From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 00:15:36 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21308106567B; Sun, 21 Aug 2011 00:15:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 852F68FC1D; Sun, 21 Aug 2011 00:15:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EALtNUE6DaFvO/2dsb2JhbABBFoQ1pECBQAEBBSMEUhsOChEZAgRVBhMbh1qnZJA3hTiBEASTFJES X-IronPort-AV: E=Sophos;i="4.68,257,1312171200"; d="scan'208";a="135039455" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Aug 2011 20:15:34 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 91349B3F82; Sat, 20 Aug 2011 20:15:34 -0400 (EDT) Date: Sat, 20 Aug 2011 20:15:34 -0400 (EDT) From: Rick Macklem To: Hiroki Sato Message-ID: <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110820.142859.319295417241413417.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_118596_867455584.1313885734527" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: pjd@FreeBSD.org, current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 00:15:36 -0000 ------=_Part_118596_867455584.1313885734527 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hiroki Sato wrote: > Rick Macklem wrote > in <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca>: > > rm> Hiroki Sato wrote: > rm> > fsid_guid = dmu_objset_fsid_guid(zfsvfs->z_os); > rm> > ASSERT((fsid_guid & ~((1ULL<<56)-1)) == 0); > rm> > vfsp->vfs_fsid.val[0] = fsid_guid; > rm> > vfsp->vfs_fsid.val[1] = ((fsid_guid>>32) << 8) | > rm> > vfsp->mnt_vfc->vfc_typenum & 0xFF; > rm> > > rm> > Since the vfc_typenum variable is incremented every time a new > vfs is > rm> > installed, loading order of modules that call vfs_register() > affects > rm> > ZFS's fsid. > rm> > > rm> > Anyway, possibility of fsid change is troublesome especially for > an > rm> > NFS server with a lot of clients running. Can zeroing or setting > a > rm> > fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful? > rm> > > rm> > -- Hiroki > rm> Well, the problem is that the fsid needs to be unique among all > mounts. > rm> The vfs_typenum field is used to try and ensure that it does not > end up > rm> the same value as a non-ZFS file system. > rm> > rm> (A) I think making that field a fixed constant should be ok, if > the function > rm> checks for a conflict by calling vfs_getvfs() to check for one. > rm> See vfs_getnewfsid() for how this is done. (There is a mutex lock > that > rm> needs to be held while doing it.) Alternately, if ZFS can call > vfs_getnewfsid() > rm> instead of doing its own, that might be nicer? > rm> > rm> (B) Another way to fix this would be to modify vfs_register() to > look up > rm> file systems in a table (by vfc_name) and used a fixed, assigned > value > rm> from the table for vfc_typenum for entries found in the table. > Only do > rm> the "maxvfsconf++" when there isn't an entry for the fstype in the > table. > rm> (VFS_GENERIC can be set to the size of the table. That's what > happened > rm> in the bad old days when vfsconf was a table built at kernel > config time.) > rm> > rm> If you guys think (B) is preferred, I could come up with a patch. > I don't > rm> know enough about ZFS to do (A). > > rm> Oh, and I think other fs types will suffer the same fate, except > that > rm> they usually avoid it, because they are compiled into the kernel > and > rm> the assignment of vfs_typenum happens in the same order-->same > value. > > Yes, using vfs_getnewfsid() does not solve the issue. > > I noticed that Solaris looked up a fixed array vfssw[] exactly for > the purpose. I think a table like it is a good solution for fixing > fsid for each file system. > > -- Hiroki Hiroki, could you please test the attached patch. One problem with this patch is that I don't know how to create a fixed table that matches what systems would already have been getting. (I got the first 6 entries by booting a GENERIC i386 kernel with a printf in vfs_init(), so I suspect those don't change much, although I'm not sure if ZFS will usually end up before or after them?) Do you guys know what ZFS gets assigned typically? (I realize that changes w.r.t. when it gets loaded, so the question also becomes "do you know how it typically gets loaded" so the table can have that vfc_typenum value assigned to it?) Maybe you could boot a system with a printf like: printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum); just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and then look in dmesg after booting, to see what your tables look like? (Without the attached patch installed.) Thanks, rick ps: The patch is also at http://people.freebsd.org/~rmacklem/fsid.patch for anyone on the list interested (if the attachment doesn't make it through. rick ------=_Part_118596_867455584.1313885734527 Content-Type: text/x-patch; name=fsid.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=fsid.patch LS0tIGtlcm4vdmZzX2luaXQuYy5zYXYJMjAxMS0wNi0xMSAxODo1ODozMy4wMDAwMDAwMDAgLTA0 MDAKKysrIGtlcm4vdmZzX2luaXQuYwkyMDExLTA4LTIwIDIwOjAxOjMxLjAwMDAwMDAwMCAtMDQw MApAQCAtNTQsOSArNTQsMzggQEAgc3RhdGljIGludAl2ZnNfdW5yZWdpc3RlcihzdHJ1Y3QgdmZz Y29uZgogTUFMTE9DX0RFRklORShNX1ZOT0RFLCAidm5vZGVzIiwgIkR5bmFtaWNhbGx5IGFsbG9j YXRlZCB2bm9kZXMiKTsKIAogLyoKKyAqIFRoaXMgdGFibGUgYXNzaWducyBzdGF0aWMgdmZjX3R5 cGVudW0gdmFsdWVzIGZvciBmaWxlIHN5c3RlbXMgdGhhdAorICogYXJlIHdlbGwga25vd24gdG8g dGhlIHN5c3RlbS4gVGhpcyBhdm9pZHMgdGhlIHByb2JsZW0gb2YgYSBmaWxlIHN5c3RlbSdzCisg KiBmc2lkIGFuZCwgdGhlcmVmb3JlLCBpdHMgTkZTIGZpbGUgaGFuZGxlLCBmcm9tIGNoYW5naW5n IGJhc2VkIG9uCisgKiB3aGVuIHRoZSBmaWxlIHN5c3RlbSBpcyBsb2FkZWQgaW50byB0aGUga2Vy bmVsLgorICogRmlsZSBzeXN0ZW0gdHlwZXMgbm90IGluIHRoaXMgbGlzdCB3aWxsIGJlIGFzc2ln bmVkIHZhbHVlcyBiYXNlZAorICogb24gbWF4dmZzY29uZi4KKyAqLworc3RhdGljIHN0cnVjdCB2 ZnN0eXBlbnVtcyB7CisJY2hhcgkqdHlwZW5hbWU7CisJaW50CXR5cGVudW07Cit9IHZmc3R5cGVu dW1zW10gPSB7CisJeyAiY2Q5NjYwIiwJMQl9LAorCXsgInVmcyIsCTIJfSwKKwl7ICJwcm9jZnMi LAkzCX0sCisJeyAiZGV2ZnMiLAk0CX0sCisJeyAibXNkb3NmcyIsCTUJfSwKKwl7ICJuZnMiLAk2 CX0sCisJeyAiemZzIiwJNwl9LAorCXsgInJlaXNlcmZzIiwJOAl9LAorCXsgInRtcGZzIiwJOQl9 LAorCXsgImhwZnMiLAkxMAl9LAorCXsgIm50ZnMiLAkxMQl9LAorCXsgImV4dDJmcyIsCTEyCX0s CisJeyAidWRmIiwJMTMJfSwKKwl7ICJ4ZnMiLAkxNAl9LAorCXsgIiIsCQkwCX0JLyogTXVzdCBi ZSBsYXN0LiAqLworfTsKKworLyoKICAqIFRoZSBoaWdoZXN0IGRlZmluZWQgVkZTIG51bWJlci4K ICAqLwotaW50IG1heHZmc2NvbmYgPSBWRlNfR0VORVJJQyArIDE7CitpbnQgbWF4dmZzY29uZiA9 IHNpemVvZih2ZnN0eXBlbnVtcykgLyBzaXplb2Yoc3RydWN0IHZmc3R5cGVudW1zKTsKIAogLyoK ICAqIFNpbmdsZS1saW5rZWQgbGlzdCBvZiBjb25maWd1cmVkIFZGU2VzLgpAQCAtMTM4LDYgKzE2 Nyw3IEBAIHZmc19yZWdpc3RlcihzdHJ1Y3QgdmZzY29uZiAqdmZjKQogCXN0cnVjdCBzeXNjdGxf b2lkICpvaWRwOwogCXN0cnVjdCB2ZnNvcHMgKnZmc29wczsKIAlzdGF0aWMgaW50IG9uY2U7CisJ aW50IGk7CiAKIAlpZiAoIW9uY2UpIHsKIAkJdmF0dHJfbnVsbCgmdmFfbnVsbCk7CkBAIC0xNTIs NyArMTgyLDE4IEBAIHZmc19yZWdpc3RlcihzdHJ1Y3QgdmZzY29uZiAqdmZjKQogCWlmICh2ZnNf YnluYW1lKHZmYy0+dmZjX25hbWUpICE9IE5VTEwpCiAJCXJldHVybiBFRVhJU1Q7CiAKLQl2ZmMt PnZmY190eXBlbnVtID0gbWF4dmZzY29uZisrOworCS8qIEZpcnN0LCBzZWFyY2ggZm9yIGEgbWF0 Y2ggaW4gdmZzdHlwZW51bXNbXS4gKi8KKwlmb3IgKGkgPSAwOyB2ZnN0eXBlbnVtc1tpXS50eXBl bnVtICE9IDA7IGkrKykgeworCQlpZiAoc3RybmNtcCh2ZnN0eXBlbnVtc1tpXS50eXBlbmFtZSwg dmZjLT52ZmNfbmFtZSwgTUZTTkFNRUxFTikKKwkJICAgID09IDApIHsKKwkJCXZmYy0+dmZjX3R5 cGVudW0gPSB2ZnN0eXBlbnVtc1tpXS50eXBlbnVtOworcHJpbnRmKCJmbmQgJXMsICVkXG4iLHZm Yy0+dmZjX25hbWUsdmZjLT52ZmNfdHlwZW51bSk7CisJCQlicmVhazsKKwkJfQorCX0KKwlpZiAo dmZzdHlwZW51bXNbaV0udHlwZW51bSA9PSAwKQorCQkvKiBOb3QgZm91bmQsIHNvIGFzc2lnbiBp dCBkeW5hbWljYWxseS4gKi8KKwkJdmZjLT52ZmNfdHlwZW51bSA9IG1heHZmc2NvbmYrKzsKIAlU QUlMUV9JTlNFUlRfVEFJTCgmdmZzY29uZiwgdmZjLCB2ZmNfbGlzdCk7CiAKIAkvKgo= ------=_Part_118596_867455584.1313885734527-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 03:27:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB1D9106566B for ; Sun, 21 Aug 2011 03:27:27 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3A98FC0C for ; Sun, 21 Aug 2011 03:27:27 +0000 (UTC) X-AuditID: 1209190f-b7b44ae000000a24-1e-4e5076fe356d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 79.7B.02596.EF6705E4; Sat, 20 Aug 2011 23:09:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p7L3CORk004212; Sat, 20 Aug 2011 23:12:25 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7L3CM7x012531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Aug 2011 23:12:24 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7L3CLwN026684; Sat, 20 Aug 2011 23:12:21 -0400 (EDT) Date: Sat, 20 Aug 2011 23:12:21 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <1522286016.115315.1313878060040.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <1522286016.115315.1313878060040.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6novu/LMDPYE6KxYQrP5gsbrWvYra4 PHUpm8XDZdeYHFg8Znyaz+Lxe/NepgCmKC6blNSczLLUIn27BK6M4+sushQ8Za34/+wCWwPj cZYuRk4OCQETicYLzawQtpjEhXvr2boYuTiEBPYxSux61sEO4WxglJi6tIMRwjnAJLF18X0m CKeBUeL+nOfMIP0sAtoSC5YdZgSx2QRUJGa+2cgGYosIqEtsXt0PVsMs4C7xfMJlJhBbWEBB YsLddWA2p0CAxKOzp4Fu4uDgFXCQ+LO7GCQsJOAvMW9nA1irqICOxOr9U8DO5hUQlDg58wkL xEhLiX9rf7FOYBSchSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJN jKDg5ZTk38H47aDSIUYBDkYlHt5fl/z9hFgTy4orcw8xSnIwKYnysgNDX4gvKT+lMiOxOCO+ qDQntfgQowQHs5IIr5MQUI43JbGyKrUoHyYlzcGiJM7buMPBT0ggPbEkNTs1tSC1CCYrw8Gh JMH7C2SoYFFqempFWmZOCUKaiYMTZDgP0PBSkBre4oLE3OLMdIj8KUZFKXHeHyAJAZBERmke XC8subxiFAd6RZh3LUgVDzAxwXW/AhrMBDRYapcPyOCSRISUVAOj+JF3Ef9dLZ5mXlWwMHde 0r6jTvPMtwmlpiYmaokP5avMHd8tb5Cp91x5UPlNuVL54RLnZPlLP8suV51uOquZENJw0b7X nGlv2c8j8/4vvVKaEjdHkvN0+E43Je4PSneFcjj/bdi1OejbzTcXluc8PKWx84rK4ZNsfVu2 f7qS2vO7vWzfiaXvlFiKMxINtZiLihMBrHRJ5QkDAAA= Cc: pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 03:27:28 -0000 On Sat, 20 Aug 2011, Rick Macklem wrote: >> Yes, using vfs_getnewfsid() does not solve the issue. >> >> I noticed that Solaris looked up a fixed array vfssw[] exactly for >> the purpose. I think a table like it is a good solution for fixing >> fsid for each file system. >> >> -- Hiroki > If anyone thinks using a fixed table to assign vfc_typenum for known > file system types is a bad idea, please let us know. Fixed table sounds like a good plan. Is there a reason for/against using a hash table for types that are not in the fixed table? The advantage would be that out-of-tree filesystems get a consistent typenum (modulo hash collisions), but there would be more overhead in maintaining the table. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 04:13:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFD3A1065670; Sun, 21 Aug 2011 04:13:08 +0000 (UTC) (envelope-from jwd@SlowBlink.Com) Received: from nmail.slowblink.com (rrcs-24-199-145-34.midsouth.biz.rr.com [24.199.145.34]) by mx1.freebsd.org (Postfix) with ESMTP id 89FFA8FC08; Sun, 21 Aug 2011 04:13:08 +0000 (UTC) Received: from nmail.slowblink.com (localhost [127.0.0.1]) by nmail.slowblink.com (8.14.3/8.14.3) with ESMTP id p7L3bomJ039848; Sat, 20 Aug 2011 23:37:50 -0400 (EDT) (envelope-from jwd@nmail.slowblink.com) Received: (from jwd@localhost) by nmail.slowblink.com (8.14.3/8.14.3/Submit) id p7L3bond039847; Sat, 20 Aug 2011 23:37:50 -0400 (EDT) (envelope-from jwd) Date: Sat, 20 Aug 2011 23:37:50 -0400 From: John To: Current List Message-ID: <20110821033750.GA39626@slowblink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sun, 21 Aug 2011 04:17:35 +0000 Cc: FS List Subject: nfs lock failure/hang when using alias address for server from linux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 04:13:09 -0000 Hi, I have an nfs server running 9-current. Everything works as far as nfs i/o operations are concerned. From another FreeBSD box, nfs locking works great to the server when addressed by both it's real ip address and it's aliased ip address. From a Linux system: Linux bb05d6403.unx.sas.com 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux nfs locking works fine if the mount goes to the real ip address of the server. If, however, the server is mounted by using it's aliased ip address, while nfs i/o operations work fine, file locking hangs. On the server, the processes: root 5995 0.0 0.0 14272 1920 ?? Ss 3:48PM 0:05.33 /usr/sbin/rpcbind -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 root 6021 0.0 0.0 12316 2364 ?? Ss 3:48PM 0:00.65 /usr/sbin/mountd -r -l -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 root 6048 0.0 0.0 10060 1864 ?? Ss 3:48PM 0:00.10 nfsd: master (nfsd) root 6049 0.0 0.0 10060 1368 ?? S 3:48PM 0:00.20 nfsd: server (nfsd) root 6074 0.0 0.0 274432 2084 ?? Is 3:48PM 0:00.03 /usr/sbin/rpc.statd -d -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 root 6099 0.0 0.0 14400 1780 ?? Ss 3:48PM 0:00.03 /usr/sbin/rpc.lockd -d 9 -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 The server is accessed by udp in addition to tcp thus the -h options for each address. Nfsv4 is not enabled at this time. I have the debug output of statd & lockd running to /var/log via syslog but nothing useful shows up. The interface configuration: bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 84:2b:2b:fd:a1:fc inet 10.24.6.38 netmask 0xffff0000 broadcast 10.24.255.255 inet6 fe80::862b:2bff:fefd:a1fc%bce0 prefixlen 64 scopeid 0x1 inet 10.24.6.33 netmask 0xffffffff broadcast 10.24.255.255 inet 10.24.6.34 netmask 0xffffffff broadcast 10.24.255.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Above, a mount to 10.24.6.38 works. A mount to either 10.24.6.33 or 10.24.6.34 works for nfs i/o operations, but hangs for lock requests. I'd like this to work so I can transistion some volumes around to different servers. Does anyone have any thoughts on the best way to debug this? I've looked at what I believe are the obvious areas. I'll probably start looking more closely at tcpdump next. Thanks, John From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 10:36:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 637E5106566C for ; Sun, 21 Aug 2011 10:36:17 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from mail.beastielabs.net (beasties.demon.nl [82.161.3.114]) by mx1.freebsd.org (Postfix) with ESMTP id A408D8FC20 for ; Sun, 21 Aug 2011 10:36:15 +0000 (UTC) Received: from testsoekris.hotsoft.nl (localhost [127.0.0.1]) by mail.beastielabs.net (8.14.4/8.14.4) with ESMTP id p7LA4Q4e028377; Sun, 21 Aug 2011 12:04:26 +0200 (CEST) (envelope-from hans@testsoekris.hotsoft.nl) Received: (from hans@localhost) by testsoekris.hotsoft.nl (8.14.4/8.14.4/Submit) id p7LA4QIw028376; Sun, 21 Aug 2011 12:04:26 +0200 (CEST) (envelope-from hans) Date: Sun, 21 Aug 2011 12:04:26 +0200 From: Hans Ottevanger To: Hugo Silva Message-ID: <20110821100426.GA28260@testsoekris.hotsoft.nl> References: <4E4F71B5.3010606@barafranca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E4F71B5.3010606@barafranca.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: Can *you* UFS snapshot a filesystem with 9.0-BETA1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 10:36:17 -0000 On Sat, Aug 20, 2011 at 09:35:01AM +0100, Hugo Silva wrote: > > > Le Thu, 18 Aug 2011 10:22:31 +0100, > Hugo Silva a ?crit : > > Hello, > > > I'm wondering. On a virtual machine (amd64 HVM+PV), it's crashing > > every time. Not sure if this is SNAFU, as I had never used ufs > > snapshots on freebsd before. > > > > After running mksnap_ffs, ssh stops working (a telnet session doesn't > > show the sshd banner). The ssh session where the command was run from > > stops responding, the webserver dies and xm console'ing from the dom0 > > works, but the VM is unresponsive (ie no login prompt on ENTER). > > > > Anyone else seeing the same? > > I've tried in a FreeBSD guest (9.0-beta1/i386) into VirtualBox and > I see a LOR (or looks like a LOR), then the system is freezed. > This is 100% reproductible. > > Unfortunatly, I'm not able to dump a panic or to break into the > debugger, so a screenshot : > http://user.lamaiziere.net/patrick/public/lormksnap.png > > You should ask on freebsd-current@ > Hi, I can confirm that this happens on "real iron" too. I use an i386 test installation (P4 2.4 GHz, 2GB RAM, 500GB PATA disk), running 9.0-BETA1 as distributed (with a kernel effectively being GENERIC with devices removed that I don't have). When I try to make a snapshot using cd /usr; mksnap_ffs /usr/.snap/testsnap the system is still responsive for a few seconds, with lots of disk activity, but then it prints the following output on the console (using firewire and dcons to ease capturing): lock order reversal: 1st 0xc5a289e8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 2nd 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 3rd 0xc5663af8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,616e735f,6f687370,3a632e74,a363435,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efe14,c5035308,c5039408,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efe14,c5663af8,c09df984,c5039408,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c5663af8,9,c0a10ba2,222,0,...) at witness_checkorder+0x839 __lockmgr_args(c5663af8,80100,c5663b18,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,c0bf1250,c59b9c30,80100,c5663aa0,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,c4fda588,c0a8df20,c5663aa0,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5663aa0,80100,c0a10ba2,222,c5011e80,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x14cb ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- lock order reversal: 1st 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc51a72dc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,662f7366,735f7366,7370616e,2e746f68,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efdfb,c5035308,c5039b58,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efdfb,c51a72dc,c0a10c04,c5039b58,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c51a72dc,9,c0a10ba2,332,c5a28a08,...) at witness_checkorder+0x839 __lockmgr_args(c51a72dc,80400,c5a28a08,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,deb2434c,100000,80400,c5a28990,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,deb243a8,c0a8df20,c5a28990,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5a28990,80400,c0a10ba2,332,0,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x295e ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- After this the system is fully unresponsive and requires a hard reset. Once rebooted, the snapshot file appears to exist, but is unusable. When reverting to just softupdates, i.e. disabling journaling on /usr, everything goes well, except that the same LOR's still do occur, though the addresses differ. My amd64 9.0-CURRENT system, just updated to r225055, has the same issue, but since I do not have WITNESS in the kernel config there, the console output is missing. BTW, this issue also makes dump(9) hang the system when the -L option is used. Kind regards, Hans Ottevanger From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 13:24:11 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E9871065673; Sun, 21 Aug 2011 13:24:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 316648FC16; Sun, 21 Aug 2011 13:24:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAIoGUU6DaFvO/2dsb2JhbABBDoQ9pD2BQAEBAQEDAQEBICsgCxsYAgINGQIpAQkmBggHBAEaAgSHVKUCkDWBLIQMgRAEkQaCDpA+VA X-IronPort-AV: E=Sophos;i="4.68,258,1312171200"; d="scan'208";a="131746198" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 21 Aug 2011 09:24:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 26795B3F08; Sun, 21 Aug 2011 09:24:10 -0400 (EDT) Date: Sun, 21 Aug 2011 09:24:10 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 13:24:11 -0000 Benjamin Kaduk wrote: > On Sat, 20 Aug 2011, Rick Macklem wrote: > > >> Yes, using vfs_getnewfsid() does not solve the issue. > >> > >> I noticed that Solaris looked up a fixed array vfssw[] exactly for > >> the purpose. I think a table like it is a good solution for fixing > >> fsid for each file system. > >> > >> -- Hiroki > > If anyone thinks using a fixed table to assign vfc_typenum for known > > file system types is a bad idea, please let us know. > > Fixed table sounds like a good plan. > Is there a reason for/against using a hash table for types that are > not in > the fixed table? The advantage would be that out-of-tree filesystems > get > a consistent typenum (modulo hash collisions), but there would be more > overhead in maintaining the table. > Well, the current code maintains maxvfsconf as the largest value of vfc_typenum configured. (vfs_register() increases it and vfs_unregister() shrinks it back down.) Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know what uses that sysctl, but it seems that doing a hash on vfc_name (which I think was what you were suggesting?) would result in a large maxvfsconf with sparsely distributed vfc_typenum values. I don't know, but I suspect that wouldn't satisfy the desired sysctl() behaviour? rick > -Ben Kaduk > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 13:54:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3ECC106564A; Sun, 21 Aug 2011 13:54:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8A89F8FC15; Sun, 21 Aug 2011 13:54:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAO4NUU6DaFvO/2dsb2JhbABBhEukPYFAAQEBAQMBAQEgKyALGxgCAg0ZAikBCSYGCAcEARwEh1SlAJA3gSyEDIEQBJEGgg6REg X-IronPort-AV: E=Sophos;i="4.68,258,1312171200"; d="scan'208";a="135068216" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 21 Aug 2011 09:54:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 68F47B3F3E; Sun, 21 Aug 2011 09:54:37 -0400 (EDT) Date: Sun, 21 Aug 2011 09:54:37 -0400 (EDT) From: Rick Macklem To: John Message-ID: <1679158213.124383.1313934877377.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110821033750.GA39626@slowblink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: FS List , Current List Subject: Re: nfs lock failure/hang when using alias address for server from linux X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 13:54:39 -0000 John De wrote: > Hi, > > I have an nfs server running 9-current. Everything works as far > as nfs i/o operations are concerned. > > From another FreeBSD box, nfs locking works great to the server > when addressed by both it's real ip address and it's aliased ip > address. > > From a Linux system: > > Linux bb05d6403.unx.sas.com 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May > 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > > nfs locking works fine if the mount goes to the real ip address > of the server. If, however, the server is mounted by using it's > aliased > ip address, while nfs i/o operations work fine, file locking hangs. > > On the server, the processes: > > root 5995 0.0 0.0 14272 1920 ?? Ss 3:48PM 0:05.33 /usr/sbin/rpcbind -h > 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 > root 6021 0.0 0.0 12316 2364 ?? Ss 3:48PM 0:00.65 /usr/sbin/mountd -r > -l -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 > root 6048 0.0 0.0 10060 1864 ?? Ss 3:48PM 0:00.10 nfsd: master (nfsd) > root 6049 0.0 0.0 10060 1368 ?? S 3:48PM 0:00.20 nfsd: server (nfsd) > root 6074 0.0 0.0 274432 2084 ?? Is 3:48PM 0:00.03 /usr/sbin/rpc.statd > -d -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 > root 6099 0.0 0.0 14400 1780 ?? Ss 3:48PM 0:00.03 /usr/sbin/rpc.lockd > -d 9 -h 10.24.6.38 -h 172.1.1.2 -h 10.24.6.33 -h 10.24.6.34 > > The server is accessed by udp in addition to tcp thus the -h > options for each address. Nfsv4 is not enabled at this time. I have > the debug output of statd & lockd running to /var/log via syslog but > nothing useful shows up. > > The interface configuration: > > bce0: flags=8843 metric 0 mtu > 1500 > options=c01bb > ether 84:2b:2b:fd:a1:fc > inet 10.24.6.38 netmask 0xffff0000 broadcast 10.24.255.255 > inet6 fe80::862b:2bff:fefd:a1fc%bce0 prefixlen 64 scopeid 0x1 > inet 10.24.6.33 netmask 0xffffffff broadcast 10.24.255.255 > inet 10.24.6.34 netmask 0xffffffff broadcast 10.24.255.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > Above, a mount to 10.24.6.38 works. A mount to either 10.24.6.33 > or 10.24.6.34 works for nfs i/o operations, but hangs for lock > requests. > > I'd like this to work so I can transistion some volumes around to > different servers. > > Does anyone have any thoughts on the best way to debug this? I've > looked > at what I believe are the obvious areas. I'll probably start looking > more > closely at tcpdump next. > I think you will probably need to capture packets and take a look. (wireshark interprets the NFS stuff much better than tcpdump, although tcpdump is fine for the capture part) A wild guess is that it will be something like: - Linux client sends an IP broadcast (those Sun RPC protocols love to do that) - FreeBSD server replies via main address and not alias - Linux client doesn`t handle reply that isn`t from the address used for the mount. (You might poke around on the Linux side, in case there is some option or sysctl that affects what addresses their lockd can handle.) rick > Thanks, > John > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 16:53:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765031065672 for ; Sun, 21 Aug 2011 16:53:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4956D8FC1B for ; Sun, 21 Aug 2011 16:53:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQA00200EX0QN00@smtpauth3.wiscmail.wisc.edu>; Sun, 21 Aug 2011 11:53:24 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQA00I2VEWY5Q30@smtpauth3.wiscmail.wisc.edu>; Sun, 21 Aug 2011 11:53:23 -0500 (CDT) Date: Sun, 21 Aug 2011 11:53:22 -0500 From: Nathan Whitehorn In-reply-to: <927966496.20110820112229@serebryakov.spb.ru> To: lev@FreeBSD.org Message-id: <4E513802.9090306@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.21.164215, SenderIP=76.210.68.180 References: <927966496.20110820112229@serebryakov.spb.ru> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: freebsd-current@freebsd.org Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 16:53:25 -0000 On 08/20/11 02:22, Lev Serebryakov wrote: > Hello, Freebsd-current. > > Maybe, everything is reported already, but I think, that better I'll > be second, that no-one notice this: > > Manual partitioning chosen > > (1) Installer offer me bunch of Partition schemes, but only MBR > and BSD have sense. Why i386 installer offer me PC98 or PowerPC-based > Apple partition schemes?! Why it offer GPT when system doesn't have > UFI BIOS? I could be wrong about GPT, but APT and PC98-based variants > should be disabled even in "Manual mode," IMHO. GPT is bootable on all x86 systems, with either EFI or BIOS, and is now the default unless you are sharing the disk with another OS (Linux/Windows). All of them are offered as options because it is sometimes useful to have more choices -- for instance, one of the disks in my powerpc64 desktop is formatted with GPT, which is nonbootable on that platform. For each partition type, the help text tells you if it is bootable or not, and you will be warned by the installer if you try to install onto a non-bootable partition scheme. The default selection in that dialog on all platforms is also always one that is bootable. > (2) MBR Slice creation. Status line suggest "freebsd-ufs" and > "freebsd-swap" as examples for "Type" field (which contains "freebsd" > by default, but "freebsd-ufs" leads to "Error: Invalid argument" :) The help text will be changed in this case, but the default is hopefully already suggestive. Thanks for pointing this out. > (3) "Auto" creates one big / partition + SWAP. It looks very not-BSD > way (disk is only 8Gb, it is virtual machine). This is designed to ease resizing on VMs as well as to kill the default-/-is-too-small problem forever. There was a great deal of discussion about this several months ago; no one made a final proposal for changing it. > (4) Partition types again: IMHO, drop-down of filesystem types will be > much better. It is not clear, is it possible to type "zfs" here, for > example. That is slightly unfortunate, but unavoidable: libdialog doesn't have a drop-down menu widget and geom takes freeform text here (which can be useful if you want to use various kinds of exotic partition types). Again, you get a warning if you pick something crazy. Hopefully, freebsd-zfs will in fact be operational in the future. > (5) Partition creation dialog has button "Options", but modify dialog > doesn't. This is by design. The installer can't run tunefs, nor is there even something like tunefs for some of the supported partition types (msdosfs, for instance). > (6) Partition editor main panel: > (a) Inconsistent sizes display. "ada0" has size "8.0 GB" but "ada0s1" > has size "8 GB". I've never seen this. Maybe some rounding behavior in humanize_number() > (b) No information about free size on device/slice. That could be added, I suppose, although the total sizes and partition sizes are printed. The available free space is also used as the default partition size when you choose Add. > (7) Partition editor doesn't seen existing filesystems and doesn't > warn about parititoning disks with existing filesystems. I have two > (virtual) disks common for all my VMs -- with sources (one common disk > per version) and with some scratch space (common for every my VM), > FSes are created without any partitions or slices, directly on device > nodes (ada1 and ada2). PArtition Editor doesn't have any sign or > warning, that ada1 and ada2 contains valid FreeBSD filesystems. I'm not sure I understand what you are saying. It lists all existing partitions on all existing disks and warns you before replacing them with new ones. It has no way of knowing (from GEOM) about UFS file systems directly on disks, nor do any of our other system tools. > (8) After "Exit" from Partition Editor I expected some filesystem > options selection (as here is no visible options on partition > creation). NOPE. Also, it is impossible to set mount points > for exisitng filesystems (see above about ada1 and ada2) Why would you expect it there? It is perfectly possible to mount existing file systems from the installer -- they just have to live on partitions. I'm not sure whether we want to support the case of the totally unpartitioned disk in the installer, anyway. > (9) Lot of LORs on slice/partition creation and newfs. Yes. These are not an installer problem, but should be fixed. > (10) Mistype password for Root for second type -- no message about it, > simple "New password:" prompt. It is not obvious, what happens. That's the usual way passwd works? (which is what is running) > (11) No way to mount NFS file systems :) > You can do this easily from the shell of course, but I'll try to think about an appropriate UI for that. It may not get done in time for the release. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 17:42:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 031041065673 for ; Sun, 21 Aug 2011 17:42:50 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B4C618FC12 for ; Sun, 21 Aug 2011 17:42:49 +0000 (UTC) Received: by gwb15 with SMTP id 15so2913728gwb.13 for ; Sun, 21 Aug 2011 10:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=iurudvfKzeUCibSKnLeA9qlWnuI1uE6Sf6Ca3OZ/26A=; b=ECqb6rQMtiMnYLv/+WtIJNehyNmki4axs+l6epgMx9EeELMyOoSUIiJVkIwYgsy/jX NrnhelM+IKvklx6vjej98xPAnziCsded8PavWsYibGd/qobCYc2DMzDqbMcOGIlx5euk jK1YJUGTsAcmIEFJCk43q0q2hweZYymxVI5eE= Received: by 10.236.190.2 with SMTP id d2mr8587036yhn.107.1313948568812; Sun, 21 Aug 2011 10:42:48 -0700 (PDT) Received: from [192.168.15.185] (c-71-226-13-215.hsd1.ga.comcast.net [71.226.13.215]) by mx.google.com with ESMTPS id a62sm1594151yhe.11.2011.08.21.10.42.47 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 10:42:47 -0700 (PDT) From: Derrick Edwards To: Andriy Gapon In-Reply-To: <4E4E717B.9090407@FreeBSD.org> References: <1313705220.8034.2.camel@datdude> <4E4E717B.9090407@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Sun, 21 Aug 2011 13:45:07 -0400 Message-ID: <1313948707.2448.2.camel@datdude> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: PANICS on 9.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 17:42:50 -0000 On Fri, 2011-08-19 at 17:21 +0300, Andriy Gapon wrote: > on 19/08/2011 01:07 Derrick Edwards said the following: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0xffffbe00a45b6798 > > This address looks suspiciously like a result of bit flips. > > > fault code = supervisor write data, page not present > > instruction pointer = 0x20:0xffffffff814f444c > > stack pointer = 0x28:0xffffff82267fbe90 > > frame pointer = 0x28:0xffffff82267fbea0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 5889 (csup) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > Uptime: 10h9m0s > > Dumping 1823 out of 7912 > > Do you always get the same stack trace? Or are they always different? > I would double-check the hardware first. > Andriy, Thanks for the reply. The stack trace are different. Attached is the latest one. Machine is about 3 months old. Any recommendations on what hardware to start looking at. Panic occurs with X and without X being used. Derrick panic: page fault 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: trap number = 12 panic: page fault cpuid = 3 Uptime: 2m12s Dumping 1317 out of 7912 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..92% 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/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.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 0xffffffff80850995 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:430 #2 0xffffffff80850dc3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xffffffff80b3b5cd in trap_fatal (frame=0xfffffe0007eb5000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:805 #4 0xffffffff80b3b9ed in trap_pfault (frame=0xffffff8221a275d0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:721 #5 0xffffffff80b3bf2f in trap (frame=0xffffff8221a275d0) at /usr/src/sys/amd64/amd64/trap.c:473 #6 0xffffffff80b268a3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff80a986fc in swp_pager_hash (object=0xfffffe0009d1fd80, index=1140583520) at /usr/src/sys/vm/swap_pager.c:466 #8 0xffffffff80a99129 in swp_pager_meta_build (object=0xfffffe0009d1fd80, pindex=1140583549, swapblk=1191201) at /usr/src/sys/vm/swap_pager.c:1850 #9 0xffffffff80a9b7db in swap_pager_putpages (object=0xfffffe0009d1fd80, m=0xffffff8221a27888, count=16, sync=0, rtvals=0xffffff8221a277a0) at /usr/src/sys/vm/swap_pager.c:1399 #10 0xffffffff80ab7a50 in vm_pageout_flush (mc=Variable "mc" is not available. ) at vm_pager.h:144 #11 0xffffffff80ab7e16 in vm_pageout_clean (m=0x4) at /usr/src/sys/vm/vm_pageout.c:448 #12 0xffffffff80aba24b in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1089 #13 0xffffffff8082234f in fork_exit (callout=0xffffffff80ab8c10 , arg=0x0, frame=0xffffff8221a27c50) at /usr/src/sys/kern/kern_fork.c:1025 #14 0xffffffff80b26dce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:603 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000001 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0xffffffff81179b40 in affinity () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0xfffffe0007f798c0 in ?? () #43 0xffffff8221a27180 in ?? () #44 0xffffff8221a27128 in ?? () #45 0xfffffe0005150460 in ?? () #46 0xffffffff8087a290 in sched_switch (td=0xffffffff80ab8c10, newtd=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 17:45:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B73D7106566C for ; Sun, 21 Aug 2011 17:45:41 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 74B998FC0A for ; Sun, 21 Aug 2011 17:45:41 +0000 (UTC) Received: by yxn22 with SMTP id 22so2390834yxn.13 for ; Sun, 21 Aug 2011 10:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=iurudvfKzeUCibSKnLeA9qlWnuI1uE6Sf6Ca3OZ/26A=; b=e6mHZO4MQt/gMKnZ8lU9ozzRzfDKxCQYV4c/8vg8NTM2bTlpwsaWh88L65EpvFKKxf 16WGKPlkfiSLgKsyKZSDes8IyT3bT6Q0XW/HSIcs6DX1OgoJLE3ujKgKBIFAXhoSO6ND YbtwLsmnhBLlrRNm/8/jOqXaB2Cu6VQ2dRBBk= Received: by 10.236.145.1 with SMTP id o1mr9026031yhj.119.1313948740713; Sun, 21 Aug 2011 10:45:40 -0700 (PDT) Received: from [192.168.15.185] (c-71-226-13-215.hsd1.ga.comcast.net [71.226.13.215]) by mx.google.com with ESMTPS id w1sm3687571yhi.9.2011.08.21.10.45.39 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 10:45:39 -0700 (PDT) From: Derrick Edwards To: Andriy Gapon In-Reply-To: <4E4E717B.9090407@FreeBSD.org> References: <1313705220.8034.2.camel@datdude> <4E4E717B.9090407@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Sun, 21 Aug 2011 13:47:59 -0400 Message-ID: <1313948879.2448.3.camel@datdude> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: PANICS on 9.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 17:45:41 -0000 On Fri, 2011-08-19 at 17:21 +0300, Andriy Gapon wrote: > on 19/08/2011 01:07 Derrick Edwards said the following: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0xffffbe00a45b6798 > > This address looks suspiciously like a result of bit flips. > > > fault code = supervisor write data, page not present > > instruction pointer = 0x20:0xffffffff814f444c > > stack pointer = 0x28:0xffffff82267fbe90 > > frame pointer = 0x28:0xffffff82267fbea0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 5889 (csup) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > Uptime: 10h9m0s > > Dumping 1823 out of 7912 > > Do you always get the same stack trace? Or are they always different? > I would double-check the hardware first. > Andriy, Thanks for the reply. The stack trace are different. Attached is the latest one. Machine is about 3 months old. Any recommendations on what hardware to start looking at. Panic occurs with X and without X being used. Derrick panic: page fault 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: trap number = 12 panic: page fault cpuid = 3 Uptime: 2m12s Dumping 1317 out of 7912 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..92% 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/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.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 0xffffffff80850995 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:430 #2 0xffffffff80850dc3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xffffffff80b3b5cd in trap_fatal (frame=0xfffffe0007eb5000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:805 #4 0xffffffff80b3b9ed in trap_pfault (frame=0xffffff8221a275d0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:721 #5 0xffffffff80b3bf2f in trap (frame=0xffffff8221a275d0) at /usr/src/sys/amd64/amd64/trap.c:473 #6 0xffffffff80b268a3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff80a986fc in swp_pager_hash (object=0xfffffe0009d1fd80, index=1140583520) at /usr/src/sys/vm/swap_pager.c:466 #8 0xffffffff80a99129 in swp_pager_meta_build (object=0xfffffe0009d1fd80, pindex=1140583549, swapblk=1191201) at /usr/src/sys/vm/swap_pager.c:1850 #9 0xffffffff80a9b7db in swap_pager_putpages (object=0xfffffe0009d1fd80, m=0xffffff8221a27888, count=16, sync=0, rtvals=0xffffff8221a277a0) at /usr/src/sys/vm/swap_pager.c:1399 #10 0xffffffff80ab7a50 in vm_pageout_flush (mc=Variable "mc" is not available. ) at vm_pager.h:144 #11 0xffffffff80ab7e16 in vm_pageout_clean (m=0x4) at /usr/src/sys/vm/vm_pageout.c:448 #12 0xffffffff80aba24b in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1089 #13 0xffffffff8082234f in fork_exit (callout=0xffffffff80ab8c10 , arg=0x0, frame=0xffffff8221a27c50) at /usr/src/sys/kern/kern_fork.c:1025 #14 0xffffffff80b26dce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:603 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000001 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0xffffffff81179b40 in affinity () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0xfffffe0007f798c0 in ?? () #43 0xffffff8221a27180 in ?? () #44 0xffffff8221a27128 in ?? () #45 0xfffffe0005150460 in ?? () #46 0xffffffff8087a290 in sched_switch (td=0xffffffff80ab8c10, newtd=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 18:24:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 216391065674; Sun, 21 Aug 2011 18:24:27 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C328F8FC13; Sun, 21 Aug 2011 18:24:26 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:248b:b3cd:918d:d0d2]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 648D74AC1C; Sun, 21 Aug 2011 22:24:25 +0400 (MSD) Date: Sun, 21 Aug 2011 22:24:24 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <569113961.20110821222424@serebryakov.spb.ru> To: Nathan Whitehorn In-Reply-To: <4E513802.9090306@freebsd.org> References: <927966496.20110820112229@serebryakov.spb.ru> <4E513802.9090306@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: lev@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 18:24:27 -0000 Hello, Nathan. You wrote 21 =E0=E2=E3=F3=F1=F2=E0 2011 =E3., 20:53:22: > GPT is bootable on all x86 systems, with either EFI or BIOS, and is now Ok, I was not sure here. >> (5) Partition creation dialog has button "Options", but modify dialog >> doesn't. > This is by design. The installer can't run tunefs, nor is there even > something like tunefs for some of the supported partition types=20 > (msdosfs, for instance). There is no FSes created at this stage. As far as I understand, now creteion of BSD partitions inside (MBR/GPT) slice is combined with creation of FSes on these partitions. And when I create "ada0s1a" with type "Freebsd-ufs" and want to turn soft-updates on it, I cannot without partition re-creation because "Modify" doesn't have "Options" button. And "newfs" will be called only on submit, much later! >> (7) Partition editor doesn't seen existing filesystems and doesn't >> warn about parititoning disks with existing filesystems. I have two >> (virtual) disks common for all my VMs -- with sources (one common disk >> per version) and with some scratch space (common for every my VM), >> FSes are created without any partitions or slices, directly on device >> nodes (ada1 and ada2). PArtition Editor doesn't have any sign or >> warning, that ada1 and ada2 contains valid FreeBSD filesystems. > I'm not sure I understand what you are saying. It lists all existing > partitions on all existing disks and warns you before replacing them=20 > with new ones. It has no way of knowing (from GEOM) about UFS file=20 > systems directly on disks, nor do any of our other system tools. GEOM_LABEL? ;-) These UFS2 file systems has valid labels :) > Why would you expect it there? It is perfectly possible to mount Because here is no obvious way to turn on/off softupdates and new su-based journaling when partitions are created. And no way to turn these options on/off with "Modify", either, even BEFORE filesyystems are really created. Also, such options to newfs as block sizes, etc. > existing file systems from the installer -- they just have to live on=20 > partitions. I'm not sure whether we want to support the case of the=20 > totally unpartitioned disk in the installer, anyway. Old installer had support for DD (Dangerously Dedicated) disks :) >> (9) Lot of LORs on slice/partition creation and newfs. > Yes. These are not an installer problem, but should be fixed. Yep, I understand, that it is not installer problem... >> (10) Mistype password for Root for second type -- no message about it, >> simple "New password:" prompt. It is not obvious, what happens. > That's the usual way passwd works? (which is what is running) passwd, run by hands on installed system, says "Mismatch; try again, EOF to quit". >> (11) No way to mount NFS file systems :) > You can do this easily from the shell of course, but I'll try to think I even could install FreeBSD from shell without any installer at all :) I have such experience, and it is not very difficult :) > about an appropriate UI for that. It may not get done in time for the=20 > release. Great! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 18:45:44 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F2BA1065672 for ; Sun, 21 Aug 2011 18:45:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 99DAD8FC17 for ; Sun, 21 Aug 2011 18:45:43 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA23110; Sun, 21 Aug 2011 21:45:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QvD1f-00015l-VE; Sun, 21 Aug 2011 21:45:39 +0300 Message-ID: <4E515252.4060706@FreeBSD.org> Date: Sun, 21 Aug 2011 21:45:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: Derrick Edwards References: <1313705220.8034.2.camel@datdude> <4E4E717B.9090407@FreeBSD.org> <1313948879.2448.3.camel@datdude> In-Reply-To: <1313948879.2448.3.camel@datdude> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: PANICS on 9.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 18:45:44 -0000 on 21/08/2011 20:47 Derrick Edwards said the following: > On Fri, 2011-08-19 at 17:21 +0300, Andriy Gapon wrote: >> on 19/08/2011 01:07 Derrick Edwards said the following: >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0xffffbe00a45b6798 >> >> This address looks suspiciously like a result of bit flips. >> >>> fault code = supervisor write data, page not present >>> instruction pointer = 0x20:0xffffffff814f444c >>> stack pointer = 0x28:0xffffff82267fbe90 >>> frame pointer = 0x28:0xffffff82267fbea0 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 5889 (csup) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> Uptime: 10h9m0s >>> Dumping 1823 out of 7912 >> >> Do you always get the same stack trace? Or are they always different? >> I would double-check the hardware first. >> > Andriy, > Thanks for the reply. The stack trace are different. Attached is the > latest one. Machine is about 3 months old. Any recommendations on what > hardware to start looking at. Panic occurs with X and without X being > used. Start with the memory - try memtest86/memtest86+. But actually any bit could be under suspicion - CPU, PSU, etc. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 19:21:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D8C106566C for ; Sun, 21 Aug 2011 19:21:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id F0BE68FC0A for ; Sun, 21 Aug 2011 19:21:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQA00F04LR5W900@smtpauth1.wiscmail.wisc.edu>; Sun, 21 Aug 2011 14:21:05 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQA006FSLR28I20@smtpauth1.wiscmail.wisc.edu>; Sun, 21 Aug 2011 14:21:03 -0500 (CDT) Date: Sun, 21 Aug 2011 14:21:02 -0500 From: Nathan Whitehorn In-reply-to: To: Kevin Oberman Message-id: <4E515A9E.90309@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-11, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.21.190913, SenderIP=76.210.68.180 References: User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: current@freebsd.org, Jonathan Anderson Subject: Re: Installer Feedback: Partitioning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:21:06 -0000 On 08/10/11 18:17, Kevin Oberman wrote: > On Wed, Aug 10, 2011 at 3:02 AM, Jonathan Anderson wrote: >> Hi, >> >> Love the new installer, but I do have a very small criticism of the >> guided partitioning screen: it's unclear at first glance which of the >> available buttons ("Create", "Delete", ..., "Exit") means "write the >> partitions to disk and carry on to the next step". >> >> I presume that the point of a "guided" setup is to make it easy on >> first-time FreeBSD installers; we might want to make it a little >> easier still by labeling the relevant button "OK", "Save", "Next", >> "Do It!" or something instead of "Exit". > Create and Delete act on the layout design Nothing done at this point > actually writes anything to the disk. I would suggest that "Exit" be changed > to "Continue" and, as I have already suggested, "Save" on the next screen > should be changed to "Commit" or "Execute". > > A one-liner on the screen stating that nothing at this point will > write to the disk > might be a good idea, though, just to make people more comfortable. Thanks for these suggestions! I've changed some of the wording here, and added help text on the bottom of the screen for all of the buttons. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 19:41:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF2D8106564A; Sun, 21 Aug 2011 19:41:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 480408FC08; Sun, 21 Aug 2011 19:41:42 +0000 (UTC) Received: by gxk28 with SMTP id 28so3592144gxk.13 for ; Sun, 21 Aug 2011 12:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B5ni3fry9kIQ1wdhR3U2Mz9DrJw3mf++GRGDOe0j7YI=; b=CM5uHND7ifUplW+cuewwitUJB8utTdBV1KXke5KIT+UKMG7AhwlsIUsWU6yhOA5djw jdSW9nH5BoqqCLf68worMDopCFtcIHRIskIPYG1azdvt7oTB9loAfX0nEA6asAfy7IEB mpBm/xmDnOGReWeaWHocbWbrEhpiTxuSe93YI= MIME-Version: 1.0 Received: by 10.150.209.12 with SMTP id h12mr1600804ybg.395.1313955702441; Sun, 21 Aug 2011 12:41:42 -0700 (PDT) Received: by 10.151.102.2 with HTTP; Sun, 21 Aug 2011 12:41:42 -0700 (PDT) In-Reply-To: <569113961.20110821222424@serebryakov.spb.ru> References: <927966496.20110820112229@serebryakov.spb.ru> <4E513802.9090306@freebsd.org> <569113961.20110821222424@serebryakov.spb.ru> Date: Sun, 21 Aug 2011 12:41:42 -0700 Message-ID: From: Kevin Oberman To: lev@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:41:43 -0000 2011/8/21 Lev Serebryakov : > Hello, Nathan. > You wrote 21 =C1=D7=C7=D5=D3=D4=C1 2011 =C7., 20:53:22: > >> GPT is bootable on all x86 systems, with either EFI or BIOS, and is now > =9A Ok, I was not sure here. The Wikipedia article on GUID Partition Table states that Windows only supp= orts GPT boot when the system is a EFI system and is 64-bit Windows, Vista or ne= wer. Windows-32 will not boot from a GPT disk. I know Wikipedia is not always right, but it matches my limited experience. https://secure.wikimedia.org/wikipedia/en/wiki/GUID_Partition_Table --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 20:04:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 795B9106564A for ; Sun, 21 Aug 2011 20:04:17 +0000 (UTC) (envelope-from alexander.burchell@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D81F8FC0C for ; Sun, 21 Aug 2011 20:04:16 +0000 (UTC) Received: by vws18 with SMTP id 18so4583313vws.13 for ; Sun, 21 Aug 2011 13:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XGpzHvTpWoeSkKA5mCtuAuqdSOWENvASTRuLgNbEsac=; b=Eb030VDE5Mvu/sLxb+AwD/xgtZrotLEVUru/SQjI1wVvuEHd4MxkRaU2N86GLELFAD LS8wTNejq6D93VLe/b4JuE76iwyODSKjmGrAqmLBCNxM/0qrd8hDadq+/e1C9NuHSN9V XHre/nowRDXIe4d0fVBFcH3VAEhC1QARjXVY0= MIME-Version: 1.0 Received: by 10.220.59.71 with SMTP id k7mr475536vch.126.1313955539058; Sun, 21 Aug 2011 12:38:59 -0700 (PDT) Received: by 10.220.31.3 with HTTP; Sun, 21 Aug 2011 12:38:59 -0700 (PDT) Received: by 10.220.31.3 with HTTP; Sun, 21 Aug 2011 12:38:59 -0700 (PDT) In-Reply-To: <4E459D8D.8040702@FreeBSD.org> References: <4E459D8D.8040702@FreeBSD.org> Date: Sun, 21 Aug 2011 12:38:59 -0700 Message-ID: From: Alexander Burchell To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Optiarc DVD-ROM not recognized with ATA_CAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 20:04:17 -0000 Sorry. This turned out to be an unrelated configuration problem due to my strange zfs layout. The ATA_CAM driver is not implicated! Thanks to all for their attention to this matter. Alexander burchell On Aug 12, 2011 2:39 PM, "Alexander Motin" wrote: > On 12.08.2011 22:33, Alexander Burchell wrote: >> I'm not being able to get my DVD-ROM recognized under 9-current, >> although I used the 8.2-release DVD to install FreeBSD (and then >> subsequently upgraded the system to the "head" version via svn-freebsd). >> >> 1) There is no /dev/*cd* ANYTHING at any time. >> >> NOTE: I'm using a kernel (built with clang) using the ATA_CAM option so >> I presume my DVD would be "/dev/acd0". >> >> 2) There is no indication in the boot log that the drive is probed. The >> drive light does not flash (not sure if they even do that anymore), >> however, after having moved it to another controller (AHCI SATA-3) I >> sometimes get a log such as this: >> >> ahcich1: Timeout on slot 0 port 0 >> ahcich1: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 100 serr >> 00000000 >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >> ahcich1: Timeout on slot 0 port 0 >> ahcich1: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 100 serr >> 00000000 >> >> It is an "Optiarc DVD RW AD-7190S". I believe it's at microcode 1.01 and >> there is 1.03 available at manufacturer site however that leads me to: > > Could you send me full verbose (boot -v) dmesgs with drive connected to > both chipset and Marvell controllers? > > -- > Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 17:25:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EB2D106566C for ; Sun, 21 Aug 2011 17:25:27 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id DF3B28FC13 for ; Sun, 21 Aug 2011 17:25:26 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1QvBm2-0004IT-5Z for freebsd-current@freebsd.org; Sun, 21 Aug 2011 10:25:26 -0700 Date: Sun, 21 Aug 2011 10:25:26 -0700 (PDT) From: timp To: freebsd-current@freebsd.org Message-ID: <1313947526165-4720898.post@n5.nabble.com> In-Reply-To: <927966496.20110820112229@serebryakov.spb.ru> References: <927966496.20110820112229@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 21 Aug 2011 20:22:51 +0000 Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 17:25:27 -0000 And if you want to run bsdinstall after installation for creating new partitions on just mounted hdd it require root mount point. And I have to set root mount point on existing partition. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-0-BETA1-installer-glithcies-i386-tp4717919p4720898.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 20:42:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BA01106564A for ; Sun, 21 Aug 2011 20:42:46 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9305E8FC18 for ; Sun, 21 Aug 2011 20:42:45 +0000 (UTC) Received: by eye4 with SMTP id 4so2383858eye.31 for ; Sun, 21 Aug 2011 13:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OmcmQ8DTPonG32xegzOAmyiqfCxjdz5qjKfyHFRaHgA=; b=X8Hux3B72dfFkjFDYQbi/v5lbcI4iXtvOnVwYaMXbkHyqJxOzxX9neHJY2Qj4oyzBM z5d1aPRiNrgQHv+Nftv06NevYixkTgPdWcyqlxMcZzXHL7EPRPiPJkMaJyVkNMH3Mh4+ Gh2+p/OEJrKRsf/EiRE0XrkWljwTQxUxW0Nmo= MIME-Version: 1.0 Received: by 10.213.102.13 with SMTP id e13mr368345ebo.81.1313959364409; Sun, 21 Aug 2011 13:42:44 -0700 (PDT) Received: by 10.213.20.135 with HTTP; Sun, 21 Aug 2011 13:42:44 -0700 (PDT) In-Reply-To: References: <927966496.20110820112229@serebryakov.spb.ru> <4E513802.9090306@freebsd.org> <569113961.20110821222424@serebryakov.spb.ru> Date: Sun, 21 Aug 2011 15:42:44 -0500 Message-ID: From: Scot Hetzel To: Kevin Oberman Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 20:42:46 -0000 2011/8/21 Kevin Oberman : > 2011/8/21 Lev Serebryakov : >> Hello, Nathan. >> You wrote 21 =C1=D7=C7=D5=D3=D4=C1 2011 =C7., 20:53:22: >> >>> GPT is bootable on all x86 systems, with either EFI or BIOS, and is now >> =9A Ok, I was not sure here. > > The Wikipedia article on GUID Partition Table states that Windows only su= pports > GPT boot when the system is a EFI system and is 64-bit Windows, Vista or = newer. > Windows-32 will not boot from a GPT disk. > > I know Wikipedia is not always right, but it matches my limited experienc= e. > > https://secure.wikimedia.org/wikipedia/en/wiki/GUID_Partition_Table Since this is the FreeBSD list, we are talking about booting FreeBSD from GPT partitioned disks. FreeBSD supports booting from both PC/BIOS and EFI Systems. If you want to dual boot between FreeBSD and Windows, then you will need a MBR Partitioned disk. > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6558@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 20:49:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 792D81065672; Sun, 21 Aug 2011 20:49:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 26F2D8FC0C; Sun, 21 Aug 2011 20:49:46 +0000 (UTC) Received: by qyk9 with SMTP id 9so2265421qyk.13 for ; Sun, 21 Aug 2011 13:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1vdRQ+qoFCLIWKf7QgAFkRjyOv804+qIiQB3FORHd+g=; b=k2m/UWiEym0B2K+cUfuj3eQGYgsavagGFcWLff8J3KEpX7hYxawzXIIyQtdKot/TTJ E3spRE7E3fr8Tc4Ab2J94lfEL+uRfVL0o/JCa/GHrL8FLUMwWN8ep3Uh4bozAJo1zMsx XmD7wBtj45zdm9oGYDe8p8V1K0UWp+suABezo= MIME-Version: 1.0 Received: by 10.224.210.132 with SMTP id gk4mr1018937qab.79.1313959786375; Sun, 21 Aug 2011 13:49:46 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Sun, 21 Aug 2011 13:49:46 -0700 (PDT) In-Reply-To: <4E4DB9A7.4040404@freebsd.org> References: <4E4DB9A7.4040404@freebsd.org> Date: Sun, 21 Aug 2011 13:49:46 -0700 Message-ID: From: Garrett Cooper To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 20:49:47 -0000 On Thu, Aug 18, 2011 at 6:17 PM, Nathan Whitehorn wrote: > On 08/18/11 18:24, Garrett Cooper wrote: >> >> So, I used the bsdinstaller again on the 9.0-BETA1 media with manual >> partitioning. The HP desktop ate up 3 partitions, I inconveniently >> forgot that geom can't grok secondary PC MBR partitions, was fooling >> around and cleared the partitions, etc. I hit abort to exit the >> partitioner start and from scratch and now my Windows partitions and >> recovery partitions are gone. >> >> So, oops... just a word of warning for anyone else that monkeys around >> with bsdinstall that it doesn't always hold true to the "will apply >> changes at Exit" guarantee right now (i.e. atomicity is busted). If >> someone else has a second OS that they'd rather not lose, at least >> they will know to reboot their box when committing changes. >> >> I'll inspect the code sometime this weekend to trace down the annoying >> bug, but this is probably release gating for new users (and sadly >> forces me back to wanting to use sysinstall :/..). >> > > There are only a couple of cases when it does that, and it gives you a giant > warning in all capital letters to ask if you really want to proceed. One of > those cases can be changing partitioning type. Can you elaborate on how you > made this happen? I simulated the issue in VirtualBox, like so: 1. Grab the Fedora 15 image (you could grab another version of FreeBSD though, or your choice OS). Install image to disk. 2. Boot BETA1 media. 3. Choose LiveCD. 4. Login as root, password "". 5. Type in bsdinstall and hit enter. 6. Enter in all prereqs (hostname, keyboard map, etc). 7. Choose "Guided" partitioning. 8. Choose "Use all disk". This destructively modifies the partition table, unlike some of the other options. Why does "Use all disk" need to commit immediately, instead of virtually deleting the partition table? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 20:53:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7821106564A; Sun, 21 Aug 2011 20:53:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 76D0B8FC0A; Sun, 21 Aug 2011 20:53:36 +0000 (UTC) Received: by qwc9 with SMTP id 9so3601758qwc.13 for ; Sun, 21 Aug 2011 13:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pZ9dOLhe9PIeiJpOK0aHTDm6+N8/PaKOp06esLFqQBU=; b=xrIhUxz/f3UlRrNlrHWvHZvddN+pNrTVQXMeN25VA5y6yQU6/Nop9cTbgFXRTwEI+0 +p7zjQ+D0KzsXeKRe8XzUsBZBeiqNiPuUuOSaAzWwY9vHa6C1TLbNJTj025A/+me3lEk iWgChc58WjWYT3jycBQhkTd3EKqzpV3PV7B9I= MIME-Version: 1.0 Received: by 10.224.200.3 with SMTP id eu3mr886201qab.279.1313960015440; Sun, 21 Aug 2011 13:53:35 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Sun, 21 Aug 2011 13:53:35 -0700 (PDT) In-Reply-To: <4E4DA33E.6070103@gmail.com> References: <4E4DA33E.6070103@gmail.com> Date: Sun, 21 Aug 2011 13:53:35 -0700 Message-ID: From: Garrett Cooper To: Matt Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , Nathan Whitehorn Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 20:53:36 -0000 On Thu, Aug 18, 2011 at 4:41 PM, Matt wrote: > On 08/18/11 16:24, Garrett Cooper wrote: >> >> So, I used the bsdinstaller again on the 9.0-BETA1 media with manual >> partitioning. The HP desktop ate up 3 partitions, I inconveniently >> forgot that geom can't grok secondary PC MBR partitions, was fooling >> around and cleared the partitions, etc. I hit abort to exit the >> partitioner start and from scratch and now my Windows partitions and >> recovery partitions are gone. >> >> So, oops... just a word of warning for anyone else that monkeys around >> with bsdinstall that it doesn't always hold true to the "will apply >> changes at Exit" guarantee right now (i.e. atomicity is busted). If >> someone else has a second OS that they'd rather not lose, at least >> they will know to reboot their box when committing changes. >> >> I'll inspect the code sometime this weekend to trace down the annoying >> bug, but this is probably release gating for new users (and sadly >> forces me back to wanting to use sysinstall :/..). > > Geom can do EBR ("Logical") etc...and definitely can do all 4 primary > partitions...some of that requires kernel options I think though. > I think that's what you're referring to? bsdinstall doesn't talk EBR yet though. > Also, if you haven't overwritten the actual *data*, just the mbr, there may > still be hope see testdisk in ports? I've never used it though. Maybe dd > backup whole disk first? > > My guess is you just smashed the MBR/partition table and need it fixed. Correct, but then I used it as an excuse to continue with nuking everything. I didn't lose a lot of sleep over it because I meant to nuke it eventually and have access to a legal copy of XP Corporate. > Maybe you don't need windows anymore subconsciously? > RDP & VirtualBox work fine for me :) Exactly :). The point behind having the recovery partition was to get everything back in the event that something went south, but most of the HP Windows software that comes prepackaged with desktops is junk (and the recovery software wipes the rest of the drive, which is not desirable). Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 21:32:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC34F106566B for ; Sun, 21 Aug 2011 21:32:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 90AC58FC17 for ; Sun, 21 Aug 2011 21:32:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQA00B00RUIAB00@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 21 Aug 2011 16:32:42 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQA00NRJRUH3420@smtpauth1.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 21 Aug 2011 16:32:42 -0500 (CDT) Date: Sun, 21 Aug 2011 16:32:40 -0500 From: Nathan Whitehorn In-reply-to: To: Garrett Cooper Message-id: <4E517978.2020705@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.21.212414, SenderIP=76.210.68.180 References: <4E4DB9A7.4040404@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: freebsd-current@freebsd.org Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 21:32:43 -0000 On 08/21/11 15:49, Garrett Cooper wrote: > On Thu, Aug 18, 2011 at 6:17 PM, Nathan Whitehorn > wrote: >> On 08/18/11 18:24, Garrett Cooper wrote: >>> So, I used the bsdinstaller again on the 9.0-BETA1 media with manual >>> partitioning. The HP desktop ate up 3 partitions, I inconveniently >>> forgot that geom can't grok secondary PC MBR partitions, was fooling >>> around and cleared the partitions, etc. I hit abort to exit the >>> partitioner start and from scratch and now my Windows partitions and >>> recovery partitions are gone. >>> >>> So, oops... just a word of warning for anyone else that monkeys around >>> with bsdinstall that it doesn't always hold true to the "will apply >>> changes at Exit" guarantee right now (i.e. atomicity is busted). If >>> someone else has a second OS that they'd rather not lose, at least >>> they will know to reboot their box when committing changes. >>> >>> I'll inspect the code sometime this weekend to trace down the annoying >>> bug, but this is probably release gating for new users (and sadly >>> forces me back to wanting to use sysinstall :/..). >>> >> There are only a couple of cases when it does that, and it gives you a giant >> warning in all capital letters to ask if you really want to proceed. One of >> those cases can be changing partitioning type. Can you elaborate on how you >> made this happen? > I simulated the issue in VirtualBox, like so: > 1. Grab the Fedora 15 image (you could grab another version of > FreeBSD though, or your choice OS). Install image to disk. > 2. Boot BETA1 media. > 3. Choose LiveCD. > 4. Login as root, password "". > 5. Type in bsdinstall and hit enter. > 6. Enter in all prereqs (hostname, keyboard map, etc). > 7. Choose "Guided" partitioning. > 8. Choose "Use all disk". This destructively modifies the > partition table, unlike some of the other options. > Why does "Use all disk" need to commit immediately, instead of > virtually deleting the partition table? > Thanks, > -Garrett gpart does not support (well, anyway) changing the underlying partition table format without committing changes. Replacing the partition scheme, which this does, is such an operation. I would note that it *does* warn about this: - Choose the disk. A box comes up saying that choosing "Entire disk" will erase the drive. - If you press "Entire box", a warning comes up saying "This will erase the disk. Are you sure you want to proceed?". It is only after you press OK the second time that it does anything to the drive. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 21:34:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DE8E106566B for ; Sun, 21 Aug 2011 21:34:08 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id E6D278FC13 for ; Sun, 21 Aug 2011 21:34:07 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQA00300RWVID00@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 21 Aug 2011 16:34:07 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQA002CZRWTLM00@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 21 Aug 2011 16:34:06 -0500 (CDT) Date: Sun, 21 Aug 2011 16:34:05 -0500 From: Nathan Whitehorn In-reply-to: To: Garrett Cooper Message-id: <4E5179CD.5040303@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.21.212414, SenderIP=76.210.68.180 References: <4E4DA33E.6070103@gmail.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: Matt , FreeBSD Current Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 21:34:08 -0000 On 08/21/11 15:53, Garrett Cooper wrote: > On Thu, Aug 18, 2011 at 4:41 PM, Matt wrote: >> On 08/18/11 16:24, Garrett Cooper wrote: >>> So, I used the bsdinstaller again on the 9.0-BETA1 media with manual >>> partitioning. The HP desktop ate up 3 partitions, I inconveniently >>> forgot that geom can't grok secondary PC MBR partitions, was fooling >>> around and cleared the partitions, etc. I hit abort to exit the >>> partitioner start and from scratch and now my Windows partitions and >>> recovery partitions are gone. >>> >>> So, oops... just a word of warning for anyone else that monkeys around >>> with bsdinstall that it doesn't always hold true to the "will apply >>> changes at Exit" guarantee right now (i.e. atomicity is busted). If >>> someone else has a second OS that they'd rather not lose, at least >>> they will know to reboot their box when committing changes. >>> >>> I'll inspect the code sometime this weekend to trace down the annoying >>> bug, but this is probably release gating for new users (and sadly >>> forces me back to wanting to use sysinstall :/..). >> Geom can do EBR ("Logical") etc...and definitely can do all 4 primary >> partitions...some of that requires kernel options I think though. >> I think that's what you're referring to? > bsdinstall doesn't talk EBR yet though. > That isn't actually true. You can't install to EBR (due to bootloader limitations), but it can see and manipulate it. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 22:49:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9974B1065673 for ; Sun, 21 Aug 2011 22:49:20 +0000 (UTC) (envelope-from ashley.wil@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4CE8FC12 for ; Sun, 21 Aug 2011 22:49:19 +0000 (UTC) Received: by vxh11 with SMTP id 11so4889002vxh.13 for ; Sun, 21 Aug 2011 15:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=KdCahWVEny4eWWjPGmxLa2JQBePFaHX8aSu0Q1/NOgo=; b=G2quUpiNVwuEoFJwWUdb3Tah3zPk+t6CSXOFL6RIh/Df72Sao6e7Q179jbWanJ/qkE wFxkBN5dUS1141OBC48xYggLeoLGfMTdrHYCrXJKiXXi00wZGPVvLwo0XpevqfaXfVR3 c7F1bT/dJX5WBheau6m4QWLQj0VcBg460PS0I= MIME-Version: 1.0 Received: by 10.52.66.40 with SMTP id c8mr1578668vdt.21.1313966959365; Sun, 21 Aug 2011 15:49:19 -0700 (PDT) Received: by 10.52.111.10 with HTTP; Sun, 21 Aug 2011 15:49:19 -0700 (PDT) In-Reply-To: <20110820230510.4363cefc@fabiankeil.de> References: <20110820230510.4363cefc@fabiankeil.de> Date: Mon, 22 Aug 2011 08:49:19 +1000 Message-ID: From: Ashley Williams To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: dtrace walltimestamp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 22:49:20 -0000 On Sun, Aug 21, 2011 at 7:05 AM, Fabian Keil wrote: > > Ashley Williams wrote: > > > walltimestamp and timestamp don't appear to be right in BETA-1: > > > > > > # dtrace -qn 'syscall::exec*:return { printf("%Y > > %s\n",walltimestamp,curpsinfo->pr_psargs); }' > > 1970 Jan =A01 10:00:00 date > > 1970 Jan =A01 10:00:00 ping > > 1970 Jan =A01 10:00:00 ls > > I can reproduce this on amd64 with a recent HEAD, walltimestamp > is always 0, which together with the dmesg warnings seems to indicate > that it's not supported (yet). Bug report has been filed - thanks for testing. PR -=A0159612 for those interested. > > > # dtrace -qn 'syscall::exec*:return { printf("%Y > > %s\n",timestamp,curpsinfo->pr_psargs); }' > > 1970 Jan =A06 12:02:27 ping > > 1970 Jan =A06 12:02:29 ls > > 1970 Jan =A06 12:02:31 dtrace > > Note that the timestamp value is relative to the time > the system is booted (I think), and not to midnight, > January 1, 1970. > > Assuming your system has been running for a few days > and the offsets are right as well, the output seems fine. Thanks for that - I did some testing on Solaris 11 and it's evident I have misunderstood the usage of the timestamp function.=A0The output above, as you said, is definitely correct. From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 23:11:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93641106566B; Sun, 21 Aug 2011 23:11:07 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 635B48FC13; Sun, 21 Aug 2011 23:11:07 +0000 (UTC) Received: from dhcp-192-168-2-22.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p7LNB0Im062231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Aug 2011 16:11:06 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4E517978.2020705@freebsd.org> Date: Sun, 21 Aug 2011 16:11:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1244.3) Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 23:11:07 -0000 On Aug 21, 2011, at 2:32 PM, Nathan Whitehorn wrote: >=20 > gpart does not support (well, anyway) changing the underlying = partition table format without committing changes. Replacing the = partition scheme, which this does, is such an operation. Weird. I could always destroy tables, create new ones using a different scheme and populate it with partitions without there being a single write to disk. The commit/undo logic worked just as well for those operations as the simpler ones. Did that get broken or are you just mistaken? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 20:00:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9BCB106566C; Sun, 21 Aug 2011 20:00:59 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id BC00D8FC08; Sun, 21 Aug 2011 20:00:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=KOI8-R; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQA00I02NLNOE00@smtpauth3.wiscmail.wisc.edu>; Sun, 21 Aug 2011 15:00:59 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQA00F5RNLLHZ10@smtpauth3.wiscmail.wisc.edu>; Sun, 21 Aug 2011 15:00:58 -0500 (CDT) Date: Sun, 21 Aug 2011 15:00:56 -0500 From: Nathan Whitehorn In-reply-to: To: Kevin Oberman Message-id: <4E5163F8.2060706@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-10, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.21.194814, SenderIP=76.210.68.180 References: <927966496.20110820112229@serebryakov.spb.ru> <4E513802.9090306@freebsd.org> <569113961.20110821222424@serebryakov.spb.ru> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 X-Mailman-Approved-At: Sun, 21 Aug 2011 23:30:49 +0000 Cc: lev@freebsd.org, freebsd-current@freebsd.org Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 20:01:00 -0000 On 08/21/11 14:41, Kevin Oberman wrote: > 2011/8/21 Lev Serebryakov: >> Hello, Nathan. >> You wrote 21 Á×ÇÕÓÔÁ 2011 Ç., 20:53:22: >> >>> GPT is bootable on all x86 systems, with either EFI or BIOS, and is now >> Ok, I was not sure here. > The Wikipedia article on GUID Partition Table states that Windows only supports > GPT boot when the system is a EFI system and is 64-bit Windows, Vista or newer. > Windows-32 will not boot from a GPT disk. > > I know Wikipedia is not always right, but it matches my limited experience. > > https://secure.wikimedia.org/wikipedia/en/wiki/GUID_Partition_Table We do EFI boot differently from Windows, using a PMBR bootstrap. This means it will work even on a 386 (in principle: I don't really want to dig out my 386 to check). -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Aug 21 23:49:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D0C11065672; Sun, 21 Aug 2011 23:49:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 46E358FC14; Sun, 21 Aug 2011 23:49:01 +0000 (UTC) Received: by iye7 with SMTP id 7so18047944iye.17 for ; Sun, 21 Aug 2011 16:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fYiTNQVEVlcZ/ZmoCdmBA1Ne+2iGPSrs/+tZ3wXmG+E=; b=M4gyPKorjWIhcvV/HXYNRWO7jz3zcH4TNnxfhAV1JmU1WlrW7w9U71R1BNqHK/EQKr vCsE7x0g7d5hUfUavHBDkPrEOE/A8iiYjFKSB/AZfHagVIv9O3Z6So02jn26XI5xBhyj Iui3T0kZmw1p776CU/hcZaepnTt4Pptoq0RK0= Received: by 10.42.159.194 with SMTP id m2mr2095415icx.83.1313970540509; Sun, 21 Aug 2011 16:49:00 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id a9sm3057908ibi.9.2011.08.21.16.48.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 16:48:59 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 21 Aug 2011 16:48:56 -0700 From: YongHyeon PYUN Date: Sun, 21 Aug 2011 16:48:56 -0700 To: Garrett Cooper Message-ID: <20110821234856.GB1755@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 23:49:01 -0000 On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: > On Thu, Aug 18, 2011 at 9:31 PM, wrote: > > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote: > >> ? ?When loading if_alc as a module on my netbook and running > >> /etc/rc.d/netif restart, I can deterministically panic my netbook with > >> the following message: > > These repro steps were overly simplified. The complete steps are: > > 1. Attach ethernet cable to alc(4) enabled NIC. > 2. Boot up machine. > 3. Login. > 4. Physically remove ethernet cable from alc(4) enabled NIC. > 5. Run `/etc/rc.d/netif restart' as root. > I can't reproduce this with AR8151 sample board. Could you give me dmesg output to know exact controller revision? One issue I'm aware of is lack of re-establishing link when controller firmware put its PHY to deep sleep mode. The deep sleep mode seems to be automatically activated by firmware when it detects no energy signal(i.e. cable unplugged) so I had to down and up the interface again to take the PHY out of the sleep mode. > >> ) at _bus_dmamap_sync+0x51 > >> alc_stop(c3dbb000,0,c0c51844,93a,80206910,...) at alc_stop+0x24e > >> alc_ioctl(c3d07400,80206910,c40423c0,c06a7935,c0914e3c,...) at alc_ioctl+0x22e > >> ifioctl(c45029c0,80206910,c40423c0,c40505c0,c4528c00,...) at ifioctl+0xc98 > >> soo_ioctl(c4574e00,80206910,c40423c0,c413e680,c40505c0,...) at soo_ioctl+0x401 > >> kern_ioctl(c40505c0,3,80206910,c40423c0,c40423c0,...) at kern_ioctl+0x1d7 > >> ioctl(c40505c0,e6ca3cec,e6ca3d28,c08e929d,0,...) at ioctl+0x118 > >> syscallenter(c40505c0,e6ca3ce4,e6ca3ce4,0,0,...) at syscallenter+0x23f > >> syscall(e6ca3d28) at syscall+0x2e > >> Xint0x80_syscall() at Xint0x80_syscall+0x21 > >> --- syscall (54kernel trap 12 with interrupts disabled > >> Kernel page fault with the following non-sleepable locks held: > >> exclusive sleep mutex alc0 (network driver) r = 0 (0xc3dbc608) locked > >> @ /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:2362 > >> KDB: stack backtrace: > >> db_trace_self_wrapper(c08e727a,80,6e726500,74206c65,20706172,...) at > >> db_trace_self_wrapper+0x26 > >> kdb_backtrace(93a,0,ffffffff,c0ad6114,e6ca323c,...) at kdb_backtrace+0x2a > >> _witness_debugger(c08e9f67,e6ca3250,4,1,0,...) at _witness_debugger+0x1e > >> witness_warn(5,0,c0924fe1,c097df50,c3e42b00,...) at witness_warn+0x1f1 > >> trap(e6ca32dc) at trap+0x15a > >> calltrap() at calltrap+0x6 > >> > >> ? ?I tried to track down what the exact issue was, but I got lost > >> (the locking sort of looks ok to me, but I'm still not an expert with > >> mutex(9)). > >> ? ?I still have the vmcore and can provide more helpful details when requested. > > > > The locking itself is almost certainly fine. ?The error message is not > > very helpful, but what went wrong was the page fault. ?You just happen > > to panic on a witness warning before vm_fault can panic due to a bad > > address. > > > > The alc(4) maintainer would probably like info on the trap (line of > > code and where the bad pointer came from). > > I talked to Xin a bit and as he noted the panic was just a symptom > of the actual issue at hand. I think the problem is that the rx ring's > rx_m value isn't set to NULL when an error occurred, but getting to > the exact problem at hand, the following call is failing: > > if (bus_dmamap_load_mbuf_sg(sc->alc_cdata.alc_rx_tag, // <-- HERE > sc->alc_cdata.alc_rx_sparemap, m, segs, &nsegs, 0) != 0) { > m_freem(m); > return (ENOBUFS); > } > > It's failing with ENOMEM. Still trying to determine what the exact Even if bus_dmamap_load_mbuf_sg(9) fails driver should not panic. Could you show me full back-trace? > reason for ENOMEM is from the x86 busdma code though.. > Thanks, > -Garrett > From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 00:00:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8938106564A for ; Mon, 22 Aug 2011 00:00:22 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id AB56F8FC15 for ; Mon, 22 Aug 2011 00:00:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQA00100YOL5O00@smtpauth2.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 21 Aug 2011 19:00:21 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQA00AQEYOKLB30@smtpauth2.wiscmail.wisc.edu>; Sun, 21 Aug 2011 19:00:21 -0500 (CDT) Date: Sun, 21 Aug 2011 19:00:19 -0500 From: Nathan Whitehorn In-reply-to: <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> To: Marcel Moolenaar Message-id: <4E519C13.4060700@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-9, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.21.235114, SenderIP=76.210.68.180 References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 00:00:22 -0000 On 08/21/11 18:11, Marcel Moolenaar wrote: > On Aug 21, 2011, at 2:32 PM, Nathan Whitehorn wrote: >> gpart does not support (well, anyway) changing the underlying partition table format without committing changes. Replacing the partition scheme, which this does, is such an operation. > Weird. I could always destroy tables, create new ones using a > different scheme and populate it with partitions without there > being a single write to disk. The commit/undo logic worked > just as well for those operations as the simpler ones. Did that > get broken or are you just mistaken? > No, it's stupider than that. When you destroy a gpart without committing, the GEOM itself lingers as a (none)-type partitioning. This of course makes sense, since that ghost geom is what is maintaining all the state, but sometimes causes problems. For instance, it breaks some of my lazy code that identifies non-partitioned disks by seeing if there is a GEOM there. But, while slightly more complicated to detect, this would not be too difficult to fix. The larger problem is that this behavior means that destroying gparts sometimes doesn't work at all. For instance, if you have nested partitioning like MBR+BSD (or EBR) it is not possible to destroy the underlying MBR geom without committing the destruction of the BSD geom. This is because the MBR geom cannot be destroyed, even without committing, while it continues to have children, which it does due to the ghost geom for the BSD slice. The regular partitioning editor only commits early in this particular case, and asks about each subpartition tree separately with a big scary dialog box. In the spirit of the autopartitioner, it makes one large scary dialog, and always runs in early commit mode instead of potentially showing many scary dialogs about partitions the user doesn't necessarily even know about. This behavior could be changed, but I think is the most friendly for the case in question: namely, "I want to blow away everything and let the installer handle all partitioning details by itself". -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 00:04:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA89106566B; Mon, 22 Aug 2011 00:04:47 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C640E8FC13; Mon, 22 Aug 2011 00:04:46 +0000 (UTC) Received: by qyk9 with SMTP id 9so2310773qyk.13 for ; Sun, 21 Aug 2011 17:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+x4tu9h4+QCGrzzV4OOV0mbek3kG3yCaCgnvIuDP5Og=; b=A/yXmRsS/rxNKx+kMeVGA5J1aZSWuoRbtN1+0WtX0fkrvWPXC5p+Kd6wPYGLHDclIC u+ZQjLg2DFWEptxg70HQubj2Du2PF4tnTPr2rueAPXFckeK9v2Za4eOSj8vBdM53qnBQ CQCzr7RBtbpF3etEoN+gQ+c85unty6YfLkyP8= MIME-Version: 1.0 Received: by 10.224.200.3 with SMTP id eu3mr941919qab.279.1313971485684; Sun, 21 Aug 2011 17:04:45 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Sun, 21 Aug 2011 17:04:45 -0700 (PDT) In-Reply-To: <4E519C13.4060700@freebsd.org> References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> Date: Sun, 21 Aug 2011 17:04:45 -0700 Message-ID: From: Garrett Cooper To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 00:04:47 -0000 On Sun, Aug 21, 2011 at 5:00 PM, Nathan Whitehorn wrote: > On 08/21/11 18:11, Marcel Moolenaar wrote: >> >> On Aug 21, 2011, at 2:32 PM, Nathan Whitehorn wrote: >>> >>> gpart does not support (well, anyway) changing the underlying partition >>> table format without committing changes. Replacing the partition scheme= , >>> which this does, is such an operation. >> >> Weird. I could always destroy tables, create new ones using a >> different scheme and populate it with partitions without there >> being a single write to disk. The commit/undo logic worked >> just as well for those operations as the simpler ones. Did that >> get broken or are you just mistaken? >> > > No, it's stupider than that. When you destroy a gpart without committing, > the GEOM itself lingers as a (none)-type partitioning. This of course mak= es > sense, since that ghost geom is what is maintaining all the state, but > sometimes causes problems. For instance, it breaks some of =A0my lazy cod= e > that identifies non-partitioned disks by seeing if there is a GEOM there. > But, while slightly more complicated to detect, this would not be too > difficult to fix. > > The larger problem is that this behavior means that destroying gparts > sometimes doesn't work at all. For instance, if you have nested partition= ing > like MBR+BSD (or EBR) it is not possible to destroy the underlying MBR ge= om > without committing the destruction of the BSD geom. This is because the M= BR > geom cannot be destroyed, even without committing, while it continues to > have children, which it does due to the ghost geom for the BSD slice. > > The regular partitioning editor only commits early in this particular cas= e, > and asks about each subpartition tree separately with a big scary dialog > box. In the spirit of the autopartitioner, it makes one large scary dialo= g, > and always runs in early commit mode instead of potentially showing many > scary dialogs about partitions the user doesn't necessarily even know abo= ut. > This behavior could be changed, but I think is the most friendly for the > case in question: namely, "I want to blow away everything and let the > installer handle all partitioning details by itself". I think that adding more bold text would better underline the fact that you _are_ in fact going to blow away your partition tables.. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 01:12:48 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E81E106564A; Mon, 22 Aug 2011 01:12:48 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B13E8FC0A; Mon, 22 Aug 2011 01:12:46 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7M1CY0u021610; Mon, 22 Aug 2011 10:12:44 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7M1CYh5014540; Mon, 22 Aug 2011 10:12:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 22 Aug 2011 10:11:30 +0900 (JST) Message-Id: <20110822.101130.49645857563136267.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> References: <20110820.142859.319295417241413417.hrs@allbsd.org> <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Aug_22_10_11_30_2011_622)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 22 Aug 2011 10:12:45 +0900 (JST) X-Spam-Status: No, score=-104.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_VERTICALLINE,RDNS_NONE,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: pjd@FreeBSD.org, current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:12:48 -0000 ----Security_Multipart0(Mon_Aug_22_10_11_30_2011_622)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_22_10_11_30_2011_156)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Aug_22_10_11_30_2011_156)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rick, Rick Macklem wrote in <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca>: rm> Hiroki, could you please test the attached patch. rm> rm> One problem with this patch is that I don't know how to create a fixed rm> table that matches what systems would already have been getting. rm> (I got the first 6 entries by booting a GENERIC i386 kernel with a rm> printf in vfs_init(), so I suspect those don't change much, although rm> I'm not sure if ZFS will usually end up before or after them?) rm> rm> Do you guys know what ZFS gets assigned typically? (I realize that rm> changes w.r.t. when it gets loaded, so the question also becomes rm> "do you know how it typically gets loaded" so the table can have rm> that vfc_typenum value assigned to it?) rm> Maybe you could boot a system with a printf like: rm> rm> printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum); rm> rm> just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and rm> then look in dmesg after booting, to see what your tables look like? rm> (Without the attached patch installed.) rm> rm> Thanks, rick rm> ps: The patch is also at rm> http://people.freebsd.org/~rmacklem/fsid.patch for anyone on rm> the list interested (if the attachment doesn't make it through. rm> rm> rm> rick Yes, we can think the typical number of zfs is 7 on GENERIC. However, I checked vfc_typenum in three boxes around me by using the attached patch for lsvfs(1), but the results were not consistent: Machine A (8-STABLE) | |Filesystem Num Refs Flags |-------------------------------- --- ----- --------------- |msdosfs 1 0 |procfs 2 0 synthetic |devfs 3 4 synthetic |cd9660 4 0 read-only |nfs 5 2 network |ufs 6 6 Machine B (HEAD with newnfs complied) | |Filesystem Num Refs Flags |-------------------------------- --- ----- --------------- |msdosfs 1 0 |ufs 2 5 |nfs 3 0 network |cd9660 4 0 read-only |procfs 5 0 synthetic |devfs 6 1 synthetic |zfs 7 1 jail, delegated-administration | Machine C (HEAD with oldnfs compiled) | |Filesystem Num Refs Flags |-------------------------------- --- ----- --------------- |ufs 1 3 |msdosfs 3 0 |procfs 4 0 synthetic |devfs 5 1 synthetic |oldnfs 6 0 network |cd9660 7 0 read-only |zfs 8 4 jail, delegated-administration |nfs 9 1 network I guess the ordering is timing-dependent and consistent only in the same box. The result of the Machine C was changed like the following after applying the patch. It worked as expected: |Filesystem Num Refs Flags |-------------------------------- --- ----- --------------- |ufs 2 3 |oldnfs 15 0 network |zfs 7 4 jail, delegated-administration |devfs 4 1 synthetic |msdosfs 5 0 |nfs 6 0 network |cd9660 1 0 read-only |procfs 3 0 synthetic Hmm, based on these results it looks difficult to assign the same number to each file system. Anyway, not fixing them is worse, so we may have to accept this as a small upgrade bump in 9.0R. -- Hiroki ----Next_Part(Mon_Aug_22_10_11_30_2011_156)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lsvfs-20110822-1.diff" Index: usr.bin/lsvfs/lsvfs.1 =================================================================== --- usr.bin/lsvfs/lsvfs.1 (revision 225066) +++ usr.bin/lsvfs/lsvfs.1 (working copy) @@ -2,7 +2,7 @@ .\" Garrett A. Wollman, September 1994 .\" This file is in the public domain. .\" -.Dd March 16, 1995 +.Dd August 22, 2011 .Dt LSVFS 1 .Os .Sh NAME @@ -36,6 +36,8 @@ .Fl t option to .Xr mount 8 +.It Num +the filesystem type number. .It Refs the number of references to this VFS; i.e., the number of currently mounted file systems of this type Index: usr.bin/lsvfs/lsvfs.c =================================================================== --- usr.bin/lsvfs/lsvfs.c (revision 225066) +++ usr.bin/lsvfs/lsvfs.c (working copy) @@ -17,9 +17,9 @@ #include #include -#define FMT "%-32.32s %5d %s\n" -#define HDRFMT "%-32.32s %5.5s %s\n" -#define DASHES "-------------------------------- ----- ---------------\n" +#define FMT "%-32.32s %3d %5d %s\n" +#define HDRFMT "%-32.32s %3s %5.5s %s\n" +#define DASHES "-------------------------------- --- ----- ---------------\n" static const char *fmt_flags(int); @@ -31,13 +31,14 @@ size_t buflen; argc--, argv++; - printf(HDRFMT, "Filesystem", "Refs", "Flags"); + printf(HDRFMT, "Filesystem", "Num", "Refs", "Flags"); fputs(DASHES, stdout); if(argc) { for(; argc; argc--, argv++) { if (getvfsbyname(*argv, &vfc) == 0) { - printf(FMT, vfc.vfc_name, vfc.vfc_refcount, fmt_flags(vfc.vfc_flags)); + printf(FMT, vfc.vfc_name, vfc.vfc_refcount, vfc.vfc_typenum, + fmt_flags(vfc.vfc_flags)); } else { warnx("VFS %s unknown or not loaded", *argv); rv++; @@ -54,8 +55,8 @@ cnt = buflen / sizeof(struct xvfsconf); for (i = 0; i < cnt; i++) { - printf(FMT, xvfsp[i].vfc_name, xvfsp[i].vfc_refcount, - fmt_flags(xvfsp[i].vfc_flags)); + printf(FMT, xvfsp[i].vfc_name, xvfsp[i].vfc_typenum, + xvfsp[i].vfc_refcount, fmt_flags(xvfsp[i].vfc_flags)); } free(xvfsp); } ----Next_Part(Mon_Aug_22_10_11_30_2011_156)---- ----Security_Multipart0(Mon_Aug_22_10_11_30_2011_622)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5RrMIACgkQTyzT2CeTzy2WYwCfXknnBZRAFm9Hzu4qUsklr01N ajEAn2LOzAbNni8wQ/s0RCkZTnpSzJus =/TXR -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Aug_22_10_11_30_2011_622)---- From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 01:28:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFC86106564A; Mon, 22 Aug 2011 01:28:36 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2758FC08; Mon, 22 Aug 2011 01:28:35 +0000 (UTC) Received: from dhcp-192-168-2-22.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p7M1STdZ062615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Aug 2011 18:28:35 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Marcel Moolenaar In-Reply-To: <4E519C13.4060700@freebsd.org> Date: Sun, 21 Aug 2011 18:28:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1244.3) Cc: "freebsd-current@FreeBSD.org Current" Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:28:36 -0000 On Aug 21, 2011, at 5:00 PM, Nathan Whitehorn wrote: >=20 > No, it's stupider than that. When you destroy a gpart without = committing, the GEOM itself lingers as a (none)-type partitioning. This = of course makes sense, since that ghost geom is what is maintaining all = the state, but sometimes causes problems. For instance, it breaks some = of my lazy code that identifies non-partitioned disks by seeing if = there is a GEOM there. But, while slightly more complicated to detect, = this would not be too difficult to fix. What if gpart always creates the null scheme if no partitioning exists = on the media? Then the difference between none but uncomitted and just plain = none is gone and we can always make sure the distinction is represented in the = XML. This would also improve the current behavior of "gpart show" in that you = don't get to see any disks that don't have partitions right now. > The larger problem is that this behavior means that destroying gparts = sometimes doesn't work at all. For instance, if you have nested = partitioning like MBR+BSD (or EBR) it is not possible to destroy the = underlying MBR geom without committing the destruction of the BSD geom. = This is because the MBR geom cannot be destroyed, even without = committing, while it continues to have children, which it does due to = the ghost geom for the BSD slice. Yup. It would be good if we can fix that=85 > The regular partitioning editor only commits early in this particular = case, and asks about each subpartition tree separately with a big scary = dialog box. In the spirit of the autopartitioner, it makes one large = scary dialog, and always runs in early commit mode instead of = potentially showing many scary dialogs about partitions the user doesn't = necessarily even know about. This behavior could be changed, but I think = is the most friendly for the case in question: namely, "I want to blow = away everything and let the installer handle all partitioning details by = itself". What about inserting a special class for doing commit/undo. The GEOM simply keeps all modifications in memory and 1) forgets everything on an undo operation or 2) writes all dirty sectors on a commit. This could be used even instead of the gpart-private support, which also removes the quirk for the null scheme. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 01:34:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 619D2106566C; Mon, 22 Aug 2011 01:34:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1BB28FC0C; Mon, 22 Aug 2011 01:34:23 +0000 (UTC) Received: by qwc9 with SMTP id 9so3671794qwc.13 for ; Sun, 21 Aug 2011 18:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wfllWerNDr+DMVuCu4M7AXF+ExZj64nb/3QLzbH7KE8=; b=dQaOalI359uv41U+qRZ001tRGLH1fgUmu/toPJO3oTneKLYHLyJoZxBWGACSwx/91E usxZvRseeITIA2cm2zuTk3Y8yCNY48rFS1jMLYQ6xJvWciE03+4q+ccGZhzXyeHc9vNR niW4ikLIugMiZsRuZ5QXxf6ywNXOyKJjalfks= MIME-Version: 1.0 Received: by 10.224.218.193 with SMTP id hr1mr1133198qab.29.1313976863294; Sun, 21 Aug 2011 18:34:23 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Sun, 21 Aug 2011 18:34:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 21 Aug 2011 18:34:23 -0700 Message-ID: From: Garrett Cooper To: Andriy Gapon , "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/sys/kern/kern_cons.c:420 when running dump in ddb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:34:24 -0000 On Thu, Aug 18, 2011 at 5:55 PM, Garrett Cooper wrote: > Hi, > =A0 =A0Long story short, I was running a UP kernel on a netbook trying to > stimulate a crash and when I did dump, it would periodically fail > non-recursive mutex failure with the output shown below (I caught it > once, but the other times the dump failed). This actually shows up when generating a panic via boot -v with WITNESS, so it's potentially a race condition on my laptop. Adding MTX_RECURSE to the mutex object didn't help things either. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 01:34:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04CC010656F4 for ; Mon, 22 Aug 2011 01:34:35 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id CC7EF8FC15 for ; Mon, 22 Aug 2011 01:34:34 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQB0000031MTD00@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Sun, 21 Aug 2011 20:34:34 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQB00MGL31KX400@smtpauth3.wiscmail.wisc.edu>; Sun, 21 Aug 2011 20:34:33 -0500 (CDT) Date: Sun, 21 Aug 2011 20:34:32 -0500 From: Nathan Whitehorn In-reply-to: To: Marcel Moolenaar Message-id: <4E51B228.7030001@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.22.12714, SenderIP=76.210.68.180 References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: "freebsd-current@FreeBSD.org Current" Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:34:35 -0000 On 08/21/11 20:28, Marcel Moolenaar wrote: > On Aug 21, 2011, at 5:00 PM, Nathan Whitehorn wrote: >> No, it's stupider than that. When you destroy a gpart without committing, the GEOM itself lingers as a (none)-type partitioning. This of course makes sense, since that ghost geom is what is maintaining all the state, but sometimes causes problems. For instance, it breaks some of my lazy code that identifies non-partitioned disks by seeing if there is a GEOM there. But, while slightly more complicated to detect, this would not be too difficult to fix. > What if gpart always creates the null scheme if no partitioning exists on the > media? Then the difference between none but uncomitted and just plain none is > gone and we can always make sure the distinction is represented in the XML. > This would also improve the current behavior of "gpart show" in that you don't > get to see any disks that don't have partitions right now. That would work, but really the difference is quite small. I just went through and fixed the remaining instances of this brokenness in my code. There were 2, and it took 5 minutes, so I wouldn't worry about it. >> The larger problem is that this behavior means that destroying gparts sometimes doesn't work at all. For instance, if you have nested partitioning like MBR+BSD (or EBR) it is not possible to destroy the underlying MBR geom without committing the destruction of the BSD geom. This is because the MBR geom cannot be destroyed, even without committing, while it continues to have children, which it does due to the ghost geom for the BSD slice. > Yup. It would be good if we can fix that… > >> The regular partitioning editor only commits early in this particular case, and asks about each subpartition tree separately with a big scary dialog box. In the spirit of the autopartitioner, it makes one large scary dialog, and always runs in early commit mode instead of potentially showing many scary dialogs about partitions the user doesn't necessarily even know about. This behavior could be changed, but I think is the most friendly for the case in question: namely, "I want to blow away everything and let the installer handle all partitioning details by itself". > What about inserting a special class for doing commit/undo. The GEOM > simply keeps all modifications in memory and 1) forgets everything on > an undo operation or 2) writes all dirty sectors on a commit. This > could be used even instead of the gpart-private support, which also > removes the quirk for the null scheme. > Where would this class go? If it went below gpart (between gpart and userland), then it seems like we would lose the ability of gpart to validate its parameters. Who would be responsible for inserting this GEOM into the stack? -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 01:48:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EDA7106566B; Mon, 22 Aug 2011 01:48:09 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 38FB38FC1F; Mon, 22 Aug 2011 01:48:08 +0000 (UTC) Received: from dhcp-192-168-2-22.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p7M1lwot062687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Aug 2011 18:48:08 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Marcel Moolenaar In-Reply-To: <4E51B228.7030001@freebsd.org> Date: Sun, 21 Aug 2011 18:48:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1244.3) Cc: "freebsd-current@FreeBSD.org Current" Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:48:09 -0000 On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>=20 >>> The regular partitioning editor only commits early in this = particular case, and asks about each subpartition tree separately with a = big scary dialog box. In the spirit of the autopartitioner, it makes one = large scary dialog, and always runs in early commit mode instead of = potentially showing many scary dialogs about partitions the user doesn't = necessarily even know about. This behavior could be changed, but I think = is the most friendly for the case in question: namely, "I want to blow = away everything and let the installer handle all partitioning details by = itself". >> What about inserting a special class for doing commit/undo. The GEOM >> simply keeps all modifications in memory and 1) forgets everything on >> an undo operation or 2) writes all dirty sectors on a commit. This >> could be used even instead of the gpart-private support, which also >> removes the quirk for the null scheme. >>=20 >=20 > Where would this class go? If it went below gpart (between gpart and = userland), then it seems like we would lose the ability of gpart to = validate its parameters. Who would be responsible for inserting this = GEOM into the stack? Between the disk GEOM and the gpart GEOM. The gpart utility would still interact with the GEOM is before. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 01:55:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B8D7106566B; Mon, 22 Aug 2011 01:55:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BFF248FC0A; Mon, 22 Aug 2011 01:55:09 +0000 (UTC) Received: by gxk28 with SMTP id 28so3694255gxk.13 for ; Sun, 21 Aug 2011 18:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zWiSvDCK6UU1OEsE8htQZkNFJ9uaQfHhW6u0pSjnsDA=; b=Zlwx1hnJnke2urQHMKyoAX3r+3ZXLsOOMgtlzS25KEdVRDscraFIO96e9Azn4nBreI NKN0sf3vTN8kM98suZrgLREu3wYawDHyYJsS7kRjjYfzA6/92+nVI2YlS4cnLsuq7Z21 CnsD5NHxKPMOWtIe6P0Momo4Bx7VfFiJITC+g= Received: by 10.150.48.27 with SMTP id v27mr1895728ybv.95.1313978109019; Sun, 21 Aug 2011 18:55:09 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 9sm2958614ybb.16.2011.08.21.18.55.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 18:55:08 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 21 Aug 2011 18:55:02 -0700 From: YongHyeon PYUN Date: Sun, 21 Aug 2011 18:55:02 -0700 To: Garrett Cooper Message-ID: <20110822015502.GE1755@michelle.cdnetworks.com> References: <20110821234856.GB1755@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:55:10 -0000 On Sun, Aug 21, 2011 at 06:26:45PM -0700, Garrett Cooper wrote: > On Sun, Aug 21, 2011 at 4:48 PM, YongHyeon PYUN wrote: > > On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: > >> On Thu, Aug 18, 2011 at 9:31 PM, ? wrote: > >> > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote: > >> >> ? ?When loading if_alc as a module on my netbook and running > >> >> /etc/rc.d/netif restart, I can deterministically panic my netbook with > >> >> the following message: > >> > >> ? ? These repro steps were overly simplified. The complete steps are: > >> > >> 1. Attach ethernet cable to alc(4) enabled NIC. > >> 2. Boot up machine. > >> 3. Login. > >> 4. Physically remove ethernet cable from alc(4) enabled NIC. > >> 5. Run `/etc/rc.d/netif restart' as root. > >> > > > > I can't reproduce this with AR8151 sample board. Could you give me > > dmesg output to know exact controller revision? > > One issue I'm aware of is lack of re-establishing link when > > controller firmware put its PHY to deep sleep mode. ?The deep sleep > > mode seems to be automatically activated by firmware when it > > detects no energy signal(i.e. cable unplugged) so I had to down and > > up the interface again to take the PHY out of the sleep mode. > > > >> >> ) at _bus_dmamap_sync+0x51 > >> >> alc_stop(c3dbb000,0,c0c51844,93a,80206910,...) at alc_stop+0x24e > >> >> alc_ioctl(c3d07400,80206910,c40423c0,c06a7935,c0914e3c,...) at alc_ioctl+0x22e > >> >> ifioctl(c45029c0,80206910,c40423c0,c40505c0,c4528c00,...) at ifioctl+0xc98 > >> >> soo_ioctl(c4574e00,80206910,c40423c0,c413e680,c40505c0,...) at soo_ioctl+0x401 > >> >> kern_ioctl(c40505c0,3,80206910,c40423c0,c40423c0,...) at kern_ioctl+0x1d7 > >> >> ioctl(c40505c0,e6ca3cec,e6ca3d28,c08e929d,0,...) at ioctl+0x118 > >> >> syscallenter(c40505c0,e6ca3ce4,e6ca3ce4,0,0,...) at syscallenter+0x23f > >> >> syscall(e6ca3d28) at syscall+0x2e > >> >> Xint0x80_syscall() at Xint0x80_syscall+0x21 > >> >> --- syscall (54kernel trap 12 with interrupts disabled > >> >> Kernel page fault with the following non-sleepable locks held: > >> >> exclusive sleep mutex alc0 (network driver) r = 0 (0xc3dbc608) locked > >> >> @ /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:2362 > >> >> KDB: stack backtrace: > >> >> db_trace_self_wrapper(c08e727a,80,6e726500,74206c65,20706172,...) at > >> >> db_trace_self_wrapper+0x26 > >> >> kdb_backtrace(93a,0,ffffffff,c0ad6114,e6ca323c,...) at kdb_backtrace+0x2a > >> >> _witness_debugger(c08e9f67,e6ca3250,4,1,0,...) at _witness_debugger+0x1e > >> >> witness_warn(5,0,c0924fe1,c097df50,c3e42b00,...) at witness_warn+0x1f1 > >> >> trap(e6ca32dc) at trap+0x15a > >> >> calltrap() at calltrap+0x6 > >> >> > >> >> ? ?I tried to track down what the exact issue was, but I got lost > >> >> (the locking sort of looks ok to me, but I'm still not an expert with > >> >> mutex(9)). > >> >> ? ?I still have the vmcore and can provide more helpful details when requested. > >> > > >> > The locking itself is almost certainly fine. ?The error message is not > >> > very helpful, but what went wrong was the page fault. ?You just happen > >> > to panic on a witness warning before vm_fault can panic due to a bad > >> > address. > >> > > >> > The alc(4) maintainer would probably like info on the trap (line of > >> > code and where the bad pointer came from). > >> > >> ? ? I talked to Xin a bit and as he noted the panic was just a symptom > >> of the actual issue at hand. I think the problem is that the rx ring's > >> rx_m value isn't set to NULL when an error occurred, but getting to > >> the exact problem at hand, the following call is failing: > >> > >> ? ? ? ? if (bus_dmamap_load_mbuf_sg(sc->alc_cdata.alc_rx_tag, // <-- HERE > >> ? ? ? ? ? ? sc->alc_cdata.alc_rx_sparemap, m, segs, &nsegs, 0) != 0) { > >> ? ? ? ? ? ? ? ? m_freem(m); > >> ? ? ? ? ? ? ? ? return (ENOBUFS); > >> ? ? ? ? } > >> > >> ? ? It's failing with ENOMEM. Still trying to determine what the exact > > > > Even if bus_dmamap_load_mbuf_sg(9) fails driver should not panic. > > Could you show me full back-trace? > > I tried to hack the kernel to get it to dump properly, but that > inevitably failed (one of the buffers or the stack data associated > probably got stomped on when the system panicked). > Here are some pics. Thanks a lot. I see that alc(4) failed to allocate RX buffers and it seems the panic happened in alc_stop(). But I can't understand how it could be triggered. When RX buffer allocation failed, the mbuf pointer would have been NULL such that bus_dmamap_sync(9) wouldn't be invoked in alc_stop(). I also see you have wireless network setup in the back trace. Could you also reproduce alc(4) panic without wireless network configuration? > Thanks, > -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 02:02:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51048106564A; Mon, 22 Aug 2011 02:02:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB87C8FC08; Mon, 22 Aug 2011 02:02:28 +0000 (UTC) Received: by yib19 with SMTP id 19so3705134yib.13 for ; Sun, 21 Aug 2011 19:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=heSWDkDEt0HPut4F0ZF5brD3xE23pNXKr1/lqLUpIj8=; b=Nh8zc7WM03AoSF+WeYjztfw2EHuEGOhx+RzzLImcNFqdysB4IycvPZQjdrn5bJ8Cry Mp+wY8VbQ6gKO2UZGjnWSmclX2NOusELo6tZ7ToJrwNcpDPfIaeAC53GghmO8Uj8DkSR +PnzmEuO8XviNRlWwNXU9GsiuYouR73a/c3tM= MIME-Version: 1.0 Received: by 10.150.133.17 with SMTP id g17mr1087344ybd.272.1313978548181; Sun, 21 Aug 2011 19:02:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Sun, 21 Aug 2011 19:02:27 -0700 (PDT) In-Reply-To: <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> Date: Mon, 22 Aug 2011 10:02:27 +0800 X-Google-Sender-Auth: Yxld9xvYdTTJbat_U1S5rAZ__9o Message-ID: From: Adrian Chadd To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@FreeBSD.org Current" , Nathan Whitehorn Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 02:02:29 -0000 Honestly - if you're relying on doing anything that isn't read-only w/ GEOM right until "commit", I think you're doing it wrong. If anything, you should write something which manipulates geom tables in userland, and can have a geom database populated from the kernel. All of your subsequent tools (eg stuff which creates labels, raid devices, etc) should manipulate this table, not the kernel. Then when you're ready, you should write the updated table to disk. 2c, Adrian On 22 August 2011 09:48, Marcel Moolenaar wrote: > > On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>> >>>> The regular partitioning editor only commits early in this particular = case, and asks about each subpartition tree separately with a big scary dia= log box. In the spirit of the autopartitioner, it makes one large scary dia= log, and always runs in early commit mode instead of potentially showing ma= ny scary dialogs about partitions the user doesn't necessarily even know ab= out. This behavior could be changed, but I think is the most friendly for t= he case in question: namely, "I want to blow away everything and let the in= staller handle all partitioning details by itself". >>> What about inserting a special class for doing commit/undo. The GEOM >>> simply keeps all modifications in memory and 1) forgets everything on >>> an undo operation or 2) writes all dirty sectors on a commit. This >>> could be used even instead of the gpart-private support, which also >>> removes the quirk for the null scheme. >>> >> >> Where would this class go? If it went below gpart (between gpart and use= rland), then it seems like we would lose the ability of gpart to validate i= ts parameters. Who would be responsible for inserting this GEOM into the st= ack? > > Between the disk GEOM and the gpart GEOM. The gpart utility would > still interact with the GEOM is before. > > -- > Marcel Moolenaar > marcel@xcllnt.net > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 02:21:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E60F106566B; Mon, 22 Aug 2011 02:21:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 011F08FC13; Mon, 22 Aug 2011 02:21:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LQB00500575OC00@smtpauth1.wiscmail.wisc.edu>; Sun, 21 Aug 2011 21:21:05 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.180]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LQB004CT573IV00@smtpauth1.wiscmail.wisc.edu>; Sun, 21 Aug 2011 21:21:04 -0500 (CDT) Date: Sun, 21 Aug 2011 21:21:02 -0500 From: Nathan Whitehorn In-reply-to: To: Adrian Chadd Message-id: <4E51BD0E.7040204@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.180 X-Spam-PmxInfo: Server=avs-9, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.21.180314, SenderIP=76.210.68.180 References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 Cc: "freebsd-current@FreeBSD.org Current" , Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 02:21:06 -0000 Doing it that way is really, really error-prone, because you have to guess (a) whether gpart will accept certain configurations and (b) how it will handle requests. On some schemes, partititions have to be aligned or sized in particular ways and have various limitations. Depending on the module, gpart will either reject the request or silently adjust it. Letting the kernel handle the state means that the geom modules themselves get to decide this, and you can act on the result at the same time you request it. Doing it in userland means you need to guess, perfectly, all the time, what will happen with every input to every module, and so that you have a fully-functional perfect simulator of all possible behaviors and states of every type of partitioning that the kernel currently or may ever support. This tends not to work well. -Nathan On 08/21/11 21:02, Adrian Chadd wrote: > Honestly - if you're relying on doing anything that isn't read-only w/ > GEOM right until "commit", I think you're doing it wrong. > > If anything, you should write something which manipulates geom tables > in userland, and can have a geom database populated from the kernel. > All of your subsequent tools (eg stuff which creates labels, raid > devices, etc) should manipulate this table, not the kernel. > > Then when you're ready, you should write the updated table to disk. > > 2c, > > > Adrian > > On 22 August 2011 09:48, Marcel Moolenaar wrote: >> On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>>>> The regular partitioning editor only commits early in this particular case, and asks about each subpartition tree separately with a big scary dialog box. In the spirit of the autopartitioner, it makes one large scary dialog, and always runs in early commit mode instead of potentially showing many scary dialogs about partitions the user doesn't necessarily even know about. This behavior could be changed, but I think is the most friendly for the case in question: namely, "I want to blow away everything and let the installer handle all partitioning details by itself". >>>> What about inserting a special class for doing commit/undo. The GEOM >>>> simply keeps all modifications in memory and 1) forgets everything on >>>> an undo operation or 2) writes all dirty sectors on a commit. This >>>> could be used even instead of the gpart-private support, which also >>>> removes the quirk for the null scheme. >>>> >>> Where would this class go? If it went below gpart (between gpart and userland), then it seems like we would lose the ability of gpart to validate its parameters. Who would be responsible for inserting this GEOM into the stack? >> Between the disk GEOM and the gpart GEOM. The gpart utility would >> still interact with the GEOM is before. >> >> -- >> Marcel Moolenaar >> marcel@xcllnt.net >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 02:39:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7AA106566C; Mon, 22 Aug 2011 02:39:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 598D78FC0A; Mon, 22 Aug 2011 02:39:27 +0000 (UTC) Received: by qyk9 with SMTP id 9so2352122qyk.13 for ; Sun, 21 Aug 2011 19:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EE8cfPL8kTUJToHkWAF53jpaYrmH9GSRGoywbmypQqQ=; b=smOGp2o8al9usLTO/X1+yqx/CQm+k3zbVgS+DQHR0Mo0v7GcTWcsDD5Yk6en+wcoI1 gCXgBtvbU64dG6hUCc4oXtJyRNoB8ITdEkmt8lYbKWrl+l+SsZUQO3ASrP4cU1Y5eCgZ 9r3LKEX4FsqD5OKkRRcfo595Zb2SH0/AMU3HM= MIME-Version: 1.0 Received: by 10.224.204.198 with SMTP id fn6mr1108800qab.229.1313980766590; Sun, 21 Aug 2011 19:39:26 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Sun, 21 Aug 2011 19:39:26 -0700 (PDT) In-Reply-To: <20110822015502.GE1755@michelle.cdnetworks.com> References: <20110821234856.GB1755@michelle.cdnetworks.com> <20110822015502.GE1755@michelle.cdnetworks.com> Date: Sun, 21 Aug 2011 19:39:26 -0700 Message-ID: From: Garrett Cooper To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 02:39:27 -0000 On Sun, Aug 21, 2011 at 6:55 PM, YongHyeon PYUN wrote: > On Sun, Aug 21, 2011 at 06:26:45PM -0700, Garrett Cooper wrote: >> On Sun, Aug 21, 2011 at 4:48 PM, YongHyeon PYUN wrote= : >> > On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: >> >> On Thu, Aug 18, 2011 at 9:31 PM, ? wrote: >> >> > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote: >> >> >> ? ?When loading if_alc as a module on my netbook and running >> >> >> /etc/rc.d/netif restart, I can deterministically panic my netbook = with >> >> >> the following message: >> >> >> >> ? ? These repro steps were overly simplified. The complete steps are: >> >> >> >> 1. Attach ethernet cable to alc(4) enabled NIC. >> >> 2. Boot up machine. >> >> 3. Login. >> >> 4. Physically remove ethernet cable from alc(4) enabled NIC. >> >> 5. Run `/etc/rc.d/netif restart' as root. >> >> >> > >> > I can't reproduce this with AR8151 sample board. Could you give me >> > dmesg output to know exact controller revision? >> > One issue I'm aware of is lack of re-establishing link when >> > controller firmware put its PHY to deep sleep mode. ?The deep sleep >> > mode seems to be automatically activated by firmware when it >> > detects no energy signal(i.e. cable unplugged) so I had to down and >> > up the interface again to take the PHY out of the sleep mode. >> > >> >> >> ) at _bus_dmamap_sync+0x51 >> >> >> alc_stop(c3dbb000,0,c0c51844,93a,80206910,...) at alc_stop+0x24e >> >> >> alc_ioctl(c3d07400,80206910,c40423c0,c06a7935,c0914e3c,...) at alc= _ioctl+0x22e >> >> >> ifioctl(c45029c0,80206910,c40423c0,c40505c0,c4528c00,...) at ifioc= tl+0xc98 >> >> >> soo_ioctl(c4574e00,80206910,c40423c0,c413e680,c40505c0,...) at soo= _ioctl+0x401 >> >> >> kern_ioctl(c40505c0,3,80206910,c40423c0,c40423c0,...) at kern_ioct= l+0x1d7 >> >> >> ioctl(c40505c0,e6ca3cec,e6ca3d28,c08e929d,0,...) at ioctl+0x118 >> >> >> syscallenter(c40505c0,e6ca3ce4,e6ca3ce4,0,0,...) at syscallenter+0= x23f >> >> >> syscall(e6ca3d28) at syscall+0x2e >> >> >> Xint0x80_syscall() at Xint0x80_syscall+0x21 >> >> >> --- syscall (54kernel trap 12 with interrupts disabled >> >> >> Kernel page fault with the following non-sleepable locks held: >> >> >> exclusive sleep mutex alc0 (network driver) r =3D 0 (0xc3dbc608) l= ocked >> >> >> @ /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:2362 >> >> >> KDB: stack backtrace: >> >> >> db_trace_self_wrapper(c08e727a,80,6e726500,74206c65,20706172,...) = at >> >> >> db_trace_self_wrapper+0x26 >> >> >> kdb_backtrace(93a,0,ffffffff,c0ad6114,e6ca323c,...) at kdb_backtra= ce+0x2a >> >> >> _witness_debugger(c08e9f67,e6ca3250,4,1,0,...) at _witness_debugge= r+0x1e >> >> >> witness_warn(5,0,c0924fe1,c097df50,c3e42b00,...) at witness_warn+0= x1f1 >> >> >> trap(e6ca32dc) at trap+0x15a >> >> >> calltrap() at calltrap+0x6 >> >> >> >> >> >> ? ?I tried to track down what the exact issue was, but I got lost >> >> >> (the locking sort of looks ok to me, but I'm still not an expert w= ith >> >> >> mutex(9)). >> >> >> ? ?I still have the vmcore and can provide more helpful details wh= en requested. >> >> > >> >> > The locking itself is almost certainly fine. ?The error message is = not >> >> > very helpful, but what went wrong was the page fault. ?You just hap= pen >> >> > to panic on a witness warning before vm_fault can panic due to a ba= d >> >> > address. >> >> > >> >> > The alc(4) maintainer would probably like info on the trap (line of >> >> > code and where the bad pointer came from). >> >> >> >> ? ? I talked to Xin a bit and as he noted the panic was just a sympto= m >> >> of the actual issue at hand. I think the problem is that the rx ring'= s >> >> rx_m value isn't set to NULL when an error occurred, but getting to >> >> the exact problem at hand, the following call is failing: >> >> >> >> ? ? ? ? if (bus_dmamap_load_mbuf_sg(sc->alc_cdata.alc_rx_tag, // <-- = HERE >> >> ? ? ? ? ? ? sc->alc_cdata.alc_rx_sparemap, m, segs, &nsegs, 0) !=3D 0= ) { >> >> ? ? ? ? ? ? ? ? m_freem(m); >> >> ? ? ? ? ? ? ? ? return (ENOBUFS); >> >> ? ? ? ? } >> >> >> >> ? ? It's failing with ENOMEM. Still trying to determine what the exac= t >> > >> > Even if bus_dmamap_load_mbuf_sg(9) fails driver should not panic. >> > Could you show me full back-trace? >> >> =A0 =A0 I tried to hack the kernel to get it to dump properly, but that >> inevitably failed (one of the buffers or the stack data associated >> probably got stomped on when the system panicked). >> =A0 =A0 Here are some pics. > > Thanks a lot. I see that alc(4) failed to allocate RX buffers and > it seems the panic happened in alc_stop(). =A0But I can't understand > how it could be triggered. =A0When RX buffer allocation failed, the > mbuf pointer would have been NULL such that bus_dmamap_sync(9) > wouldn't be invoked in alc_stop(). > I also see you have wireless network setup in the back trace. Could > you also reproduce alc(4) panic without wireless network > configuration? Unfortunately disabling wireless and if_ath still yields the panic. -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:23:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F4A106566C; Mon, 22 Aug 2011 04:23:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id D9B518FC15; Mon, 22 Aug 2011 04:23:44 +0000 (UTC) Received: by yib19 with SMTP id 19so3753037yib.13 for ; Sun, 21 Aug 2011 21:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FX7DjBaZkz1PWJzi1uOtI1m9IY7otd3jT+atqFKjLxA=; b=Eu4/NxPFRowtT1YOOKSX6LRGeNAi1HX92RB9QQd2iiJY6W2yNGOp27oPO7slvsZUqB HrqAgNJGq2Qb5miiRDhlO+xOBQw7CsRkfUNrZ/IltXbeknTza+BND25t7cZR9/KcaOjZ PEwVje9WGbPtLQNlPAjYePb/22YWXw9lpB708= MIME-Version: 1.0 Received: by 10.150.133.17 with SMTP id g17mr1187574ybd.272.1313987023090; Sun, 21 Aug 2011 21:23:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Sun, 21 Aug 2011 21:23:43 -0700 (PDT) In-Reply-To: <4E51BD0E.7040204@freebsd.org> References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> <4E51BD0E.7040204@freebsd.org> Date: Mon, 22 Aug 2011 12:23:43 +0800 X-Google-Sender-Auth: v1lkQUb05CD8rdVVPMAnyn5rHEw Message-ID: From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@FreeBSD.org Current" , Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 04:23:45 -0000 I totally get it. However, an installer is user-facing (here), as well as system-facing. As much as I understand the logic behind it, it is still going to surprise people to find that their partition tables are modified at any point before that final "commit". Linux installers manage to do it. :-) Adrian On 22 August 2011 10:21, Nathan Whitehorn wrote: > Doing it that way is really, really error-prone, because you have to gues= s > (a) whether gpart will accept certain configurations and (b) how it will > handle requests. On some schemes, partititions have to be aligned or size= d > in particular ways and have various limitations. Depending on the module, > gpart will either reject the request or silently adjust it. Letting the > kernel handle the state means that the geom modules themselves get to dec= ide > this, and you can act on the result at the same time you request it. Doin= g > it in userland means you need to guess, perfectly, all the time, what wil= l > happen with every input to every module, and so that you have a > fully-functional perfect simulator of all possible behaviors and states o= f > every type of partitioning that the kernel currently or may ever support. > This tends not to work well. > -Nathan > > On 08/21/11 21:02, Adrian Chadd wrote: >> >> Honestly - if you're relying on doing anything that isn't read-only w/ >> GEOM right until "commit", I think you're doing it wrong. >> >> If anything, you should write something which manipulates geom tables >> in userland, and can have a geom database populated from the kernel. >> All of your subsequent tools (eg stuff which creates labels, raid >> devices, etc) should manipulate this table, not the kernel. >> >> Then when you're ready, you should write the updated table to disk. >> >> 2c, >> >> >> Adrian >> >> On 22 August 2011 09:48, Marcel Moolenaar =A0wrote: >>> >>> On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>>>>> >>>>>> The regular partitioning editor only commits early in this particula= r >>>>>> case, and asks about each subpartition tree separately with a big sc= ary >>>>>> dialog box. In the spirit of the autopartitioner, it makes one large= scary >>>>>> dialog, and always runs in early commit mode instead of potentially = showing >>>>>> many scary dialogs about partitions the user doesn't necessarily eve= n know >>>>>> about. This behavior could be changed, but I think is the most frien= dly for >>>>>> the case in question: namely, "I want to blow away everything and le= t the >>>>>> installer handle all partitioning details by itself". >>>>> >>>>> What about inserting a special class for doing commit/undo. The GEOM >>>>> simply keeps all modifications in memory and 1) forgets everything on >>>>> an undo operation or 2) writes all dirty sectors on a commit. This >>>>> could be used even instead of the gpart-private support, which also >>>>> removes the quirk for the null scheme. >>>>> >>>> Where would this class go? If it went below gpart (between gpart and >>>> userland), then it seems like we would lose the ability of gpart to va= lidate >>>> its parameters. Who would be responsible for inserting this GEOM into = the >>>> stack? >>> >>> Between the disk GEOM and the gpart GEOM. The gpart utility would >>> still interact with the GEOM is before. >>> >>> -- >>> Marcel Moolenaar >>> marcel@xcllnt.net >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:27:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB1F0106566B; Mon, 22 Aug 2011 04:27:27 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9708FC12; Mon, 22 Aug 2011 04:27:27 +0000 (UTC) X-AuditID: 12074423-b7b31ae000000a3c-45-4e51daaf0916 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.A7.02620.FAAD15E4; Mon, 22 Aug 2011 00:27:27 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p7M4RQRL023740; Mon, 22 Aug 2011 00:27:26 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7M4RNuE004056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Aug 2011 00:27:25 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7M4RNUg012621; Mon, 22 Aug 2011 00:27:23 -0400 (EDT) Date: Mon, 22 Aug 2011 00:27:23 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <917325587.123830.1313933050111.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixG6norv+VqCfwZk/GhYTrvxgsrg8dSmb xcNl15gcmD1mfJrP4vF7816mAKYoLpuU1JzMstQifbsEroyu13OYCxYJVFy+fJu5gfETTxcj J4eEgInE9XWtrBC2mMSFe+vZuhi5OIQE9jFKnN/wlBHC2cAo8WXPPyjnAJPE7MNboJwGRokD n56ygfSzCGhL/Lt0gwXEZhNQkZj5ZiNYXERAXWLz6n5mEJtZQEOi4eRMsLiwgILEhLvrmEBs TgF/ie6XS8BqeAUcJHZ3N4DZQgJ+Eq9294DdJyqgI7F6/xQWiBpBiZMzn7BAzLSUOPfnOtsE RsFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECA5bF+UdjH8O Kh1iFOBgVOLhfWAS6CfEmlhWXJl7iFGSg0lJlHfzVaAQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed6elUA53pTEyqrUonyYlDQHi5I4r8xOBz8hgfTEktTs1NSC1CKYrAwHh5IE74ebQI2CRanp qRVpmTklCGkmDk6Q4TxAw8+A1PAWFyTmFmemQ+RPMSpKifMeBUkIgCQySvPgemFp5RWjONAr wrwvQap4gCkJrvsV0GAmoMETVgaADC5JREhJNTCmMHKmT2u4Xyfz1ujnLHP/q2+kAytfla58 1xKWIfg2bLn1w8ULijhk1zO/eHI+3Wc+54a+jAdn7Ly9zBkDt9qc0Jn9OPsvzySfmQc7Z2o+ +H93EtvP+N9ZrYtO/jm27KOhyr795xMr2v6/T9DQ3rrrxOoXjn2HIzmVHfnz17yeFSNelfA5 nuW8EktxRqKhFnNRcSIAho3BAgYDAAA= Cc: pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 04:27:28 -0000 On Sun, 21 Aug 2011, Rick Macklem wrote: > Benjamin Kaduk wrote: >> On Sat, 20 Aug 2011, Rick Macklem wrote: >> >>> If anyone thinks using a fixed table to assign vfc_typenum for known >>> file system types is a bad idea, please let us know. >> >> Fixed table sounds like a good plan. >> Is there a reason for/against using a hash table for types that are >> not in >> the fixed table? The advantage would be that out-of-tree filesystems >> get >> a consistent typenum (modulo hash collisions), but there would be more >> overhead in maintaining the table. >> > Well, the current code maintains maxvfsconf as the largest value of vfc_typenum configured. > (vfs_register() increases it and vfs_unregister() shrinks it back down.) Yes; I assume this is just so that it can keep track of how to efficiently allocate an id to the next filesystem that is registered. It still walks the whole list in vfs_unregister, though, so there is some amount of overhead involved. > > Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know what uses vfs_sysctl() also starts off with: printf("WARNING: userland calling deprecated sysctl, " "please rebuild world\n"); I don't know where (if anywhere) it is legitimately used, but it is plausible that it could safely be deprecated. > that sysctl, but it seems that doing a hash on vfc_name (which I think was > what you were suggesting?) would result in a large maxvfsconf with sparsely > distributed vfc_typenum values. > I don't know, but I suspect that wouldn't satisfy the desired sysctl() behaviour? I don't think tracking maxvfsconf would be useful with a hash table approach -- fxr seems to indicate that it is only used so as to give a unique number to a new filesystem, and a hash table with collision detection could perform that role. But, I don't have a good assessment of the tradeoffs involved. It may not be worth the code churn just for the sake of a couple of out-of-tree filesystems that never get exported over NFS; I just don't know. -Ben From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:46:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D7D2106564A for ; Mon, 22 Aug 2011 04:46:10 +0000 (UTC) (envelope-from Peter.Ross@bogen.in-berlin.de) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.freebsd.org (Postfix) with ESMTP id A9C448FC0C for ; Mon, 22 Aug 2011 04:46:09 +0000 (UTC) X-Envelope-From: Peter.Ross@bogen.in-berlin.de X-Envelope-To: Received: from localhost (okapi.in-berlin.de [192.109.42.117]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id p7M4XTEZ005471 for ; Mon, 22 Aug 2011 06:33:30 +0200 Received: from 124-254-118-24-static.bb.ispone.net.au (124-254-118-24-static.bb.ispone.net.au [124.254.118.24]) by webmail.in-berlin.de (Horde Framework) with HTTP; Mon, 22 Aug 2011 14:33:29 +1000 Message-ID: <20110822143329.1608794cjui0lmah@webmail.in-berlin.de> Date: Mon, 22 Aug 2011 14:33:29 +1000 From: "Peter Ross" To: freebsd-current@freebsd.org References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> <4E51BD0E.7040204@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 04:46:10 -0000 Quoting "Adrian Chadd" : > I totally get it. > > However, an installer is user-facing (here), as well as system-facing. > As much as I understand the logic behind it, it is still going to > surprise people to find that their partition tables are modified at > any point before that final "commit". > > Linux installers manage to do it. :-) But they do not get it right all the time. With RHEL and CentOS 5 I had a deterministic way of setting up virtual machines with LVM so they could not boot;-) Just to lower the expectation a bit. Regards Peter From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:50:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B9D91065670; Mon, 22 Aug 2011 04:50:40 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id 16DA38FC1A; Mon, 22 Aug 2011 04:50:40 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id 3875EC28E4E; Mon, 22 Aug 2011 08:50:38 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1313988638; bh=siof4WB9+9NaKV6vz06JCLdr5xFktGvbJg+AlIe68Eo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=PmHG5yjpSTD9hFKlqz9+QDUdgUTeLli5XzxYIp8rMgYnP5++cP7S/gq9tJ8DIjZFq 2fm9PIhII6DKfQXKKvh6LGGwi4CdlJFcTOcYf79OE3qyHvuQlPRoH6r286zJfCoZW7 EBWYylEGqeoSr2NXS2um3R/hCgGwIIDhi3k/gw84= Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 1015DE40015; Mon, 22 Aug 2011 08:50:38 +0400 (MSD) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id obmGHSaV; Mon, 22 Aug 2011 08:50:37 +0400 X-Yandex-Spam: 1 Message-ID: <4E51E019.4060206@yandex.ru> Date: Mon, 22 Aug 2011 08:50:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Nathan Whitehorn References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> In-Reply-To: <4E519C13.4060700@freebsd.org> X-Enigmail-Version: 1.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig53C192017D619D5E3127E9E1" Cc: Garrett Cooper , freebsd-current@freebsd.org, Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 04:50:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig53C192017D619D5E3127E9E1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 22.08.2011 4:00, Nathan Whitehorn wrote: > The larger problem is that this behavior means that destroying gparts s= ometimes doesn't work at > all. For instance, if you have nested partitioning like MBR+BSD (or EBR= ) it is not possible to > destroy the underlying MBR geom without committing the destruction of t= he BSD geom. This is > because the MBR geom cannot be destroyed, even without committing, whil= e it continues to have > children, which it does due to the ghost geom for the BSD slice. Actually you can destroy underlying MBR geom without committing, just use= "force" flag. But there is another problem, the metadata of nested scheme will not dele= ted and it might appear again when you create new MBR and new partition in the same place.= --=20 WBR, Andrey V. Elsukov --------------enig53C192017D619D5E3127E9E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJOUeAdAAoJEAHF6gQQyKF6vAkH/A6jsqVHkTVaRNvqMSdZhvbT prSSLgBl547+IW543jZLlb3n8w2tFQRd104+cVPltg4lzZtHl9T9rs8FdkLCsMJr c263MYOS28GC8vVgvBI4+4leM72Wgs0NOcUb7u+oqP4omwNSMuo0f62qNQFToXEw sIygGATMqH3i5+ILAOVzmtbplCXK5qLFElxW9guERpDyOdgAm59nCmRr5pNkEq8a b6C+R2cE50luEHmpLpQn2tsSZoXf+ZBOSUSWCEmPMgeQO+irT/vtZ4pMwRgZUVec aic9K8BeCGQg2lzi2RePgk6bWY5WJhXTFUcmlI4/HANJgRsc8m3jvOUD6PQAQgE= =TdiM -----END PGP SIGNATURE----- --------------enig53C192017D619D5E3127E9E1-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 06:43:40 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EBDF1065687 for ; Mon, 22 Aug 2011 06:43:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 337458FC12 for ; Mon, 22 Aug 2011 06:43:38 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA01668; Mon, 22 Aug 2011 09:43:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QvOES-0003rU-D5; Mon, 22 Aug 2011 09:43:36 +0300 Message-ID: <4E51FA96.8090106@FreeBSD.org> Date: Mon, 22 Aug 2011 09:43:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: Garrett Cooper References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "Kenneth D. Merry" Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/sys/kern/kern_cons.c:420 when running dump in ddb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 06:43:40 -0000 on 22/08/2011 04:34 Garrett Cooper said the following: > On Thu, Aug 18, 2011 at 5:55 PM, Garrett Cooper wrote: >> Hi, >> Long story short, I was running a UP kernel on a netbook trying to >> stimulate a crash and when I did dump, it would periodically fail >> non-recursive mutex failure with the output shown below (I caught it >> once, but the other times the dump failed). > > This actually shows up when generating a panic via boot -v with > WITNESS, so it's potentially a race condition on my laptop. Adding > MTX_RECURSE to the mutex object didn't help things either. You may want to try to reproduce this panic with the following patch: http://article.gmane.org/gmane.os.freebsd.stable/76534 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 07:59:33 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 844D5106566C; Mon, 22 Aug 2011 07:59:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id F344F14FEF8; Mon, 22 Aug 2011 07:59:32 +0000 (UTC) Message-ID: <4E520C64.1080603@FreeBSD.org> Date: Mon, 22 Aug 2011 00:59:32 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: FreeBSD Current , perl@FreeBSD.org References: <201108201123.p7KBNYFO008124@172-17-198-245.globalsuite.net> In-Reply-To: <201108201123.p7KBNYFO008124@172-17-198-245.globalsuite.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 X-Forwarded-Message-Id: <201108201123.p7KBNYFO008124@172-17-198-245.globalsuite.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: periodic weekly catman - perl problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 07:59:33 -0000 I have the catman option enabled for periodic/weekly and get the following errors: Reformatting manual pages: catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission denied It seems that the cat3 directories are not created because the man directories are owned by root, and the cat* directories are owned by man, which is what the 330.catman script operates as. Creating those directories with the proper permissions allows the catman periodic script to do its thing. So my question is, is this something that the catman periodic script should be doing, or should the perl port be doing it? Doug From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 08:20:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931741065670 for ; Mon, 22 Aug 2011 08:20:05 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3358FC0A for ; Mon, 22 Aug 2011 08:20:04 +0000 (UTC) Received: from msx3.exchange.alogis.com (msx3exchange.alogis.com [10.1.1.6] (may be forged)) by alogis.com (8.13.4/8.13.1) with ESMTP id p7M854KP049634; Mon, 22 Aug 2011 10:05:04 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Mon, 22 Aug 2011 10:06:43 +0200 From: Holger Kipp To: Yampress Thread-Topic: installer freebsd9 beta1 Thread-Index: AQHMYKJttrrW7dH2AkC4Y1hLb9w2Ag== Date: Mon, 22 Aug 2011 08:06:42 +0000 Message-ID: <44483776-78EB-44D6-879A-BBE278D8E838@alogis.com> References: <4E5204B4.106@gmail.com> In-Reply-To: <4E5204B4.106@gmail.com> Accept-Language: en-GB, de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" , FreeBSD-STABLE Mailing List Subject: Re: installer freebsd9 beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 08:20:05 -0000 Hello *, I'll just add a 'me too'. Had not posted to the list because I wasn't sure if it wasn't because of me :-) Best regards, Holger Am 22.08.2011 um 09:26 schrieb Yampress: > Welcome > I installed freebsd 9bata1 and noticed the installer does not create a us= er account's home directory. > Have to manually create after installation. > Greet > _______________________________________________ > 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" -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 04:53:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DDD1065676 for ; Mon, 22 Aug 2011 04:53:23 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id CC06C8FC18 for ; Mon, 22 Aug 2011 04:53:22 +0000 (UTC) Received: (qmail 7808 invoked by uid 399); 22 Aug 2011 04:26:40 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 22 Aug 2011 04:26:40 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Date: Sun, 21 Aug 2011 21:26:37 -0700 From: Doug Barton To: Adrian Chadd Message-ID: <20110821212637.39bb22de@172-17-198-245.globalsuite.net> In-Reply-To: References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> <4E51BD0E.7040204@freebsd.org> Organization: http://SupersetSolutions.com/ X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Aug 2011 10:58:58 +0000 Cc: "freebsd-current@FreeBSD.org Current" , Nathan Whitehorn , Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 04:53:23 -0000 On Mon, 22 Aug 2011 12:23:43 +0800 Adrian Chadd wrote: > However, an installer is user-facing (here), as well as system-facing. > As much as I understand the logic behind it, it is still going to > surprise people to find that their partition tables are modified at > any point before that final "commit". +1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 11:08:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4744C1065693; Mon, 22 Aug 2011 11:08:47 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E509F8FC15; Mon, 22 Aug 2011 11:08:46 +0000 (UTC) Received: by gxk28 with SMTP id 28so3904577gxk.13 for ; Mon, 22 Aug 2011 04:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=66lEGglPaxeZy9wMNytxAmQVR+EwO3CfiSZ7qbHWLTM=; b=oYWblFk84xZ/LpzHxEa5DP5KiSjSbotJORAZDti3H19Bflj0u3gAfu/96DTr9MFroE GhRWIupHZxKheM1X5r70JySv5o9rnoaLpzOedSkqPD7DnM5C3OUV0RyLUDORxxsTzKxb eLTB26fXXMu3ewqeFPmi7q/lu7XDLSEWOz19M= MIME-Version: 1.0 Received: by 10.150.14.3 with SMTP id 3mr2338959ybn.425.1314011326080; Mon, 22 Aug 2011 04:08:46 -0700 (PDT) Received: by 10.150.188.9 with HTTP; Mon, 22 Aug 2011 04:08:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 15:08:46 +0400 Message-ID: From: Sergey Kandaurov To: Tom Vijlbrief Content-Type: multipart/mixed; boundary=000e0cd762ae5266d904ab161afa Cc: FreeBSD Net , freebsd-current@freebsd.org Subject: Re: BETA1 IPv6 crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 11:08:47 -0000 --000e0cd762ae5266d904ab161afa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 8 August 2011 22:06, Tom Vijlbrief wrote: > 2011/8/7 Sergey Kandaurov : >> On 7 August 2011 17:11, Tom Vijlbrief wrote: >>> I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the >>> new installer. >>> >>> Major issue I noticed was the missing /home. >>> >>> It took me quite some time to get IPv6 working in the guest (a Linux >>> configuration issue), but now that it works >>> BETA1 panics in about 50% of the boot attempts: >>> >>> testbsd dumped core - see /var/crash/vmcore.0 >>> >>> Sun Aug =A07 08:25:28 CEST 2011 >>> >>> FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 >>> UTC 2011 =A0 =A0 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENER= IC >>> i386 >>> >>> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ >>> /usr/src/sys/netinet6/mld6.c:1676 >>> >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and yo= u are >>> welcome to change it and/or distribute copies of it under certain condi= tions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. =A0Type "show warranty" for de= tails. >>> This GDB was configured as "i386-marcel-freebsd"... >> [..] >>> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ >>> /usr/src/sys/netinet6/mld6.c:1676 >>> >>> cpuid =3D 0 >>> KDB: enter: panic >>> Uptime: 28s >>> Physical memory: 491 MB >>> Dumping 45 MB: 30 14 >>> >>> #0 =A0doadump (textdump=3D1) at pcpu.h:244 >>> 244 =A0 =A0 pcpu.h: No such file or directory. >>> =A0 =A0 =A0 =A0in pcpu.h >>> (kgdb) #0 =A0doadump (textdump=3D1) at pcpu.h:244 >>> #1 =A00xc0a04965 in kern_reboot (howto=3D260) >>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:430 >>> #2 =A00xc0a04291 in panic (fmt=3DVariable "fmt" is not available. >>> ) at /usr/src/sys/kern/kern_shutdown.c:595 >>> #3 =A00xc09f4a4a in _mtx_lock_sleep (m=3D0xc35f3a28, tid=3D3278693824, = opts=3D0, >>> =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) >>> =A0 =A0at /usr/src/sys/kern/kern_mutex.c:341 >>> #4 =A00xc09f4c67 in _mtx_lock_flags (m=3D0xc35f3a28, opts=3D0, >>> =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) >>> =A0 =A0at /usr/src/sys/kern/kern_mutex.c:203 >>> #5 =A00xc0bbf007 in mld_set_version (mli=3D0xc3589a00, version=3DVariab= le >>> "version" is not available. >>> ) >>> =A0 =A0at /usr/src/sys/netinet6/mld6.c:1676 >>> #6 =A00xc0bc0c00 in mld_input (m=3D0xc3951e00, off=3D48, icmp6len=3D24) >>> =A0 =A0at /usr/src/sys/netinet6/mld6.c:690 >>> #7 =A00xc0ba5696 in icmp6_input (mp=3D0xc3313a54, offp=3D0xc3313a68, pr= oto=3D58) >>> =A0 =A0at /usr/src/sys/netinet6/icmp6.c:654 >>> #8 =A00xc0bba23a in ip6_input (m=3D0xc3951e00) >>> =A0 =A0at /usr/src/sys/netinet6/ip6_input.c:964 >>> #9 =A00xc0ac9b1c in netisr_dispatch_src (proto=3D10, source=3D0, m=3D0x= c3951e00) >>> =A0 =A0at /usr/src/sys/net/netisr.c:1013 >>> #10 0xc0ac9da0 in netisr_dispatch (proto=3D10, m=3D0xc3951e00) >>> =A0 =A0at /usr/src/sys/net/netisr.c:1104 >>> #11 0xc0abecf1 in ether_demux (ifp=3D0xc35f3800, m=3D0xc3951e00) >>> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:936 >>> #12 0xc0abf1b3 in ether_nh_input (m=3D0xc3951e00) >>> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:755 >>> #13 0xc0ac9b1c in netisr_dispatch_src (proto=3D9, source=3D0, m=3D0xc39= 51e00) >>> =A0 =A0at /usr/src/sys/net/netisr.c:1013 >>> #14 0xc0ac9da0 in netisr_dispatch (proto=3D9, m=3D0xc3951e00) >>> =A0 =A0at /usr/src/sys/net/netisr.c:1104 >>> #15 0xc0abe7f5 in ether_input (ifp=3D0xc35f3800, m=3D0xc3951e00) >>> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:796 >>> #16 0xc0672bc9 in lem_handle_rxtx (context=3D0xc3732000, pending=3D1) >>> =A0 =A0at /usr/src/sys/dev/e1000/if_lem.c:3554 >>> #17 0xc0a468ab in taskqueue_run_locked (queue=3D0xc359ca80) >>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:306 >>> #18 0xc0a47307 in taskqueue_thread_loop (arg=3D0xc37365ec) >>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:495 >>> #19 0xc09d7af8 in fork_exit (callout=3D0xc0a472a0 , >>> =A0 =A0arg=3D0xc37365ec, frame=3D0xc3313d28) at /usr/src/sys/kern/kern_= fork.c:941 >>> #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exceptio= n.s:275 >>> (kgdb) >>> >> >> This is the same as in PR kern/158426. >> Can you try the patch from PR followup and report us whether it helps? >> Full link to PR with patch: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/158426 >> > > I applied the patch and tried about 15 reboots and all went fine.... > Hi, Tom. A better fix for this problem has been developed since then. Would you please try it as well? For doing that, you need to revert a previous patch and apply this one. Please report if this change also fixes the panic for you, so it has better chances to get into 9.0 release. Index: sys/netinet6/mld6.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netinet6/mld6.c (revision 224471) +++ sys/netinet6/mld6.c (working copy) @@ -680,7 +680,6 @@ mld_v1_input_query(struct ifnet *ifp, const struct IN6_MULTI_LOCK(); MLD_LOCK(); - IF_ADDR_LOCK(ifp); /* * Switch to MLDv1 host compatibility mode. @@ -693,6 +692,7 @@ mld_v1_input_query(struct ifnet *ifp, const struct if (timer =3D=3D 0) timer =3D 1; + IF_ADDR_LOCK(ifp); if (is_general_query) { /* * For each reporting group joined on this @@ -888,7 +888,6 @@ mld_v2_input_query(struct ifnet *ifp, const struct IN6_MULTI_LOCK(); MLD_LOCK(); - IF_ADDR_LOCK(ifp); mli =3D MLD_IFINFO(ifp); KASSERT(mli !=3D NULL, ("%s: no mld_ifinfo for ifp %p", __func__, i= fp)); @@ -936,14 +935,18 @@ mld_v2_input_query(struct ifnet *ifp, const struct * Queries for groups we are not a member of on this * link are simply ignored. */ + IF_ADDR_LOCK(ifp); inm =3D in6m_lookup_locked(ifp, &mld->mld_addr); - if (inm =3D=3D NULL) + if (inm =3D=3D NULL) { + IF_ADDR_UNLOCK(ifp); goto out_locked; + } if (nsrc > 0) { if (!ratecheck(&inm->in6m_lastgsrtv, &V_mld_gsrdelay)) { CTR1(KTR_MLD, "%s: GS query throttled.", __func__); + IF_ADDR_UNLOCK(ifp); goto out_locked; } } @@ -961,10 +964,10 @@ mld_v2_input_query(struct ifnet *ifp, const struct /* XXX Clear embedded scope ID as userland won't expect it.= */ in6_clearscope(&mld->mld_addr); + IF_ADDR_UNLOCK(ifp); } out_locked: - IF_ADDR_UNLOCK(ifp); MLD_UNLOCK(); IN6_MULTI_UNLOCK(); --=20 wbr, pluknet --000e0cd762ae5266d904ab161afa Content-Type: application/octet-stream; name="mld6.locking.2.patch" Content-Disposition: attachment; filename="mld6.locking.2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_grncdatp0 SW5kZXg6IHN5cy9uZXRpbmV0Ni9tbGQ2LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2L21s ZDYuYwkocmV2aXNpb24gMjI0NDcxKQorKysgc3lzL25ldGluZXQ2L21sZDYuYwkod29ya2luZyBj b3B5KQpAQCAtNjgwLDcgKzY4MCw2IEBAIG1sZF92MV9pbnB1dF9xdWVyeShzdHJ1Y3QgaWZuZXQg KmlmcCwgY29uc3Qgc3RydWN0CiAKIAlJTjZfTVVMVElfTE9DSygpOwogCU1MRF9MT0NLKCk7Ci0J SUZfQUREUl9MT0NLKGlmcCk7CiAKIAkvKgogCSAqIFN3aXRjaCB0byBNTER2MSBob3N0IGNvbXBh dGliaWxpdHkgbW9kZS4KQEAgLTY5Myw2ICs2OTIsNyBAQCBtbGRfdjFfaW5wdXRfcXVlcnkoc3Ry dWN0IGlmbmV0ICppZnAsIGNvbnN0IHN0cnVjdAogCWlmICh0aW1lciA9PSAwKQogCQl0aW1lciA9 IDE7CiAKKwlJRl9BRERSX0xPQ0soaWZwKTsKIAlpZiAoaXNfZ2VuZXJhbF9xdWVyeSkgewogCQkv KgogCQkgKiBGb3IgZWFjaCByZXBvcnRpbmcgZ3JvdXAgam9pbmVkIG9uIHRoaXMKQEAgLTg4OCw3 ICs4ODgsNiBAQCBtbGRfdjJfaW5wdXRfcXVlcnkoc3RydWN0IGlmbmV0ICppZnAsIGNvbnN0IHN0 cnVjdAogCiAJSU42X01VTFRJX0xPQ0soKTsKIAlNTERfTE9DSygpOwotCUlGX0FERFJfTE9DSyhp ZnApOwogCiAJbWxpID0gTUxEX0lGSU5GTyhpZnApOwogCUtBU1NFUlQobWxpICE9IE5VTEwsICgi JXM6IG5vIG1sZF9pZmluZm8gZm9yIGlmcCAlcCIsIF9fZnVuY19fLCBpZnApKTsKQEAgLTkzNiwx NCArOTM1LDE4IEBAIG1sZF92Ml9pbnB1dF9xdWVyeShzdHJ1Y3QgaWZuZXQgKmlmcCwgY29uc3Qg c3RydWN0CiAJCSAqIFF1ZXJpZXMgZm9yIGdyb3VwcyB3ZSBhcmUgbm90IGEgbWVtYmVyIG9mIG9u IHRoaXMKIAkJICogbGluayBhcmUgc2ltcGx5IGlnbm9yZWQuCiAJCSAqLworCQlJRl9BRERSX0xP Q0soaWZwKTsKIAkJaW5tID0gaW42bV9sb29rdXBfbG9ja2VkKGlmcCwgJm1sZC0+bWxkX2FkZHIp OwotCQlpZiAoaW5tID09IE5VTEwpCisJCWlmIChpbm0gPT0gTlVMTCkgeworCQkJSUZfQUREUl9V TkxPQ0soaWZwKTsKIAkJCWdvdG8gb3V0X2xvY2tlZDsKKwkJfQogCQlpZiAobnNyYyA+IDApIHsK IAkJCWlmICghcmF0ZWNoZWNrKCZpbm0tPmluNm1fbGFzdGdzcnR2LAogCQkJICAgICZWX21sZF9n c3JkZWxheSkpIHsKIAkJCQlDVFIxKEtUUl9NTEQsICIlczogR1MgcXVlcnkgdGhyb3R0bGVkLiIs CiAJCQkJICAgIF9fZnVuY19fKTsKKwkJCQlJRl9BRERSX1VOTE9DSyhpZnApOwogCQkJCWdvdG8g b3V0X2xvY2tlZDsKIAkJCX0KIAkJfQpAQCAtOTYxLDEwICs5NjQsMTAgQEAgbWxkX3YyX2lucHV0 X3F1ZXJ5KHN0cnVjdCBpZm5ldCAqaWZwLCBjb25zdCBzdHJ1Y3QKIAogCQkvKiBYWFggQ2xlYXIg ZW1iZWRkZWQgc2NvcGUgSUQgYXMgdXNlcmxhbmQgd29uJ3QgZXhwZWN0IGl0LiAqLwogCQlpbjZf Y2xlYXJzY29wZSgmbWxkLT5tbGRfYWRkcik7CisJCUlGX0FERFJfVU5MT0NLKGlmcCk7CiAJfQog CiBvdXRfbG9ja2VkOgotCUlGX0FERFJfVU5MT0NLKGlmcCk7CiAJTUxEX1VOTE9DSygpOwogCUlO Nl9NVUxUSV9VTkxPQ0soKTsKIAo= --000e0cd762ae5266d904ab161afa-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 11:14:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B551065670 for ; Mon, 22 Aug 2011 11:14:49 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id DFCDF8FC17 for ; Mon, 22 Aug 2011 11:14:48 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 35F121; Mon, 22 Aug 2011 13:15:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Mon, 22 Aug 2011 13:14:48 +0200 From: Bernhard Froehlich To: Alvaro Castillo In-Reply-To: References: Message-ID: <372a51ec9fff3e1793f844a1389d0161@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.5.4 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0207.4E523A27.01D9,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: freebsd-current@freebsd.org Subject: Re: VirtualBox causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 11:14:49 -0000 On Sat, 20 Aug 2011 19:35:16 +0100, Alvaro Castillo wrote: > VirtualBox Version: 4.0.12_OSE r72916 > > uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #1: Wed Aug > 17 01:21:47 WEST 2011 > netSys@shuttle0.lan:/usr/obj/usr/src/sys/GALILEO amd64 > > The kernel panic is occurred when I start a virtual machine with boot > from CD/DVD burner/reader device. > > With or without passthrough. > > Kernel panic > http://pastie.org/private/0nxanttdmtc9zvtllg0rw > > atapicam is loaded and hald is working. I've added the bugreport and stacktrace to our list of known problems and will inform you once there is something new about it. http://wiki.freebsd.org/VirtualBox/ToDo -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 07:49:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03E2B106566C; Mon, 22 Aug 2011 07:49:55 +0000 (UTC) (envelope-from yampresss@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 662618FC18; Mon, 22 Aug 2011 07:49:54 +0000 (UTC) Received: by fxe4 with SMTP id 4so4148697fxe.13 for ; Mon, 22 Aug 2011 00:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=PKwoLGeFdzdY0Zng5rWlV6m4fHhAwRrJlzuas9ZYXAs=; b=iTkk9t2GYfYFVYcGgKWQ4E1HkwoejzsmT/n1QP4j4waP+OHQJCR5LIGOQeV6v8HmIj ySuCjv2UvkPYnoFPzYzgovRFZfKF2VwabkmW+0Y4Y0PZ6ovT5Qjj7XsbtxJic2rX+wcZ zJ1GsonqqbIff7LBJzJs9bnqxAiqTPtUMSKmw= Received: by 10.223.14.146 with SMTP id g18mr3266106faa.3.1313997947040; Mon, 22 Aug 2011 00:25:47 -0700 (PDT) Received: from [10.0.1.3] ([91.218.158.195]) by mx.google.com with ESMTPS id 16sm4884379faw.42.2011.08.22.00.25.46 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 00:25:46 -0700 (PDT) Message-ID: <4E5204B4.106@gmail.com> Date: Mon, 22 Aug 2011 09:26:44 +0200 From: Yampress User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110704 Icedove/3.0.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org, mailto:freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Aug 2011 11:15:22 +0000 Cc: Subject: installer freebsd9 bata1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 07:49:55 -0000 Welcome I installed freebsd 9bata1 and noticed the installer does not create a user account's home directory. Have to manually create after installation. Greet From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 11:41:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EBFE106566B for ; Mon, 22 Aug 2011 11:41:44 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 13E218FC12 for ; Mon, 22 Aug 2011 11:41:43 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 259DC8; Mon, 22 Aug 2011 13:26:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Mon, 22 Aug 2011 13:26:36 +0200 From: Bernhard Froehlich To: Alvaro Castillo In-Reply-To: <372a51ec9fff3e1793f844a1389d0161@bluelife.at> References: <372a51ec9fff3e1793f844a1389d0161@bluelife.at> Message-ID: <69a61f1715911582ca67281f75a12f0c@bluelife.at> X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.5.4 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0209.4E523CEB.0145,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-Mailman-Approved-At: Mon, 22 Aug 2011 11:57:25 +0000 Cc: freebsd-current@freebsd.org Subject: Re: VirtualBox causes kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 11:41:44 -0000 On Mon, 22 Aug 2011 13:14:48 +0200, Bernhard Froehlich wrote: > On Sat, 20 Aug 2011 19:35:16 +0100, Alvaro Castillo wrote: >> VirtualBox Version: 4.0.12_OSE r72916 >> >> uname -a: FreeBSD shuttle0.lan 9.0-BETA1 FreeBSD 9.0-BETA1 #1: Wed Aug >> 17 01:21:47 WEST 2011 >> netSys@shuttle0.lan:/usr/obj/usr/src/sys/GALILEO amd64 >> >> The kernel panic is occurred when I start a virtual machine with boot >> from CD/DVD burner/reader device. >> >> With or without passthrough. >> >> Kernel panic > http://pastie.org/private/0nxanttdmtc9zvtllg0rw >> >> atapicam is loaded and hald is working. > > I've added the bugreport and stacktrace to our list of known problems > and will inform you once there is something new about it. > > http://wiki.freebsd.org/VirtualBox/ToDo I've just seen that the stacktrace does not belong to the panic. So could you please generate a stacktrace for that panic? -- Bernhard Fröhlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 12:58:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95FE71065675 for ; Mon, 22 Aug 2011 12:58:58 +0000 (UTC) (envelope-from christoph_hoffmann@me.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 710F28FC13 for ; Mon, 22 Aug 2011 12:58:58 +0000 (UTC) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_dhaOQu7O1t7dAhVo33SXwg)" Received: from [172.16.17.216] ([62.2.44.34]) by asmtp026.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQB00EXDYQ3KM50@asmtp026.mac.com> for freebsd-current@freebsd.org; Mon, 22 Aug 2011 05:58:56 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-08-22_03:2011-08-22, 2011-08-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108220096 From: Christoph Hoffmann Date: Mon, 22 Aug 2011 14:58:50 +0200 In-reply-to: To: freebsd-current@freebsd.org References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> Message-id: <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> X-Mailer: Apple Mail (2.1244.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: gptzfsboot error using HP Smart Array P410i Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:58:58 -0000 --Boundary_(ID_dhaOQu7O1t7dAhVo33SXwg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello Everybody, As per Dimitry request, please find set of gzip'ed zfsboot.s files (61223 bytes). Due to size of the attachments which exceeded 200 KB, the original message has been rejected. Thank you very much indeed for your help and I am sorry of this spam. Regards, Christoph --Boundary_(ID_dhaOQu7O1t7dAhVo33SXwg) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable -- Christoph Hoffmann On Aug 22, 2011, at 12:23 PM, Christoph Hoffmann wrote: > Hello Dimitry, >=20 > Please find attached zfsboot.s files.=20 >=20 > Thank you very much indeed for your help. >=20 > Best Regards, >=20 > Christoph >=20 > >=20 > -- > Christoph Hoffmann >=20 > On Aug 21, 2011, at 12:03 AM, Dimitry Andric wrote: >=20 >> On 2011-08-18 18:30, Christoph Hoffmann wrote: >> ... >>> Changing the order of execution in zfsboot.c main() function to >>>=20 >>> [=85] >>> int >>> main(void) >>> { >>> [=85] >>> bios_getmem(); >>>=20 >>> if (high_heap_size> 0) { >>> [=85] >>> bootinfo.bi_version =3D BOOTINFO_VERSION; >>> bootinfo.bi_size =3D sizeof(bootinfo); >>> bootinfo.bi_basemem =3D bios_basemem / 1024; >>> bootinfo.bi_extmem =3D bios_extmem / 1024; >>> bootinfo.bi_memsizes_valid++; >>> /* bootinfo.bi_bios_dev =3D dsk->drive; */ >>> bootinfo.bi_bios_dev =3D *(uint8_t *)PTOV(ARGS); >>>=20 >>> dsk =3D malloc(sizeof(struct dsk)); >>> dsk->drive =3D *(uint8_t *)PTOV(ARGS); >>> dsk->type =3D dsk->drive& DRV_HARD ? TYPE_AD : TYPE_FD; >>> dsk->unit =3D dsk->drive& DRV_MASK; >>> dsk->slice =3D *(uint8_t *)PTOV(ARGS + 1) + 1; >>> dsk->part =3D 0; >>> dsk->start =3D 0; >>> dsk->init =3D 0; >>>=20 >>> bootdev =3D MAKEBOOTDEV(dev_maj[dsk->type], >>> dsk->slice, dsk->unit, dsk->part), >>> [=85] >>>=20 >>>=20 >>> fixes the problem. >>=20 >> Can you please use -save-temps to save the intermediate zfsboot.s = files, >> both before and after you change this order, then post them here? = It's >> easiest to just do: >>=20 >> DEBUG_FLAGS=3D-save-temps make -C /usr/src/sys/boot/i386/gptzfsboot = clean all >>=20 >> then save /usr/obj/usr/src/sys/boot/i386/gptzfsboot/zfsboot.s = somewhere. >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 --Boundary_(ID_dhaOQu7O1t7dAhVo33SXwg)-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 13:13:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7C8106564A; Mon, 22 Aug 2011 13:13:19 +0000 (UTC) (envelope-from nwhitehorn@banshee.munuc.org) Received: from banshee.munuc.org (cl-106.chi-02.us.sixxs.net [IPv6:2001:4978:f:69::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2958FC0A; Mon, 22 Aug 2011 13:13:19 +0000 (UTC) Received: from nwhitehorn (helo=localhost) by banshee.munuc.org with local-esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvUJa-000Mdg-Bp; Mon, 22 Aug 2011 08:13:18 -0500 Date: Mon, 22 Aug 2011 08:13:18 -0500 (CDT) From: Nathan Whitehorn X-X-Sender: nwhitehorn@banshee.munuc.org To: Adrian Chadd In-Reply-To: Message-ID: References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51B228.7030001@freebsd.org> <0AF19658-2FA7-48EC-9EA2-67DC26DAC1D4@xcllnt.net> <4E51BD0E.7040204@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1464019946-260687654-1314018798=:87003" Sender: Nathan Whitehorn X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: nwhitehorn@banshee.munuc.org X-SA-Exim-Scanned: No (on banshee.munuc.org); SAEximRunCond expanded to false Cc: "freebsd-current@FreeBSD.org Current" , Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 13:13:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1464019946-260687654-1314018798=:87003 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 22 Aug 2011, Adrian Chadd wrote: > I totally get it. > > However, an installer is user-facing (here), as well as system-facing. > As much as I understand the logic behind it, it is still going to > surprise people to find that their partition tables are modified at > any point before that final "commit". > > Linux installers manage to do it. :-) This is why there is a GIANT WARNING MESSAGE IN ALL CAPITAL LETTERS before= =20 this happens, which is only under very specific circumstances. For almost= =20 all possible modifications, it doesn't change anything until commit, as=20 suggested. -Nathan > > > On 22 August 2011 10:21, Nathan Whitehorn wrote: >> Doing it that way is really, really error-prone, because you have to gue= ss >> (a) whether gpart will accept certain configurations and (b) how it will >> handle requests. On some schemes, partititions have to be aligned or siz= ed >> in particular ways and have various limitations. Depending on the module= , >> gpart will either reject the request or silently adjust it. Letting the >> kernel handle the state means that the geom modules themselves get to de= cide >> this, and you can act on the result at the same time you request it. Doi= ng >> it in userland means you need to guess, perfectly, all the time, what wi= ll >> happen with every input to every module, and so that you have a >> fully-functional perfect simulator of all possible behaviors and states = of >> every type of partitioning that the kernel currently or may ever support= =2E >> This tends not to work well. >> -Nathan >> >> On 08/21/11 21:02, Adrian Chadd wrote: >>> >>> Honestly - if you're relying on doing anything that isn't read-only w/ >>> GEOM right until "commit", I think you're doing it wrong. >>> >>> If anything, you should write something which manipulates geom tables >>> in userland, and can have a geom database populated from the kernel. >>> All of your subsequent tools (eg stuff which creates labels, raid >>> devices, etc) should manipulate this table, not the kernel. >>> >>> Then when you're ready, you should write the updated table to disk. >>> >>> 2c, >>> >>> >>> Adrian >>> >>> On 22 August 2011 09:48, Marcel Moolenaar =A0wrote: >>>> >>>> On Aug 21, 2011, at 6:34 PM, Nathan Whitehorn wrote: >>>>>>> >>>>>>> The regular partitioning editor only commits early in this particul= ar >>>>>>> case, and asks about each subpartition tree separately with a big s= cary >>>>>>> dialog box. In the spirit of the autopartitioner, it makes one larg= e scary >>>>>>> dialog, and always runs in early commit mode instead of potentially= showing >>>>>>> many scary dialogs about partitions the user doesn't necessarily ev= en know >>>>>>> about. This behavior could be changed, but I think is the most frie= ndly for >>>>>>> the case in question: namely, "I want to blow away everything and l= et the >>>>>>> installer handle all partitioning details by itself". >>>>>> >>>>>> What about inserting a special class for doing commit/undo. The GEOM >>>>>> simply keeps all modifications in memory and 1) forgets everything o= n >>>>>> an undo operation or 2) writes all dirty sectors on a commit. This >>>>>> could be used even instead of the gpart-private support, which also >>>>>> removes the quirk for the null scheme. >>>>>> >>>>> Where would this class go? If it went below gpart (between gpart and >>>>> userland), then it seems like we would lose the ability of gpart to v= alidate >>>>> its parameters. Who would be responsible for inserting this GEOM into= the >>>>> stack? >>>> >>>> Between the disk GEOM and the gpart GEOM. The gpart utility would >>>> still interact with the GEOM is before. >>>> >>>> -- >>>> Marcel Moolenaar >>>> marcel@xcllnt.net >>>> >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --1464019946-260687654-1314018798=:87003-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 13:13:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59DA4106564A for ; Mon, 22 Aug 2011 13:13:58 +0000 (UTC) (envelope-from nwhitehorn@banshee.munuc.org) Received: from banshee.munuc.org (cl-106.chi-02.us.sixxs.net [IPv6:2001:4978:f:69::2]) by mx1.freebsd.org (Postfix) with ESMTP id 31D1D8FC17 for ; Mon, 22 Aug 2011 13:13:58 +0000 (UTC) Received: from nwhitehorn (helo=localhost) by banshee.munuc.org with local-esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvUKA-000Mdk-Pp; Mon, 22 Aug 2011 08:13:54 -0500 Date: Mon, 22 Aug 2011 08:13:54 -0500 (CDT) From: Nathan Whitehorn X-X-Sender: nwhitehorn@banshee.munuc.org To: "Andrey V. Elsukov" In-Reply-To: <4E51E019.4060206@yandex.ru> Message-ID: References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51E019.4060206@yandex.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: Nathan Whitehorn X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: nwhitehorn@banshee.munuc.org X-SA-Exim-Scanned: No (on banshee.munuc.org); SAEximRunCond expanded to false Cc: Garrett Cooper , freebsd-current@freebsd.org, Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 13:13:58 -0000 On Mon, 22 Aug 2011, Andrey V. Elsukov wrote: > On 22.08.2011 4:00, Nathan Whitehorn wrote: >> The larger problem is that this behavior means that destroying gparts sometimes doesn't work at >> all. For instance, if you have nested partitioning like MBR+BSD (or EBR) it is not possible to >> destroy the underlying MBR geom without committing the destruction of the BSD geom. This is >> because the MBR geom cannot be destroyed, even without committing, while it continues to have >> children, which it does due to the ghost geom for the BSD slice. > > Actually you can destroy underlying MBR geom without committing, just use "force" flag. > But there is another problem, the metadata of nested scheme will not deleted and it might > appear again when you create new MBR and new partition in the same place. This isn't true for nested partitioning, at least in my experience. -Nathan > -- > WBR, Andrey V. Elsukov > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 13:15:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9843B106566B; Mon, 22 Aug 2011 13:15:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 397A78FC12; Mon, 22 Aug 2011 13:15:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPRVUk6DaFvO/2dsb2JhbABBDoQ9pDeBQAEBAQECAQEBASAEJyALGxgCAg0ZAikBCSYGCAcEARwEh1AEpBaQeIEshAyBEASRBoIOkD9U X-IronPort-AV: E=Sophos;i="4.68,263,1312171200"; d="scan'208";a="135134454" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Aug 2011 09:15:33 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2DC59B3F27; Mon, 22 Aug 2011 09:15:33 -0400 (EDT) Date: Mon, 22 Aug 2011 09:15:33 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <1581074997.148660.1314018933175.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 13:15:34 -0000 Benjamin Kaduk wrote: > On Sun, 21 Aug 2011, Rick Macklem wrote: > > > Benjamin Kaduk wrote: > >> On Sat, 20 Aug 2011, Rick Macklem wrote: > >> > >>> If anyone thinks using a fixed table to assign vfc_typenum for > >>> known > >>> file system types is a bad idea, please let us know. > >> > >> Fixed table sounds like a good plan. > >> Is there a reason for/against using a hash table for types that are > >> not in > >> the fixed table? The advantage would be that out-of-tree > >> filesystems > >> get > >> a consistent typenum (modulo hash collisions), but there would be > >> more > >> overhead in maintaining the table. > >> > > Well, the current code maintains maxvfsconf as the largest value of > > vfc_typenum configured. > > (vfs_register() increases it and vfs_unregister() shrinks it back > > down.) > > Yes; I assume this is just so that it can keep track of how to > efficiently > allocate an id to the next filesystem that is registered. It still > walks > the whole list in vfs_unregister, though, so there is some amount of > overhead involved. > > > > > Then, vfs_sysctl() returns maxvfsconf for a sysctl. I don't know > > what uses > > vfs_sysctl() also starts off with: > printf("WARNING: userland calling deprecated sysctl, " > "please rebuild world\n"); > I don't know where (if anywhere) it is legitimately used, but it is > plausible that it could safely be deprecated. > If/what might use this sysctl is my main concern w.r.t. the patch. (Even without using a hash, the table will result in some gaps in the assignment of vfc_typenum and the sysctl will return ENOTSUPP for those. If a program is looping through them all, from 0<->maxvfsconf it would need to ignore those.) I'm going to grep /usr/src for any use(s) of it, but I don't know beyond that. > > that sysctl, but it seems that doing a hash on vfc_name (which I > > think was > > what you were suggesting?) would result in a large maxvfsconf with > > sparsely > > distributed vfc_typenum values. > > I don't know, but I suspect that wouldn't satisfy the desired > > sysctl() behaviour? > > I don't think tracking maxvfsconf would be useful with a hash table > approach -- fxr seems to indicate that it is only used so as to give a > unique number to a new filesystem, and a hash table with collision > detection could perform that role. > > But, I don't have a good assessment of the tradeoffs involved. It may > not > be worth the code churn just for the sake of a couple of out-of-tree > filesystems that never get exported over NFS; I just don't know. > At this point in the 9.0 release cycle, I'd lean towards less churn and preserving the sysctl(), except that it would still have some small gaps in it. (As you say, there aren't a lot of file system types that will be NFS exported anyhow.) How do others feel w.r.t. this? W.r.t what file system types get exported over NFS... - I think the current list might be: ufs, zfs, msdosfs, cd9660, udf Does anyone out there NFS export any others? rick > -Ben > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 13:17:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D701065700 for ; Mon, 22 Aug 2011 13:17:47 +0000 (UTC) (envelope-from nwhitehorn@banshee.munuc.org) Received: from banshee.munuc.org (cl-106.chi-02.us.sixxs.net [IPv6:2001:4978:f:69::2]) by mx1.freebsd.org (Postfix) with ESMTP id 577448FC14; Mon, 22 Aug 2011 13:17:47 +0000 (UTC) Received: from nwhitehorn (helo=localhost) by banshee.munuc.org with local-esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvUNu-000MeE-PU; Mon, 22 Aug 2011 08:17:46 -0500 Date: Mon, 22 Aug 2011 08:17:46 -0500 (CDT) From: Nathan Whitehorn X-X-Sender: nwhitehorn@banshee.munuc.org To: Yampress In-Reply-To: <4E5204B4.106@gmail.com> Message-ID: References: <4E5204B4.106@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: Nathan Whitehorn X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: nwhitehorn@banshee.munuc.org X-SA-Exim-Scanned: No (on banshee.munuc.org); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org, "mailto:freebsd-stable"@freebsd.org Subject: Re: installer freebsd9 bata1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 13:17:47 -0000 On Mon, 22 Aug 2011, Yampress wrote: > Welcome > I installed freebsd 9bata1 and noticed the installer does not create a user > account's home directory. > Have to manually create after installation. This was due to a temporary regression in pw(8) that managed to sneak into the BETA1 builds. It has been fixed and will not reappear in BETA2. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 14:04:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CD0C106579A for ; Mon, 22 Aug 2011 14:04:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 697958FC08 for ; Mon, 22 Aug 2011 14:04:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E42C46B0D; Mon, 22 Aug 2011 10:04:56 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 958FC8A02E; Mon, 22 Aug 2011 10:04:55 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 22 Aug 2011 09:54:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <927966496.20110820112229@serebryakov.spb.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Message-Id: <201108220954.17541.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 22 Aug 2011 10:04:55 -0400 (EDT) Cc: Scot Hetzel Subject: Re: 9.0-BETA1 installer glithcies (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 14:04:57 -0000 On Sunday, August 21, 2011 4:42:44 pm Scot Hetzel wrote: > 2011/8/21 Kevin Oberman : > > 2011/8/21 Lev Serebryakov : > >> Hello, Nathan. > >> You wrote 21 =C1=D7=C7=D5=D3=D4=C1 2011 =C7., 20:53:22: > >> > >>> GPT is bootable on all x86 systems, with either EFI or BIOS, and is n= ow > >> Ok, I was not sure here. > > > > The Wikipedia article on GUID Partition Table states that Windows only = supports > > GPT boot when the system is a EFI system and is 64-bit Windows, Vista o= r newer. > > Windows-32 will not boot from a GPT disk. > > > > I know Wikipedia is not always right, but it matches my limited experie= nce. > > > > https://secure.wikimedia.org/wikipedia/en/wiki/GUID_Partition_Table >=20 > Since this is the FreeBSD list, we are talking about booting FreeBSD > from GPT partitioned disks. FreeBSD supports booting from both > PC/BIOS and EFI Systems. >=20 > If you want to dual boot between FreeBSD and Windows, then you will > need a MBR Partitioned disk. Err, FreeBSD only supports booting from EFI on ia64 unless someone added missing bits to the x86 efi loader recently and I missed it. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 15:45:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EAC0106564A; Mon, 22 Aug 2011 15:45:47 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0729A8FC0A; Mon, 22 Aug 2011 15:45:47 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id 63097C252D1; Mon, 22 Aug 2011 19:45:45 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1314027945; bh=h4K0UlTy/y7i7Of4lLEstmL2+HXkvhdVEnczFBFUnvY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=p+P3soTLO0ZoaUpPdAFJUGh0zjHkJQfyPaW66kG1Lq65PRrhLmn757fhUcu3D8MLx 2d+SLiemJWNmR5yHrXUdMTKXw+7rFKTDgxVw10YBQuNizgJ1q0qauNzKSRgfzMeKUQ yyvuUsmI6AzWYccwWMRMg1Cban6UaVucrXEeOCf8= Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 4207FE40015; Mon, 22 Aug 2011 19:45:45 +0400 (MSD) Received: from dynamic-178-141-127-99.kirov.comstar-r.ru (dynamic-178-141-127-99.kirov.comstar-r.ru [178.141.127.99]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jimeq1Kp; Mon, 22 Aug 2011 19:45:45 +0400 X-Yandex-Spam: 1 Message-ID: <4E52797F.6060100@yandex.ru> Date: Mon, 22 Aug 2011 19:45:03 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nathan Whitehorn References: <4E4DB9A7.4040404@freebsd.org> <4E517978.2020705@freebsd.org> <64622705-80AB-4FEF-91E9-8F3041818B4E@xcllnt.net> <4E519C13.4060700@freebsd.org> <4E51E019.4060206@yandex.ru> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Aug 2011 15:53:04 +0000 Cc: freebsd-current@freebsd.org, Marcel Moolenaar Subject: Re: Well, there goes Windows! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:45:47 -0000 On 22.08.2011 17:13, Nathan Whitehorn wrote: >> Actually you can destroy underlying MBR geom without committing, just >> use "force" flag. >> But there is another problem, the metadata of nested scheme will not >> deleted and it might >> appear again when you create new MBR and new partition in the same place. > > This isn't true for nested partitioning, at least in my experience. You can try: # mdconfig -s 100m # gpart create -s mbr md0 # gpart add -t freebsd md0 # gpart create -s bsd md0s1 # gpart add -t freebsd-ufs md0s1 # gpart destroy -F -f x md0 But when you create MBR again: # gpart create -f x -s mbr md0 # gpart add -f x -t fat32 md0 Now the old BSD scheme will be detected: => 9 204791 md0 MBR (100M) 9 204786 1 fat32 (100M) 204795 5 - free - (2.5k) => 0 204786 md0s1 BSD (100M) 0 204786 1 freebsd-ufs (100M) ---------------------------------------------- The forced destroying does not work for the case when you destroyed nested scheme before MBR, e.g. # gpart destroy -f x -F md0s1 # gpart destroy -f x -F md0 gpart: Device busy It's because the first destroying is not committed and provider md0s1 is still opened: # gpart list md0s1 | grep Mode Mode: r1w1e1 <----- -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 16:35:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0D4B106566B for ; Mon, 22 Aug 2011 16:35:09 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id A0CE28FC16 for ; Mon, 22 Aug 2011 16:35:09 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1QvXSu-0000Cd-KT for freebsd-current@freebsd.org; Mon, 22 Aug 2011 09:35:08 -0700 Date: Mon, 22 Aug 2011 09:35:08 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1314030908626-4723962.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: kldload uhci, system grinds to halt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:35:09 -0000 Hello. Anybody is experiencing something similar? There was no such problem on 8-STABLE, this is now FreeBSD 9.0-BETA1 #0 r225063 amd64, kernel is semi-heavily stripped (usb is not compiled in). I could post system details, but for now I think it could be unnecessary distraction. When this system was 8-STABLE, this configuration worked fine. regards, -Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/kldload-uhci-system-grinds-to-halt-tp4723962p4723962.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 17:12:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E52FA1065672; Mon, 22 Aug 2011 17:12:41 +0000 (UTC) (envelope-from andrej.zverev@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4BB8FC08; Mon, 22 Aug 2011 17:12:41 +0000 (UTC) Received: by vxh11 with SMTP id 11so5631691vxh.13 for ; Mon, 22 Aug 2011 10:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=if3hbx3/CBaCX5mJHr/EkZCPW7oj/5rhVXlgZ/Q5zhs=; b=Wc5lgC9zhx+ZPkVzPjpRCl9vnzcJrLMSjbL/YrA1qO3DVvrCQGpXtzCJjWh3GoVO2i HB4v3dcpucFOnHpVYEC1vnO+zgMRzDw0sRfic8hMODHpq/NaVibE4Upat1pwMEIbD3eX YgzGw8oehOHCVmlc2LZKkpR/95v9QDKuHx4Gg= MIME-Version: 1.0 Received: by 10.52.69.37 with SMTP id b5mr2496685vdu.396.1314031313504; Mon, 22 Aug 2011 09:41:53 -0700 (PDT) Received: by 10.52.159.225 with HTTP; Mon, 22 Aug 2011 09:41:53 -0700 (PDT) In-Reply-To: <4E520C64.1080603@FreeBSD.org> References: <201108201123.p7KBNYFO008124@172-17-198-245.globalsuite.net> <4E520C64.1080603@FreeBSD.org> Date: Mon, 22 Aug 2011 20:41:53 +0400 Message-ID: From: Andrej Zverev To: Doug Barton X-Mailman-Approved-At: Mon, 22 Aug 2011 17:42:12 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: perl@freebsd.org, FreeBSD Current Subject: Re: periodic weekly catman - perl problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:12:42 -0000 On Mon, Aug 22, 2011 at 11:59 AM, Doug Barton wrote: > I have the catman option enabled for periodic/weekly and get the > following errors: > > Reformatting manual pages: > catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied > catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission denied > > > It seems that the cat3 directories are not created because the man > directories are owned by root, and the cat* directories are owned by > man, which is what the 330.catman script operates as. > > Creating those directories with the proper permissions allows the catman > periodic script to do its thing. So my question is, is this something > that the catman periodic script should be doing, or should the perl port > be doing it? > > Hello, Doug. I couldn't find which way is correct in this situation but I can propose the following patch: http://sunner.semmy.ru/~az/perl-man.txt if this solve issue when you can knock-knock at skv's (perl maintainer) door. From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 18:40:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A30106564A; Mon, 22 Aug 2011 18:40:56 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5F28FC0A; Mon, 22 Aug 2011 18:40:55 +0000 (UTC) Received: by qyk4 with SMTP id 4so1778802qyk.13 for ; Mon, 22 Aug 2011 11:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ouq6zc3NnCSWvIMrvDhebAPJiuqQIzOlNK8SsFeND0U=; b=X8DgpYXXFrGvyhWKwJ/C0UGavc5zDqqyQZ9vqMrR/GmaQoEenwChpLwlyXMr3FWR8p InsIE1Z/c5H+2GSwNzg4i2IZtx/K5DoAgzm1qlwY1R6AXQPvP/0GRipRDTN9Cc+7NqED B4PcxYn40Eg0HhBQOU9hu+NDUlJepIqI37gIA= MIME-Version: 1.0 Received: by 10.229.77.78 with SMTP id f14mr1863429qck.38.1314038454536; Mon, 22 Aug 2011 11:40:54 -0700 (PDT) Sender: tvijlbrief@gmail.com Received: by 10.229.230.130 with HTTP; Mon, 22 Aug 2011 11:40:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 20:40:54 +0200 X-Google-Sender-Auth: jbMOBIqThuhTCrXAukPT-offTj8 Message-ID: From: Tom Vijlbrief To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , freebsd-current@freebsd.org Subject: Re: BETA1 IPv6 crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:40:56 -0000 2011/8/22 Sergey Kandaurov : > On 8 August 2011 22:06, Tom Vijlbrief wrote: >> 2011/8/7 Sergey Kandaurov : >>> On 7 August 2011 17:11, Tom Vijlbrief wrote: >>>> I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the >>>> new installer. >>>> >>>> Major issue I noticed was the missing /home. >>>> >>>> It took me quite some time to get IPv6 working in the guest (a Linux >>>> configuration issue), but now that it works >>>> BETA1 panics in about 50% of the boot attempts: >>>> >>>> testbsd dumped core - see /var/crash/vmcore.0 >>>> >>>> Sun Aug =A07 08:25:28 CEST 2011 >>>> >>>> FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 >>>> UTC 2011 =A0 =A0 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENE= RIC >>>> i386 >>>> >>>> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ >>>> /usr/src/sys/netinet6/mld6.c:1676 >>>> >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and y= ou are >>>> welcome to change it and/or distribute copies of it under certain cond= itions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. =A0Type "show warranty" for d= etails. >>>> This GDB was configured as "i386-marcel-freebsd"... >>> [..] >>>> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ >>>> /usr/src/sys/netinet6/mld6.c:1676 >>>> >>>> cpuid =3D 0 >>>> KDB: enter: panic >>>> Uptime: 28s >>>> Physical memory: 491 MB >>>> Dumping 45 MB: 30 14 >>>> >>>> #0 =A0doadump (textdump=3D1) at pcpu.h:244 >>>> 244 =A0 =A0 pcpu.h: No such file or directory. >>>> =A0 =A0 =A0 =A0in pcpu.h >>>> (kgdb) #0 =A0doadump (textdump=3D1) at pcpu.h:244 >>>> #1 =A00xc0a04965 in kern_reboot (howto=3D260) >>>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:430 >>>> #2 =A00xc0a04291 in panic (fmt=3DVariable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:595 >>>> #3 =A00xc09f4a4a in _mtx_lock_sleep (m=3D0xc35f3a28, tid=3D3278693824,= opts=3D0, >>>> =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) >>>> =A0 =A0at /usr/src/sys/kern/kern_mutex.c:341 >>>> #4 =A00xc09f4c67 in _mtx_lock_flags (m=3D0xc35f3a28, opts=3D0, >>>> =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) >>>> =A0 =A0at /usr/src/sys/kern/kern_mutex.c:203 >>>> #5 =A00xc0bbf007 in mld_set_version (mli=3D0xc3589a00, version=3DVaria= ble >>>> "version" is not available. >>>> ) >>>> =A0 =A0at /usr/src/sys/netinet6/mld6.c:1676 >>>> #6 =A00xc0bc0c00 in mld_input (m=3D0xc3951e00, off=3D48, icmp6len=3D24= ) >>>> =A0 =A0at /usr/src/sys/netinet6/mld6.c:690 >>>> #7 =A00xc0ba5696 in icmp6_input (mp=3D0xc3313a54, offp=3D0xc3313a68, p= roto=3D58) >>>> =A0 =A0at /usr/src/sys/netinet6/icmp6.c:654 >>>> #8 =A00xc0bba23a in ip6_input (m=3D0xc3951e00) >>>> =A0 =A0at /usr/src/sys/netinet6/ip6_input.c:964 >>>> #9 =A00xc0ac9b1c in netisr_dispatch_src (proto=3D10, source=3D0, m=3D0= xc3951e00) >>>> =A0 =A0at /usr/src/sys/net/netisr.c:1013 >>>> #10 0xc0ac9da0 in netisr_dispatch (proto=3D10, m=3D0xc3951e00) >>>> =A0 =A0at /usr/src/sys/net/netisr.c:1104 >>>> #11 0xc0abecf1 in ether_demux (ifp=3D0xc35f3800, m=3D0xc3951e00) >>>> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:936 >>>> #12 0xc0abf1b3 in ether_nh_input (m=3D0xc3951e00) >>>> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:755 >>>> #13 0xc0ac9b1c in netisr_dispatch_src (proto=3D9, source=3D0, m=3D0xc3= 951e00) >>>> =A0 =A0at /usr/src/sys/net/netisr.c:1013 >>>> #14 0xc0ac9da0 in netisr_dispatch (proto=3D9, m=3D0xc3951e00) >>>> =A0 =A0at /usr/src/sys/net/netisr.c:1104 >>>> #15 0xc0abe7f5 in ether_input (ifp=3D0xc35f3800, m=3D0xc3951e00) >>>> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:796 >>>> #16 0xc0672bc9 in lem_handle_rxtx (context=3D0xc3732000, pending=3D1) >>>> =A0 =A0at /usr/src/sys/dev/e1000/if_lem.c:3554 >>>> #17 0xc0a468ab in taskqueue_run_locked (queue=3D0xc359ca80) >>>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:306 >>>> #18 0xc0a47307 in taskqueue_thread_loop (arg=3D0xc37365ec) >>>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:495 >>>> #19 0xc09d7af8 in fork_exit (callout=3D0xc0a472a0 , >>>> =A0 =A0arg=3D0xc37365ec, frame=3D0xc3313d28) at /usr/src/sys/kern/kern= _fork.c:941 >>>> #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/excepti= on.s:275 >>>> (kgdb) >>>> >>> >>> This is the same as in PR kern/158426. >>> Can you try the patch from PR followup and report us whether it helps? >>> Full link to PR with patch: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/158426 >>> >> >> I applied the patch and tried about 15 reboots and all went fine.... >> > > Hi, Tom. > A better fix for this problem has been developed since then. Would you > please try it as well? For doing that, you need to revert a previous > patch and apply this one. > Please report if this change also fixes the panic for you, so it =A0has > better chances to get into 9.0 release. > > > Index: sys/netinet6/mld6.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/netinet6/mld6.c (revision 224471) > +++ sys/netinet6/mld6.c (working copy) > @@ -680,7 +680,6 @@ mld_v1_input_query(struct ifnet *ifp, const struct > > =A0 =A0 =A0 =A0IN6_MULTI_LOCK(); > =A0 =A0 =A0 =A0MLD_LOCK(); > - =A0 =A0 =A0 IF_ADDR_LOCK(ifp); > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Switch to MLDv1 host compatibility mode. > @@ -693,6 +692,7 @@ mld_v1_input_query(struct ifnet *ifp, const struct > =A0 =A0 =A0 =A0if (timer =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0timer =3D 1; > > + =A0 =A0 =A0 IF_ADDR_LOCK(ifp); > =A0 =A0 =A0 =A0if (is_general_query) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * For each reporting group joined on this > @@ -888,7 +888,6 @@ mld_v2_input_query(struct ifnet *ifp, const struct > > =A0 =A0 =A0 =A0IN6_MULTI_LOCK(); > > =A0 =A0 =A0 =A0MLD_LOCK(); > - =A0 =A0 =A0 IF_ADDR_LOCK(ifp); > > =A0 =A0 =A0 =A0mli =3D MLD_IFINFO(ifp); > =A0 =A0 =A0 =A0KASSERT(mli !=3D NULL, ("%s: no mld_ifinfo for ifp %p", __= func__, ifp)); > @@ -936,14 +935,18 @@ mld_v2_input_query(struct ifnet *ifp, const struct > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Queries for groups we are not a member = of on this > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * link are simply ignored. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF_ADDR_LOCK(ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0inm =3D in6m_lookup_locked(ifp, &mld->mld_= addr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (inm =3D=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (inm =3D=3D NULL) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF_ADDR_UNLOCK(ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_locked; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (nsrc > 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!ratecheck(&inm->in6m_= lastgsrtv, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&V_mld_gsrdelay)) = { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CTR1(KTR_M= LD, "%s: GS query throttled.", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__= func__); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF_ADDR_UNL= OCK(ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_l= ocked; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > @@ -961,10 +964,10 @@ mld_v2_input_query(struct ifnet *ifp, const struct > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* XXX Clear embedded scope ID as userland= won't expect it. */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in6_clearscope(&mld->mld_addr); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF_ADDR_UNLOCK(ifp); > =A0 =A0 =A0 =A0} > > =A0out_locked: > - =A0 =A0 =A0 IF_ADDR_UNLOCK(ifp); > =A0 =A0 =A0 =A0MLD_UNLOCK(); > =A0 =A0 =A0 =A0IN6_MULTI_UNLOCK(); > > > -- > wbr, > pluknet > Applied your patch and rebooted about 10 times without problems, so the new patch works ok for me! From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 18:59:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97615106564A for ; Mon, 22 Aug 2011 18:59:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 247938FC0A for ; Mon, 22 Aug 2011 18:59:34 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=xmFjUGIb0+Qtkw36JMBkZ4MjFvRoLuHFC3dFHsXsG5g= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=J-K_0Bz8RJYA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8GiEO3FRut4fuwx88DUA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 169587788; Mon, 22 Aug 2011 20:59:27 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 22 Aug 2011 20:57:03 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1314030908626-4723962.post@n5.nabble.com> In-Reply-To: <1314030908626-4723962.post@n5.nabble.com> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108222057.03575.hselasky@c2i.net> Cc: Jakub Lach Subject: Re: kldload uhci, system grinds to halt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:59:35 -0000 On Monday 22 August 2011 18:35:08 Jakub Lach wrote: > Hello. > > Anybody is experiencing something similar? > > There was no such problem on 8-STABLE, this is > now FreeBSD 9.0-BETA1 #0 r225063 amd64, kernel > is semi-heavily stripped (usb is not compiled in). Is ACPI and PCI compiled? Are you able to get stats like vmstat -i ? Will try to reproduce. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 19:56:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B981106564A for ; Mon, 22 Aug 2011 19:56:41 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 289B58FC0A for ; Mon, 22 Aug 2011 19:56:40 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Qvabw-0002KT-8c for freebsd-current@freebsd.org; Mon, 22 Aug 2011 12:56:40 -0700 Date: Mon, 22 Aug 2011 12:56:40 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1314043000260-4724430.post@n5.nabble.com> In-Reply-To: <201108222057.03575.hselasky@c2i.net> References: <1314030908626-4723962.post@n5.nabble.com> <201108222057.03575.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: kldload uhci, system grinds to halt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:56:41 -0000 Hi, thanks for reply. ahci and pci is compiled in. I doubt I will be able to get vmstat, single xterm bell is continuous sound. I usually brought up usb by something like: # kldload usb umass uhci ehci and was only able to isolate cause to uhci module. Speaking of hardware, it's common Intel 82801I (ICH9 Family). As I think of it, maybe I don't need uhci after all, but I suspected I used it with usb/ums mouse. regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/kldload-uhci-system-grinds-to-halt-tp4723962p4724430.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 20:41:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 471B9106566C; Mon, 22 Aug 2011 20:41:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF5108FC0C; Mon, 22 Aug 2011 20:41:02 +0000 (UTC) Received: by gxk28 with SMTP id 28so4373749gxk.13 for ; Mon, 22 Aug 2011 13:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SgkyhBJ754sipOHyyjBTxjvEllNrb+A1ErUltZa8lbg=; b=pzj5nNDHjDUbsPcSfyOUCPMQgDXH4j2CFWjF/DvIg3FKkM2Wi6tH0pRfsCDs1qUeT9 rJkoW1eGokVslgcG2kgIw81lQMV4a/BAk8/+aTHRvsjPdGrysVXHWTrKzyzBaz5LcXjp pGu0NKxO32+iFDO+rDRHyHYwcedrZRI+d/GtM= Received: by 10.236.73.170 with SMTP id v30mr9976212yhd.15.1314045662045; Mon, 22 Aug 2011 13:41:02 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id z29sm996929yhn.44.2011.08.22.13.40.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 13:41:00 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 22 Aug 2011 13:40:54 -0700 From: YongHyeon PYUN Date: Mon, 22 Aug 2011 13:40:54 -0700 To: Garrett Cooper Message-ID: <20110822204054.GB4452@michelle.cdnetworks.com> References: <20110821234856.GB1755@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110821234856.GB1755@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 20:41:03 -0000 On Sun, Aug 21, 2011 at 04:48:56PM -0700, YongHyeon PYUN wrote: > On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: > > On Thu, Aug 18, 2011 at 9:31 PM, wrote: > > > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote: > > >> ? ?When loading if_alc as a module on my netbook and running > > >> /etc/rc.d/netif restart, I can deterministically panic my netbook with > > >> the following message: > > > > These repro steps were overly simplified. The complete steps are: > > > > 1. Attach ethernet cable to alc(4) enabled NIC. > > 2. Boot up machine. > > 3. Login. > > 4. Physically remove ethernet cable from alc(4) enabled NIC. > > 5. Run `/etc/rc.d/netif restart' as root. > > > > I can't reproduce this with AR8151 sample board. Could you give me > dmesg output to know exact controller revision? > One issue I'm aware of is lack of re-establishing link when > controller firmware put its PHY to deep sleep mode. The deep sleep > mode seems to be automatically activated by firmware when it > detects no energy signal(i.e. cable unplugged) so I had to down and > up the interface again to take the PHY out of the sleep mode. > Not re-establishing link issue was fixed in r225088. I'm not sure whether this also fixes kern/148772 though. Because you also seem to have the same issue of the PR, it would be good to know whether it makes any difference or not. > > >> ) at _bus_dmamap_sync+0x51 > > >> alc_stop(c3dbb000,0,c0c51844,93a,80206910,...) at alc_stop+0x24e > > >> alc_ioctl(c3d07400,80206910,c40423c0,c06a7935,c0914e3c,...) at alc_ioctl+0x22e > > >> ifioctl(c45029c0,80206910,c40423c0,c40505c0,c4528c00,...) at ifioctl+0xc98 > > >> soo_ioctl(c4574e00,80206910,c40423c0,c413e680,c40505c0,...) at soo_ioctl+0x401 > > >> kern_ioctl(c40505c0,3,80206910,c40423c0,c40423c0,...) at kern_ioctl+0x1d7 > > >> ioctl(c40505c0,e6ca3cec,e6ca3d28,c08e929d,0,...) at ioctl+0x118 > > >> syscallenter(c40505c0,e6ca3ce4,e6ca3ce4,0,0,...) at syscallenter+0x23f > > >> syscall(e6ca3d28) at syscall+0x2e > > >> Xint0x80_syscall() at Xint0x80_syscall+0x21 > > >> --- syscall (54kernel trap 12 with interrupts disabled > > >> Kernel page fault with the following non-sleepable locks held: > > >> exclusive sleep mutex alc0 (network driver) r = 0 (0xc3dbc608) locked > > >> @ /usr/src/sys/modules/alc/../../dev/alc/if_alc.c:2362 > > >> KDB: stack backtrace: > > >> db_trace_self_wrapper(c08e727a,80,6e726500,74206c65,20706172,...) at > > >> db_trace_self_wrapper+0x26 > > >> kdb_backtrace(93a,0,ffffffff,c0ad6114,e6ca323c,...) at kdb_backtrace+0x2a > > >> _witness_debugger(c08e9f67,e6ca3250,4,1,0,...) at _witness_debugger+0x1e > > >> witness_warn(5,0,c0924fe1,c097df50,c3e42b00,...) at witness_warn+0x1f1 > > >> trap(e6ca32dc) at trap+0x15a > > >> calltrap() at calltrap+0x6 > > >> > > >> ? ?I tried to track down what the exact issue was, but I got lost > > >> (the locking sort of looks ok to me, but I'm still not an expert with > > >> mutex(9)). > > >> ? ?I still have the vmcore and can provide more helpful details when requested. > > > > > > The locking itself is almost certainly fine. ?The error message is not > > > very helpful, but what went wrong was the page fault. ?You just happen > > > to panic on a witness warning before vm_fault can panic due to a bad > > > address. > > > > > > The alc(4) maintainer would probably like info on the trap (line of > > > code and where the bad pointer came from). > > > > I talked to Xin a bit and as he noted the panic was just a symptom > > of the actual issue at hand. I think the problem is that the rx ring's > > rx_m value isn't set to NULL when an error occurred, but getting to > > the exact problem at hand, the following call is failing: > > > > if (bus_dmamap_load_mbuf_sg(sc->alc_cdata.alc_rx_tag, // <-- HERE > > sc->alc_cdata.alc_rx_sparemap, m, segs, &nsegs, 0) != 0) { > > m_freem(m); > > return (ENOBUFS); > > } > > > > It's failing with ENOMEM. Still trying to determine what the exact > > Even if bus_dmamap_load_mbuf_sg(9) fails driver should not panic. > Could you show me full back-trace? > > > reason for ENOMEM is from the x86 busdma code though.. > > Thanks, > > -Garrett > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 21:26:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FE06106564A; Mon, 22 Aug 2011 21:26:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBB0B8FC1A; Mon, 22 Aug 2011 21:26:48 +0000 (UTC) Received: by qwc9 with SMTP id 9so4303472qwc.13 for ; Mon, 22 Aug 2011 14:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nqgzhkOMH+w9/Ntp1tybCaCzegUUUprVcEPbNlijY6U=; b=nX2W4jyd3Ip4WJS/dbTa103P0AQKkSRf2OYIC00RChdUuPZMGO0gdAkabZe/Tsg/k1 DOYgpbW3AKCxzGMULvXNDbCaqZ2xZCE2d949qQELoe1+vLGHJ0p4ypasXAJHiJ4UHijm gCFc6GhtlPmAqJM3mcSkqLixyUV5VpCX1FgiA= MIME-Version: 1.0 Received: by 10.224.208.130 with SMTP id gc2mr1779976qab.329.1314048408036; Mon, 22 Aug 2011 14:26:48 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Mon, 22 Aug 2011 14:26:47 -0700 (PDT) In-Reply-To: <20110822204054.GB4452@michelle.cdnetworks.com> References: <20110821234856.GB1755@michelle.cdnetworks.com> <20110822204054.GB4452@michelle.cdnetworks.com> Date: Mon, 22 Aug 2011 14:26:47 -0700 Message-ID: From: Garrett Cooper To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:26:49 -0000 On Mon, Aug 22, 2011 at 1:40 PM, YongHyeon PYUN wrote: > On Sun, Aug 21, 2011 at 04:48:56PM -0700, YongHyeon PYUN wrote: >> On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: >> > On Thu, Aug 18, 2011 at 9:31 PM, =A0 wrote: >> > > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper = wrote: >> > >> ? ?When loading if_alc as a module on my netbook and running >> > >> /etc/rc.d/netif restart, I can deterministically panic my netbook w= ith >> > >> the following message: >> > >> > =A0 =A0 These repro steps were overly simplified. The complete steps a= re: >> > >> > 1. Attach ethernet cable to alc(4) enabled NIC. >> > 2. Boot up machine. >> > 3. Login. >> > 4. Physically remove ethernet cable from alc(4) enabled NIC. >> > 5. Run `/etc/rc.d/netif restart' as root. >> > >> >> I can't reproduce this with AR8151 sample board. Could you give me >> dmesg output to know exact controller revision? >> One issue I'm aware of is lack of re-establishing link when >> controller firmware put its PHY to deep sleep mode. =A0The deep sleep >> mode seems to be automatically activated by firmware when it >> detects no energy signal(i.e. cable unplugged) so I had to down and >> up the interface again to take the PHY out of the sleep mode. >> > > Not re-establishing link issue was fixed in r225088. =A0I'm not sure > whether this also fixes kern/148772 though. Because you also seem > to have the same issue of the PR, it would be good to know whether > it makes any difference or not. The panic no longer occurs with that commit when running /etc/rc.d/netif restart after inserting and reinserting the ethernet cable (I've done it several times for good measure); the failing case was potentially being triggered somehow by the hibernation code path. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 21:35:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906D3106564A; Mon, 22 Aug 2011 21:35:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7648FC08; Mon, 22 Aug 2011 21:35:56 +0000 (UTC) Received: by gyd10 with SMTP id 10so4404226gyd.13 for ; Mon, 22 Aug 2011 14:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3yCxoyJFEcrtm+OJ3MfN2BzLimMlIvBA5JXPEumgPjQ=; b=p451xAwezjJ5AjOb0L809dUK2p/+3rRBV6hS8xBjeg31ZKpwJvIm9YiGAkOwejQm/Z DM3pD4dORfcqBT44kZBih7CtOhV1kr7ZDVvcWt8+se6C6Veeuijcg9kfKKs9cjFyvfND ZlX0S04HUwquJ1Ak+JzYd+F6LorfsEpb88tG8= Received: by 10.101.212.12 with SMTP id o12mr1027110anq.31.1314048956363; Mon, 22 Aug 2011 14:35:56 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id e4sm5571933anb.15.2011.08.22.14.35.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 14:35:55 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 22 Aug 2011 14:35:49 -0700 From: YongHyeon PYUN Date: Mon, 22 Aug 2011 14:35:49 -0700 To: Garrett Cooper Message-ID: <20110822213549.GC4452@michelle.cdnetworks.com> References: <20110821234856.GB1755@michelle.cdnetworks.com> <20110822204054.GB4452@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:35:57 -0000 On Mon, Aug 22, 2011 at 02:26:47PM -0700, Garrett Cooper wrote: > On Mon, Aug 22, 2011 at 1:40 PM, YongHyeon PYUN wrote: > > On Sun, Aug 21, 2011 at 04:48:56PM -0700, YongHyeon PYUN wrote: > >> On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: > >> > On Thu, Aug 18, 2011 at 9:31 PM, ? wrote: > >> > > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote: > >> > >> ? ?When loading if_alc as a module on my netbook and running > >> > >> /etc/rc.d/netif restart, I can deterministically panic my netbook with > >> > >> the following message: > >> > > >> > ? ? These repro steps were overly simplified. The complete steps are: > >> > > >> > 1. Attach ethernet cable to alc(4) enabled NIC. > >> > 2. Boot up machine. > >> > 3. Login. > >> > 4. Physically remove ethernet cable from alc(4) enabled NIC. > >> > 5. Run `/etc/rc.d/netif restart' as root. > >> > > >> > >> I can't reproduce this with AR8151 sample board. Could you give me > >> dmesg output to know exact controller revision? > >> One issue I'm aware of is lack of re-establishing link when > >> controller firmware put its PHY to deep sleep mode. ?The deep sleep > >> mode seems to be automatically activated by firmware when it > >> detects no energy signal(i.e. cable unplugged) so I had to down and > >> up the interface again to take the PHY out of the sleep mode. > >> > > > > Not re-establishing link issue was fixed in r225088. ?I'm not sure > > whether this also fixes kern/148772 though. Because you also seem > > to have the same issue of the PR, it would be good to know whether > > it makes any difference or not. > > The panic no longer occurs with that commit when running > /etc/rc.d/netif restart after inserting and reinserting the ethernet > cable (I've done it several times for good measure); the failing case > was potentially being triggered somehow by the hibernation code path. Hmm, have no idea how this can be related with the panic. :-( BTW, does the commit also fix kern/148772? > Thanks, > -Garrett > From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 21:39:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF13106564A; Mon, 22 Aug 2011 21:39:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB918FC14; Mon, 22 Aug 2011 21:39:55 +0000 (UTC) Received: by qyk9 with SMTP id 9so2964223qyk.13 for ; Mon, 22 Aug 2011 14:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NLtuO9F7ILEFMe/iyoZ//gJ4K6L25dVxjGp+SrcoRXM=; b=Ov3Jdbh6AJDX0P0WlKgtrTTX5fFgGbOLsNyHVCrkKaTWCcO0A2vfq+Dnl2BX9s/lKQ SYeQbUjyCTJtnUB8/aY0dyPdkt/i89a+yqxI14jbJB9kg4jbikQSlOiGp8f2QFX75O3n 22c6vP0EoZkOFAxQ0m0upq3DIk/UFOKUB4zDc= MIME-Version: 1.0 Received: by 10.224.216.1 with SMTP id hg1mr1816901qab.179.1314049194673; Mon, 22 Aug 2011 14:39:54 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Mon, 22 Aug 2011 14:39:54 -0700 (PDT) In-Reply-To: <20110822213549.GC4452@michelle.cdnetworks.com> References: <20110821234856.GB1755@michelle.cdnetworks.com> <20110822204054.GB4452@michelle.cdnetworks.com> <20110822213549.GC4452@michelle.cdnetworks.com> Date: Mon, 22 Aug 2011 14:39:54 -0700 Message-ID: From: Garrett Cooper To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, FreeBSD Current , Pyun YongHyeon Subject: Re: Deterministic panic due to non-sleepable lock with if_alc when reconfiguring interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:39:56 -0000 On Mon, Aug 22, 2011 at 2:35 PM, YongHyeon PYUN wrote: > On Mon, Aug 22, 2011 at 02:26:47PM -0700, Garrett Cooper wrote: >> On Mon, Aug 22, 2011 at 1:40 PM, YongHyeon PYUN wrote= : >> > On Sun, Aug 21, 2011 at 04:48:56PM -0700, YongHyeon PYUN wrote: >> >> On Fri, Aug 19, 2011 at 12:17:12AM -0700, Garrett Cooper wrote: >> >> > On Thu, Aug 18, 2011 at 9:31 PM, ? wrote: >> >> > > On Thu, Aug 18, 2011 at 5:50 PM, Garrett Cooper wrote: >> >> > >> ? ?When loading if_alc as a module on my netbook and running >> >> > >> /etc/rc.d/netif restart, I can deterministically panic my netboo= k with >> >> > >> the following message: >> >> > >> >> > ? ? These repro steps were overly simplified. The complete steps ar= e: >> >> > >> >> > 1. Attach ethernet cable to alc(4) enabled NIC. >> >> > 2. Boot up machine. >> >> > 3. Login. >> >> > 4. Physically remove ethernet cable from alc(4) enabled NIC. >> >> > 5. Run `/etc/rc.d/netif restart' as root. >> >> > >> >> >> >> I can't reproduce this with AR8151 sample board. Could you give me >> >> dmesg output to know exact controller revision? >> >> One issue I'm aware of is lack of re-establishing link when >> >> controller firmware put its PHY to deep sleep mode. ?The deep sleep >> >> mode seems to be automatically activated by firmware when it >> >> detects no energy signal(i.e. cable unplugged) so I had to down and >> >> up the interface again to take the PHY out of the sleep mode. >> >> >> > >> > Not re-establishing link issue was fixed in r225088. ?I'm not sure >> > whether this also fixes kern/148772 though. Because you also seem >> > to have the same issue of the PR, it would be good to know whether >> > it makes any difference or not. >> >> =A0 =A0 The panic no longer occurs with that commit when running >> /etc/rc.d/netif restart after inserting and reinserting the ethernet >> cable (I've done it several times for good measure); the failing case >> was potentially being triggered somehow by the hibernation code path. > > Hmm, have no idea how this can be related with the panic. :-( > BTW, does the commit also fix kern/148772? Yup. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 01:18:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACC161065670 for ; Tue, 23 Aug 2011 01:18:24 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mx1.freebsd.org (Postfix) with ESMTP id 56AC48FC12 for ; Tue, 23 Aug 2011 01:18:24 +0000 (UTC) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20110823011819.DXCI32549.eastrmfepo201.cox.net@eastrmimpo02.cox.net> for ; Mon, 22 Aug 2011 21:18:19 -0400 Received: from serene.no-ip.org ([98.164.83.25]) by eastrmimpo02.cox.net with bizsmtp id PdJJ1h00Z0YnB6A02dJJ9m; Mon, 22 Aug 2011 21:18:19 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.4E52FFDB.0017,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=L18tZtgXvCjggtrPsn7EqxywmDwdeqj6Yva+6kM3mdg= c=1 sm=1 a=jWUiUVLpvAUA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=2vO5UZG1h46htWAnE/rx2g==:17 a=kviXuzpPAAAA:8 a=BRkwVJW0SWS2U0z8nvoA:9 a=CjuIK1q_8ugA:10 a=4vB-4DCPJfMA:10 a=2vO5UZG1h46htWAnE/rx2g==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id p7N1IIfd018103 for ; Mon, 22 Aug 2011 20:18:18 -0500 (CDT) (envelope-from conrads@cox.net) Date: Mon, 22 Aug 2011 20:18:12 -0500 From: "Conrad J. Sabatier" To: freebsd-current@FreeBSD.org Message-ID: <20110822201812.04a11b17@cox.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: bsdinstall: partitioning dialog doesn't feel "safe" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 01:18:24 -0000 Today I decided to finally go ahead and repartition my external (USB) drive (da3) that I had originally installed 9.0-BETA1 on (I've since installed on, and am now running from, my main internal drive, ada0). I wanted to try this with the new installer, rather than the old sysinstall. When I got to the partitioning dialog, I became a little concerned, in that, unlike the earlier sysinstall, both drives' current partitioning schemes were displayed, and I didn't feel too comfortable with making any changes and possibly disturbing my working installation on ada0, so I quickly exited and used the command line tools to accomplish the job. OK, call me paranoid, but I'd personally much prefer to be able to select a single drive as before, to know that I'm working only with that device at the moment, and be able to feel reasonably certain that no other device will be touched. The current dialog doesn't exactly foster that feeling. While I can see where there may be some benefits to having all known devices/partitions displayed at once (say, for the sake of flexibility), nonetheless, it can also feel a little unsafe, if not downright unnerving. Perhaps some alternative could be provided? I've been away for a good while, and will admit to not having followed any of the discussion leading up to the current design, but does anyone think there may be something to what I'm saying? Over the long haul, it could become an issue that you may be hearing about from users other than myself. Thank you, and I hope this isn't considered a waste of bandwidth. :-) -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 03:47:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8189C1065734; Tue, 23 Aug 2011 03:47:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E58D214E4AE; Tue, 23 Aug 2011 03:47:33 +0000 (UTC) Message-ID: <4E5322D5.7030403@FreeBSD.org> Date: Mon, 22 Aug 2011 20:47:33 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: Andrej Zverev References: <201108201123.p7KBNYFO008124@172-17-198-245.globalsuite.net> <4E520C64.1080603@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perl@freebsd.org, FreeBSD Current Subject: Re: periodic weekly catman - perl problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 03:47:35 -0000 On 08/22/2011 09:41, Andrej Zverev wrote: > > > On Mon, Aug 22, 2011 at 11:59 AM, Doug Barton > wrote: > > I have the catman option enabled for periodic/weekly and get the > following errors: > > Reformatting manual pages: > catman: /usr/local/lib/perl5/5.12.4/man/cat3: mkdir: Permission denied > catman: /usr/local/lib/perl5/5.12.4/perl/man/cat3: mkdir: Permission > denied > > > It seems that the cat3 directories are not created because the man > directories are owned by root, and the cat* directories are owned by > man, which is what the 330.catman script operates as. > > Creating those directories with the proper permissions allows the catman > periodic script to do its thing. So my question is, is this something > that the catman periodic script should be doing, or should the perl port > be doing it? > > Hello, Doug. I couldn't find which way is correct in this situation but > I can propose the following patch: > http://sunner.semmy.ru/~az/perl-man.txt if this solve issue when you can > knock-knock at skv's (perl maintainer) door. Thanks for looking at this, but you're solving the wrong problem. :) It's the cat* directories that need to be owned by man. Having thought about this more, I think it's the 330.catman script that needs to ensure that these directories exist, likely with 'install -d'. I'll try to get to it, but if someone else is quicker ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 10:03:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14BDF106566C for ; Tue, 23 Aug 2011 10:03:59 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 999398FC14 for ; Tue, 23 Aug 2011 10:03:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qvnpr-0008Va-O6 for freebsd-current@freebsd.org; Tue, 23 Aug 2011 12:03:55 +0200 Received: from 208.88.188.90.adsl.tomsknet.ru ([90.188.88.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Aug 2011 12:03:55 +0200 Received: from vadim_nuclight by 208.88.188.90.adsl.tomsknet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Aug 2011 12:03:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Vadim Goncharov Date: Tue, 23 Aug 2011 10:03:41 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 53 Message-ID: References: <927966496.20110820112229@serebryakov.spb.ru> <4E513802.9090306@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.88.188.90.adsl.tomsknet.ru X-Comment-To: Nathan Whitehorn User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: / auto-sizing (Was: 9.0-BETA1 installer glithcies (i386)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:03:59 -0000 Hi Nathan Whitehorn! On Sun, 21 Aug 2011 11:53:22 -0500; Nathan Whitehorn wrote about 'Re: 9.0-BETA1 installer glithcies (i386)': >> (3) "Auto" creates one big / partition + SWAP. It looks very not-BSD >> way (disk is only 8Gb, it is virtual machine). > This is designed to ease resizing on VMs as well as to kill the > default-/-is-too-small problem forever. There was a great deal of > discussion about this several months ago; no one made a final proposal > for changing it. Actually, it's simple: make / be able to survive 5 years from now (a reasonable age before major upgrade). So, the size needs to be predicted. http://en.wikipedia.org/wiki/File:Hard_drive_capacity_over_time.svg says that hard disks sizes grow according to Moore's Law, 10 times per 5 years. The FreeBSD kernel sizes grow slower, though. As of src/usr.sbin/sysinstall/label.c CVS log: rev 1.161: / 1 Gb in Jul 2010 rev 1.149: / 512 Mb in Aug 2005, formulas for other pertitions provided, / 256 Mb if RAMsize/harddisk size gives another value rev 1.106: / 120 Mb in Apr 2001 ...added by tens of Mbs before, not doubled So it doubles or fourths every 5 years, thus, to reserve, let's set / to 2 or 4 Gb in 2011. Also don't create /tmp partition but rather do: lrwxr-xr-x 1 root wheel - 12 9 Jan 2010 /tmp -> /var/tmp/tmp drwxrwxrwt 9 root wheel sunlnk 1024 23 Aug 16:55 /var/tmp/tmp Actually, this is just most simple short-term solution for auto-sizing. For long-term, it should be considered to merge / and /usr with separate partitions for ports, local, and so on, that's easy on ZFS. I have on 7.x: Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1.4G 1.1G 253M 81% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 4.4G 3.9G 66M 98% /home /dev/ad0s1e 6.8G 4.4G 1.9G 70% /usr/local /dev/ad0s1d 1.9G 1.4G 412M 77% /var devfs 1.0K 1.0K 0B 100% /var/named/dev lrwxr-xr-x 1 root wheel 13 29 ÄÅË 2009 /usr/obj -> local/BSD/obj lrwxr-xr-x 1 root wheel 15 29 ÄÅË 2009 /usr/ports -> local/BSD/ports lrwxr-xr-x 1 root wheel 13 29 ÄÅË 2009 /usr/src -> local/BSD/src but that will cause another long boring bikesched without clear final proposal :-) So for 9.0R it is simpler to take short-term approach. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 11:13:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40102106567C for ; Tue, 23 Aug 2011 11:13:02 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from web01.lando.us (web01.lando.us [77.232.247.17]) by mx1.freebsd.org (Postfix) with ESMTP id 088AC8FC0C for ; Tue, 23 Aug 2011 11:13:01 +0000 (UTC) Received: from R2D2 (bridge.aixit.com [82.149.224.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: uwe@grohnwaldt.eu) by web01.lando.us (Postfix) with ESMTPSA id 9025879D07 for ; Tue, 23 Aug 2011 12:57:41 +0200 (CEST) From: "Uwe Grohnwaldt" To: Date: Tue, 23 Aug 2011 12:57:45 +0200 Message-ID: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxhguJVDnRE8EQWTIud3HJdutMrnA== Content-Language: de Cc: Subject: Panic with 9.0 Beta 1 (arcmsr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:13:02 -0000 Hi, i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a kernel panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 A screenshot from the panic can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png Chers, Uwe From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 11:40:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 139E11065673 for ; Tue, 23 Aug 2011 11:40:14 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id B4F808FC1D for ; Tue, 23 Aug 2011 11:40:13 +0000 (UTC) Received: from msx3.exchange.alogis.com (msx3exchange.alogis.com [10.1.1.6] (may be forged)) by alogis.com (8.13.4/8.13.1) with ESMTP id p7NBT5B3082714 for ; Tue, 23 Aug 2011 13:29:05 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Tue, 23 Aug 2011 13:29:51 +0200 From: Holger Kipp To: "current@freebsd.org" Thread-Topic: LOR 9.0 beta1 Thread-Index: AQHMYYf4k1P63m2CZkK0qycGmnrLJg== Date: Tue, 23 Aug 2011 11:29:50 +0000 Message-ID: <4FE605DD-17CC-4378-9418-50BEE438296E@alogis.com> Accept-Language: en-GB, de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8253F0BC40A9B4419AE094837066E687@exchange.alogis.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: LOR 9.0 beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:40:14 -0000 Maybe already seen... This is within Parallels 6.0 VM on a Mac with OS 10.6.8 Aug 23 09:11:54 tramp kernel: lock order reversal: Aug 23 09:11:54 tramp kernel: 1st 0xffffff803d3d08b8 bufwait (bufwait) @ /u= sr/src/sys/kern/vfs_bio.c:2658 Aug 23 09:11:54 tramp kernel: 2nd 0xfffffe0002b6c800 dirhash (dirhash) @ /u= sr/src/sys/ufs/ufs/ufs_dirhash.c:284 Aug 23 09:11:54 tramp kernel: KDB: stack backtrace: Aug 23 09:11:54 tramp kernel: db_trace_self_wrapper() at db_trace_self_wrap= per+0x2a Aug 23 09:11:54 tramp kernel: kdb_backtrace() at kdb_backtrace+0x37 Aug 23 09:11:54 tramp kernel: _witness_debugger() at _witness_debugger+0x2e Aug 23 09:11:54 tramp kernel: witness_checkorder() at witness_checkorder+0x= 807 Aug 23 09:11:54 tramp kernel: _sx_xlock() at _sx_xlock+0x55 Aug 23 09:11:54 tramp kernel: ufsdirhash_acquire() at ufsdirhash_acquire+0x= 33 Aug 23 09:11:54 tramp kernel: ufsdirhash_add() at ufsdirhash_add+0x19 Aug 23 09:11:54 tramp kernel: ufs_direnter() at ufs_direnter+0x8c9 Aug 23 09:11:54 tramp kernel: ufs_makeinode() at ufs_makeinode+0x25b Aug 23 09:11:54 tramp kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0x8d Aug 23 09:11:54 tramp kernel: vn_open_cred() at vn_open_cred+0x46a Aug 23 09:11:54 tramp kernel: kern_openat() at kern_openat+0x17f Aug 23 09:11:54 tramp kernel: syscallenter() at syscallenter+0x1aa Aug 23 09:11:54 tramp kernel: syscall() at syscall+0x4c Aug 23 09:11:54 tramp kernel: Xfast_syscall() at Xfast_syscall+0xdd Aug 23 09:11:54 tramp kernel: --- syscall (5, FreeBSD ELF64, open), rip =3D= 0x801348e2c, rsp =3D 0x7fffffffd658, rbp =3D 0x8 --- Aug 23 09:18:44 tramp kernel: lock order reversal: Aug 23 09:18:44 tramp kernel: 1st 0xfffffe0015459278 ufs (ufs) @ /usr/src/s= ys/kern/vfs_lookup.c:501 Aug 23 09:18:44 tramp kernel: 2nd 0xffffff803d4889b8 bufwait (bufwait) @ /u= sr/src/sys/ufs/ffs/ffs_vnops.c:261 Aug 23 09:18:44 tramp kernel: 3rd 0xfffffe00154b5db8 ufs (ufs) @ /usr/src/s= ys/kern/vfs_subr.c:2134 Aug 23 09:18:44 tramp kernel: KDB: stack backtrace: Aug 23 09:18:44 tramp kernel: db_trace_self_wrapper() at db_trace_self_wrap= per+0x2a Aug 23 09:18:44 tramp kernel: kdb_backtrace() at kdb_backtrace+0x37 Aug 23 09:18:44 tramp kernel: _witness_debugger() at _witness_debugger+0x2e Aug 23 09:18:44 tramp kernel: witness_checkorder() at witness_checkorder+0x= 807 Aug 23 09:18:44 tramp kernel: __lockmgr_args() at __lockmgr_args+0xd42 Aug 23 09:18:44 tramp kernel: ffs_lock() at ffs_lock+0x8c Aug 23 09:18:44 tramp kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b Aug 23 09:18:44 tramp kernel: _vn_lock() at _vn_lock+0x47 Aug 23 09:18:44 tramp kernel: vget() at vget+0x7b Aug 23 09:18:44 tramp kernel: vfs_hash_get() at vfs_hash_get+0xd5 Aug 23 09:18:44 tramp kernel: ffs_vgetf() at ffs_vgetf+0x48 Aug 23 09:18:44 tramp kernel: softdep_sync_buf() at softdep_sync_buf+0x547 Aug 23 09:18:44 tramp kernel: ffs_syncvnode() at ffs_syncvnode+0x299 Aug 23 09:18:44 tramp kernel: ffs_truncate() at ffs_truncate+0x463 Aug 23 09:18:44 tramp kernel: ufs_direnter() at ufs_direnter+0x6ff Aug 23 09:18:44 tramp kernel: ufs_makeinode() at ufs_makeinode+0x25b Aug 23 09:18:44 tramp kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0x8d Aug 23 09:18:44 tramp kernel: vn_open_cred() at vn_open_cred+0x46a Aug 23 09:18:44 tramp kernel: kern_openat() at kern_openat+0x17f Aug 23 09:18:44 tramp kernel: syscallenter() at syscallenter+0x1aa Aug 23 09:18:44 tramp kernel: syscall() at syscall+0x4c Aug 23 09:18:44 tramp kernel: Xfast_syscall() at Xfast_syscall+0xdd Aug 23 09:18:44 tramp kernel: --- syscall (5, FreeBSD ELF64, open), rip =3D= 0x800dc6e2c, rsp =3D 0x7fffffffd2d8, rbp =3D 0x1 --- Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 11:43:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 643DF1065672 for ; Tue, 23 Aug 2011 11:43:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 264568FC18 for ; Tue, 23 Aug 2011 11:43:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B34B246B97; Tue, 23 Aug 2011 07:43:11 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 505038A02E; Tue, 23 Aug 2011 07:43:11 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 23 Aug 2011 07:43:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> In-Reply-To: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108230743.10489.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 23 Aug 2011 07:43:11 -0400 (EDT) Cc: Uwe Grohnwaldt Subject: Re: Panic with 9.0 Beta 1 (arcmsr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:43:12 -0000 On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: > Hi, > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a > kernel panic: > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock > @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > A screenshot from the panic can be found here: > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png Looks like this was fixed after BETA1 was released. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 11:44:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CC3106566B for ; Tue, 23 Aug 2011 11:44:53 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9291C8FC0C for ; Tue, 23 Aug 2011 11:44:52 +0000 (UTC) Received: by ewy1 with SMTP id 1so8329ewy.13 for ; Tue, 23 Aug 2011 04:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fgBkqsobhAv08PlkdH29mthOHhw2vIpCdWPqk1BIZXQ=; b=cdtOICDlmFetR8bStQ199mYzTJZgJNSH9amH1uaWcSbtM37snPafii9YXtH35/YtZh PrFIjuA5pe9XFvw4F+p8pM0fHFs4DwdGyl/p/aZkg5npqSCQmZCVhDMBPDtwiHH3349V NCWVLlOO10L7UcWn5UAlC8CwD3X/0Buuql07I= MIME-Version: 1.0 Received: by 10.14.147.15 with SMTP id s15mr1011178eej.100.1314098257755; Tue, 23 Aug 2011 04:17:37 -0700 (PDT) Received: by 10.14.98.73 with HTTP; Tue, 23 Aug 2011 04:17:37 -0700 (PDT) In-Reply-To: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> References: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> Date: Tue, 23 Aug 2011 15:17:37 +0400 Message-ID: From: Sergey Kandaurov To: Uwe Grohnwaldt Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Panic with 9.0 Beta 1 (arcmsr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:44:53 -0000 On 23 August 2011 14:57, Uwe Grohnwaldt wrote: > Hi, > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a > kernel panic: > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock > @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > A screenshot from the panic can be found here: > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png HI, that should be fixed in head (and in forthcoming BETA2). You can apply this patch from head to fix panic: http://svnweb.freebsd.org/base/head/sys/dev/arcmsr/arcmsr.c?view=patch&r1=224905&r2=224904&pathrev=224905 -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 11:46:31 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04FC61065679; Tue, 23 Aug 2011 11:46:31 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id A9F5E8FC13; Tue, 23 Aug 2011 11:46:30 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 8FCDC9A3; Tue, 23 Aug 2011 13:31:02 +0200 (CEST) Date: Tue, 23 Aug 2011 13:30:45 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110823113044.GB1662@garage.freebsd.pl> References: <20110820.142859.319295417241413417.hrs@allbsd.org> <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <59520805.118597.1313885734529.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hiroki Sato , current@FreeBSD.org, Benjamin Kaduk Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:46:31 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote: > Hiroki, could you please test the attached patch. >=20 > One problem with this patch is that I don't know how to create a fixed > table that matches what systems would already have been getting. > (I got the first 6 entries by booting a GENERIC i386 kernel with a > printf in vfs_init(), so I suspect those don't change much, although > I'm not sure if ZFS will usually end up before or after them?) >=20 > Do you guys know what ZFS gets assigned typically? (I realize that > changes w.r.t. when it gets loaded, so the question also becomes > "do you know how it typically gets loaded" so the table can have > that vfc_typenum value assigned to it?) > Maybe you could boot a system with a printf like: >=20 > printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum); >=20 > just after vfc->vfc_typenum =3D maxvfsconf++; in vfs_init() and > then look in dmesg after booting, to see what your tables look like? > (Without the attached patch installed.) Rick, I'm sorry to arrive so late, but in my opinion hardcoding list of file systems in the kernel is a step in wrong direction, really. We are trying to keep things modularized, so there are no such things laying around that have to be cleaned up when file system goes away or updated when new file system arrives. I remember for example fts code where I found that it keeps list of file systems that can be handled faster. ZFS could have been handled faster, but I found this after few years. For this case there should be VFCF_* flag that fts shuld recognize and not hardcore file system names. This was also the reason that when I added support for "jail-friendly" file systems and support for file systems with delegated administration I haven't created list of file system types that support it, but added VFCF_JAIL and VFCF_DELEGADMIN flags. Here you cannot use those flags to solve the problem, but hardcoding file system types in an array is really not the way to go. I much prefer Ben's idea of calculating a hash from file system name and detecting collisions. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk5Tj2QACgkQForvXbEpPzSsPACgs1bUMf9f8+B3oXBuQ8iw4+Dy AKMAoKeIoNcEww/EZpfyMnTL/XuDug5x =aUbk -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 12:09:19 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B13FC106566C; Tue, 23 Aug 2011 12:09:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 44E0D8FC0C; Tue, 23 Aug 2011 12:09:17 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA25743; Tue, 23 Aug 2011 15:09:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E53986B.5000804@FreeBSD.org> Date: Tue, 23 Aug 2011 15:09:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Aug 2011 12:17:18 +0000 Cc: Subject: skipping locks, mutex_owned, usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:09:19 -0000 Yes, the subject sounds quite hairy, so please let me try to explain it. First, let's consider one concrete function: static int ukbd_poll(keyboard_t *kbd, int on) { struct ukbd_softc *sc = kbd->kb_data; if (!mtx_owned(&Giant)) { /* XXX cludge */ int retval; mtx_lock(&Giant); retval = ukbd_poll(kbd, on); mtx_unlock(&Giant); return (retval); } if (on) { sc->sc_flags |= UKBD_FLAG_POLLING; sc->sc_poll_thread = curthread; } else { sc->sc_flags &= ~UKBD_FLAG_POLLING; ukbd_start_timer(sc); /* start timer */ } return (0); } This "XXX cludge" [sic] pattern is scattered around a few functions in the ukbd code and perhaps other usb code: func() { if (!mtx_owned(&Giant)) { mtx_lock(&Giant); func(); mtx_unlock(&Giant); return; } // etc ... } I have a few question directly and indirectly related to this pattern. I. [Why] do we need this pattern? Can the code be re-written in a smarter (if not to say proper) way? II. ukbd_poll() in particular can be called from the kdb context (kdb_trap -> db_trap -> db_command_loop -> etc). What would happen if the Giant is held by a thread on some other CPU (which would be hard-stopped by kdp_trap)? Won't we get a lockup here? So shouldn't this code actually check for kdb_active? III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite chains of 'infinite' recursion because mtx_owned() always returns false. This is because I skip all lock/unlock/etc operations in the post-panic context. I think that it's a good philosophical question: what operations like mtx_owned(), mtx_recursed(), mtx_trylock() 'should' return when we actually act as if no locks exist at all? My first knee-jerk reaction was to change mtx_owned() to return true in this "lock-less" context, but _hypothetically_ there could exist some symmetric code that does something like: func() { if (mtx_owned(&Giant)) { mtx_unlock(&Giant); func(); mtx_lock(&Giant); return; } // etc ... What do you think about this problem? Should we re-write ukbd_poll() (and possibly usb code) or should mutex_owned() be adjusted? That question III actually brings another thought: perhaps the whole of idea of skipping locks in a certain context is not a correct direction? Perhaps, instead we should identify all the code that could be legitimately executed in the after-panic and/or kdb contexts and make that could explicitly aware of its execution context. That is, instead of trying to make _lock, _unlock, _owned, _trylock, etc do the right thing auto-magically, we should try to make the calling code check panicstr and kdb_active and do the right thing on that level (which would include not invoking those lock-related operations or other inappropriate operations). Thank you very much in advance for your insights and help! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 12:38:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F102106566B; Tue, 23 Aug 2011 12:38:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2BF8FC19; Tue, 23 Aug 2011 12:38:34 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=T62/IVpqZ1mLJMkeHfndQHXgWa4ATHZu3+3wVrCy9JU= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=ni9ZY7ZFbhgA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=U5pupLfntSEKqH8ZPzoA:9 a=4Dju21vhlnFLU5Q-dnsA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 169339470; Tue, 23 Aug 2011 14:38:33 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 23 Aug 2011 14:36:04 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> In-Reply-To: <4E53986B.5000804@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108231436.04210.hselasky@c2i.net> Cc: Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 12:38:36 -0000 On Tuesday 23 August 2011 14:09:15 Andriy Gapon wrote: > Yes, the subject sounds quite hairy, so please let me try to explain it. > First, let's consider one concrete function: > > static int > ukbd_poll(keyboard_t *kbd, int on) > { > struct ukbd_softc *sc = kbd->kb_data; > > if (!mtx_owned(&Giant)) { > /* XXX cludge */ > int retval; > mtx_lock(&Giant); > retval = ukbd_poll(kbd, on); > mtx_unlock(&Giant); > return (retval); > } > > if (on) { > sc->sc_flags |= UKBD_FLAG_POLLING; > sc->sc_poll_thread = curthread; > } else { > sc->sc_flags &= ~UKBD_FLAG_POLLING; > ukbd_start_timer(sc); /* start timer */ > } > return (0); > } > > This "XXX cludge" [sic] pattern is scattered around a few functions in the > ukbd code and perhaps other usb code: > func() > { > if (!mtx_owned(&Giant)) { > mtx_lock(&Giant); > func(); > mtx_unlock(&Giant); > return; > } > > // etc ... > } > > I have a few question directly and indirectly related to this pattern. Hi Andriy, Thanks for bringing up this topic. > > I. [Why] do we need this pattern? > Can the code be re-written in a smarter (if not to say proper) way? Unless that API's surrounding ukbd change, we are stuck with auto-magic Giant locking inside ukbd. The USB stack itself does not require that Giant is used for the USB keyboard driver. It is some times since I touched this topic. From what I remember some interfacing layers of ukbd are using Giant. Some are not. Much of the existing non-USB keyboard code is written to get/put key-presses directly through legacy PCI/ISA registers. This approach is deferred in the USB stack, hence it would cause blocking delays of 1ms per polling operation. Another corner case: When you are scrolling the console having scroll lock locked, then the first printf on that console will directly call an IOCTL in the ukbd to switch off the scroll lock led. As you might be aware this can be dangerous. The ukbd is also sometimes printing stuff. The chance of deadlock and LOR is increasing. Without having to push for multiple changes outside ukbd, this problem is simply hidden in UKBD by checking if Giant is locked, which is required for starting the USB transfers in UKBD. I think it would be a very bad idea to lock another lock in a sub-function of printf. See! A multithread / taskqueue interface is needed for postponing keyboard events. And what about polling and UKBD? This needs a separate calling path I think. > > II. ukbd_poll() in particular can be called from the kdb context (kdb_trap > -> db_trap -> db_command_loop -> etc). What would happen if the Giant is > held by a thread on some other CPU (which would be hard-stopped by > kdp_trap)? Won't we get a lockup here? > So shouldn't this code actually check for kdb_active? > > III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite > chains of 'infinite' recursion because mtx_owned() always returns false. > This is because I skip all lock/unlock/etc operations in the post-panic > context. I think that it's a good philosophical question: what operations > like mtx_owned(), mtx_recursed(), mtx_trylock() 'should' return when we > actually act as if no locks exist at all? > > My first knee-jerk reaction was to change mtx_owned() to return true in > this "lock-less" context, but _hypothetically_ there could exist some > symmetric code that does something like: > func() > { > if (mtx_owned(&Giant)) { > mtx_unlock(&Giant); > func(); > mtx_lock(&Giant); > return; > } > > // etc ... > > What do you think about this problem? > Should we re-write ukbd_poll() (and possibly usb code) or should > mutex_owned() be adjusted? I think you've brought an interesing problem. I would suggest to change mtx_owned or make a new function to take an integer value to handle the case of SCHEDULER_STOPPED: mtx_owned_default(struct mtx *, int return value in case of SCHEDULER_STOPPED); > > That question III actually brings another thought: perhaps the whole of > idea of skipping locks in a certain context is not a correct direction? > Perhaps, instead we should identify all the code that could be legitimately > executed in the after-panic and/or kdb contexts and make that could > explicitly aware of its execution context. That is, instead of trying to > make _lock, _unlock, _owned, _trylock, etc do the right thing > auto-magically, we should try to make the calling code check panicstr and > kdb_active and do the right thing on that level (which would include not > invoking those lock-related operations or other inappropriate operations). > Thank you very much in advance for your insights and help! --HPS From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 13:19:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E32106566B for ; Tue, 23 Aug 2011 13:19:18 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from web01.lando.us (web01.lando.us [77.232.247.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8188FC08 for ; Tue, 23 Aug 2011 13:19:18 +0000 (UTC) Received: from R2D2 (bridge.aixit.com [82.149.224.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: uwe@grohnwaldt.eu) by web01.lando.us (Postfix) with ESMTPSA id 5A7B679F64 for ; Tue, 23 Aug 2011 15:19:17 +0200 (CEST) From: "Uwe Grohnwaldt" To: References: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> In-Reply-To: Date: Tue, 23 Aug 2011 15:19:21 +0200 Message-ID: <04a201cc6197$44fc6790$cef536b0$@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8/ALEYr63kQpPHfBEQNtjoABymAFGh91dlb8CNmA= Content-Language: de Cc: Subject: AW: Panic with 9.0 Beta 1 (arcmsr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 13:19:18 -0000 Ah, thanks for your fast reply. :) > -----Urspr=FCngliche Nachricht----- > Von: Sergey Kandaurov [mailto:pluknet@gmail.com] > Gesendet: Dienstag, 23. August 2011 13:18 > An: Uwe Grohnwaldt > Cc: current@freebsd.org > Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) >=20 > On 23 August 2011 14:57, Uwe Grohnwaldt wrote: > > Hi, > > > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped > > with a kernel panic: > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q > > buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > > > A screenshot from the panic can be found here: > > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png >=20 > HI, that should be fixed in head (and in forthcoming BETA2). > You can apply this patch from head to fix panic: > = http://svnweb.freebsd.org/base/head/sys/dev/arcmsr/arcmsr.c?view=3Dpatc > h&r1=3D224905&r2=3D224904&pathrev=3D224905 >=20 >=20 > -- > wbr, > pluknet From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 14:09:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6609106567B; Tue, 23 Aug 2011 14:09:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5D07A8FC0A; Tue, 23 Aug 2011 14:09:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAF20U06DaFvO/2dsb2JhbABBhEukSIFAAQEFIwQuJBsYAgINGQJZBi6wXJF+gSyEDIEQBJMZkRY X-IronPort-AV: E=Sophos;i="4.68,269,1312171200"; d="scan'208";a="135261448" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 23 Aug 2011 10:09:41 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 23DAAB3F2A; Tue, 23 Aug 2011 10:09:41 -0400 (EDT) Date: Tue, 23 Aug 2011 10:09:41 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <1965813445.219973.1314108581091.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110823113044.GB1662@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Hiroki Sato , current@FreeBSD.org, Benjamin Kaduk Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 14:09:45 -0000 Pawel Jakub Dawidek wrote: > On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote: > > Hiroki, could you please test the attached patch. > > > > One problem with this patch is that I don't know how to create a > > fixed > > table that matches what systems would already have been getting. > > (I got the first 6 entries by booting a GENERIC i386 kernel with a > > printf in vfs_init(), so I suspect those don't change much, > > although > > I'm not sure if ZFS will usually end up before or after them?) > > > > Do you guys know what ZFS gets assigned typically? (I realize that > > changes w.r.t. when it gets loaded, so the question also becomes > > "do you know how it typically gets loaded" so the table can have > > that vfc_typenum value assigned to it?) > > Maybe you could boot a system with a printf like: > > > > printf("%s, %d\n", vfc->vfc_name, vfc->vfc_typenum); > > > > just after vfc->vfc_typenum = maxvfsconf++; in vfs_init() and > > then look in dmesg after booting, to see what your tables look like? > > (Without the attached patch installed.) > > Rick, I'm sorry to arrive so late, but in my opinion hardcoding list > of > file systems in the kernel is a step in wrong direction, really. > We are trying to keep things modularized, so there are no such things > laying around that have to be cleaned up when file system goes away or > updated when new file system arrives. > > I remember for example fts code where I found that it keeps list of > file > systems that can be handled faster. ZFS could have been handled > faster, > but I found this after few years. > For this case there should be VFCF_* flag that fts shuld recognize and > not > hardcore file system names. > > This was also the reason that when I added support for "jail-friendly" > file systems and support for file systems with delegated > administration > I haven't created list of file system types that support it, but added > VFCF_JAIL and VFCF_DELEGADMIN flags. > > Here you cannot use those flags to solve the problem, but hardcoding > file system types in an array is really not the way to go. > > I much prefer Ben's idea of calculating a hash from file system name > and > detecting collisions. > Ok, I'll admit I wasn't very fond of a fixed table that would inevitably get out of date someday, either. I didn't think hashing for the cases not in the table was worth the effort, but doing a hash instead of a table seems reasonable. I see that ZFS only uses the low order 8 bits, so I'll try and come up with an 8bit hash solution and will post a patch for testing/review soon. I don't think the vfs_sysctl() is that great a concern, given that it appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum won't be that sparse.) I'll also make sure that whatever hash I use doesn't collide for the current list of file names (although I will include code that handles a collision in the patch). Thanks for the comments, rick > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 14:48:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D85C106566C for ; Tue, 23 Aug 2011 14:48:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD7C78FC13 for ; Tue, 23 Aug 2011 14:48:49 +0000 (UTC) Received: by qwc9 with SMTP id 9so159262qwc.13 for ; Tue, 23 Aug 2011 07:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gZPkjVK3Z8NshDeWWQcOfike4RZFox5Dpt+/H3gzBNM=; b=t3PzBAsVvlgfQ+rCwNQhclM84hrqFn00+EPhVqUe/DgOL2psLCvLMl4ubN8+V+NuGZ laF4aic6k/bOmtYenQnZqaESfOFNeg09V1PUPECaC/pK/IY2f2eOXLgzdzjGkWItUx4k 5Uz+bxYHb3ryCyuWgFP9fSJmUdaZO1kzRxxQc= MIME-Version: 1.0 Received: by 10.224.210.132 with SMTP id gk4mr2504011qab.79.1314110929043; Tue, 23 Aug 2011 07:48:49 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Tue, 23 Aug 2011 07:48:49 -0700 (PDT) In-Reply-To: <4FE605DD-17CC-4378-9418-50BEE438296E@alogis.com> References: <4FE605DD-17CC-4378-9418-50BEE438296E@alogis.com> Date: Tue, 23 Aug 2011 07:48:49 -0700 Message-ID: From: Garrett Cooper To: Holger Kipp Content-Type: text/plain; charset=ISO-8859-1 Cc: "current@freebsd.org" Subject: Re: LOR 9.0 beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 14:48:50 -0000 On Tue, Aug 23, 2011 at 4:29 AM, Holger Kipp wrote: > Maybe already seen... > This is within Parallels 6.0 VM on a Mac with OS 10.6.8 ... This is a well known LOR. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 15:10:59 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6837106564A; Tue, 23 Aug 2011 15:10:59 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7C78D8FC0A; Tue, 23 Aug 2011 15:10:59 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E4364AA2; Tue, 23 Aug 2011 17:10:57 +0200 (CEST) Date: Tue, 23 Aug 2011 17:10:41 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110823151041.GA1697@garage.freebsd.pl> References: <20110823113044.GB1662@garage.freebsd.pl> <1965813445.219973.1314108581091.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <1965813445.219973.1314108581091.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hiroki Sato , current@FreeBSD.org, Benjamin Kaduk Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 15:10:59 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > Ok, I'll admit I wasn't very fond of a fixed table that would inevitably > get out of date someday, either. >=20 > I didn't think hashing for the cases not in the table was worth the effor= t, > but doing a hash instead of a table seems reasonable. >=20 > I see that ZFS only uses the low order 8 bits, so I'll try and come up > with an 8bit hash solution and will post a patch for testing/review soon. >=20 > I don't think the vfs_sysctl() is that great a concern, given that it > appears to be deprecated already anyhow. (With an 8bit hash, vfs_typenum > won't be that sparse.) I'll also make sure that whatever hash I use > doesn't collide for the current list of file names (although I will inclu= de > code that handles a collision in the patch). Sounds great. Thanks! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk5TwvAACgkQForvXbEpPzSfFwCfWLYfd7U0G+7LtaEeZCLcwG0o u84AoIzRC53xtqSEeH9MK7MdAd5QsWbg =/73t -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 15:28:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 707C41065672 for ; Tue, 23 Aug 2011 15:28:30 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0DA8FC12 for ; Tue, 23 Aug 2011 15:28:29 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Qvstx-0007Oc-3o for freebsd-current@freebsd.org; Tue, 23 Aug 2011 08:28:29 -0700 Date: Tue, 23 Aug 2011 08:28:29 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1314113309105-4727173.post@n5.nabble.com> In-Reply-To: <1314043000260-4724430.post@n5.nabble.com> References: <1314030908626-4723962.post@n5.nabble.com> <201108222057.03575.hselasky@c2i.net> <1314043000260-4724430.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: kldload uhci, system grinds to halt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 15:28:30 -0000 After filling sticks with zeros, and writing data again on them, cannot replicate. Maybe usb sticks were to blame. One was brand new, possibly loaded with some "helpful" software, and other contained broken OpenBSD install. Thanks for attention. best regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/kldload-uhci-system-grinds-to-halt-tp4723962p4727173.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 18:42:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4029E1065673 for ; Tue, 23 Aug 2011 18:42:18 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 03C4E8FC14 for ; Tue, 23 Aug 2011 18:42:17 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 23 Aug 2011 14:12:34 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.2.3-GA) with ESMTP id BAS82946; Tue, 23 Aug 2011 14:12:34 -0400 X-Auth-ID: roberthuff Received: from 209-6-40-157.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO [209.6.40.157]) ([209.6.40.157]) by smtp04.lnh.mail.rcn.net with ESMTP; 23 Aug 2011 14:12:34 -0400 Message-ID: <4E53ED98.7010507@rcn.com> Date: Tue, 23 Aug 2011 14:12:40 -0400 From: Robert Huff User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr17.lnh.mail.rcn.net) Cc: Subject: login problem after update. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:42:18 -0000 This morning I updated an amd64 machine which had been running -CURRENT from April 18 to last night's version. The build/build/install/install process seemed to go as usual. However, when I tried to log in (any user) I get: login: tac_config: cannot open "/etc/tacplus.conf" Login: pam_authenticate(): error in services module and at a different point: su: in openpam_dispatch(): pam_unix.so: no pam_sm_acct_mgmt() I have checked, and there is no /etc/tacplus.conf; but there wasn't one in the full backup done MOnday either, at which point everything was working. The file is in the man pages, but with no mention of how it is created. What have I mangled, and how to I fix it? Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 18:57:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF1D106566B for ; Tue, 23 Aug 2011 18:57:31 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 937F78FC08 for ; Tue, 23 Aug 2011 18:57:31 +0000 (UTC) Received: by qyk9 with SMTP id 9so401218qyk.13 for ; Tue, 23 Aug 2011 11:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZpZ7bvgPY3OyWfrBDi8xvIzIo8q+f9Pl3kmEIeNm6co=; b=QnzO5o5G/lV2F4Sb206z0TgDAmqymgv6Jw1O6MveJijP1vfbzQkiHvUlg3kQCUSYAt HkfTcD2KSqC1HY2+jw/qfBs6jbHdR3FqcVi9O3LF1bSe5ZXup12fUJbICLXlMt4hSyfv yCX1bjSHz/ZUZYqGnhr0sGKnNsD0OG9D/1Gvs= MIME-Version: 1.0 Received: by 10.224.216.1 with SMTP id hg1mr210996qab.179.1314125850822; Tue, 23 Aug 2011 11:57:30 -0700 (PDT) Received: by 10.224.178.65 with HTTP; Tue, 23 Aug 2011 11:57:30 -0700 (PDT) In-Reply-To: <4E53ED98.7010507@rcn.com> References: <4E53ED98.7010507@rcn.com> Date: Tue, 23 Aug 2011 11:57:30 -0700 Message-ID: From: Garrett Cooper To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: login problem after update. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:57:32 -0000 On Tue, Aug 23, 2011 at 11:12 AM, Robert Huff wrote: > =A0 =A0 This morning I updated an amd64 machine which had been running -C= URRENT > from April 18 to last night's version. > =A0 =A0 =A0 =A0The build/build/install/install process seemed to go as us= ual. > However, when I tried to log in (any user) I get: > > login: tac_config: cannot open "/etc/tacplus.conf" > > Login: pam_authenticate(): error in services module > > =A0 =A0 =A0 =A0and at a different point: > > su: =A0in openpam_dispatch(): pam_unix.so: no pam_sm_acct_mgmt() > > =A0 =A0 =A0 =A0I have checked, and there is no /etc/tacplus.conf; but the= re wasn't > one in the full backup done MOnday either, at which point everything was > working. =A0The file is in the man pages, but with no mention of how it i= s > created. > > =A0 =A0 =A0 =A0What have I mangled, and how to I fix it? make -C /usr/src/lib/libpam/ all install Maybe? I can't find tacplus.conf anywhere on my system in /usr/src or /usr/obj , and it isn't installed in /etc either, so it seems optional at least (assuming that you don't use the tacacs login class in /etc/login.conf?). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 19:31:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71FCE1065677 for ; Tue, 23 Aug 2011 19:31:25 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1908FC1A for ; Tue, 23 Aug 2011 19:31:24 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 23 Aug 2011 15:31:24 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.2.3-GA) with ESMTP id BAS95819; Tue, 23 Aug 2011 15:31:22 -0400 X-Auth-ID: roberthuff Received: from 209-6-28-204.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO [192.168.1.101]) ([209.6.28.204]) by smtp04.lnh.mail.rcn.net with ESMTP; 23 Aug 2011 15:31:22 -0400 Message-ID: <4E540001.3080508@rcn.com> Date: Tue, 23 Aug 2011 15:31:13 -0400 From: Robert Huff User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Garrett Cooper References: <4E53ED98.7010507@rcn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr17.lnh.mail.rcn.net) Cc: current@freebsd.org Subject: Re: login problem after update. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:31:25 -0000 On 8/23/2011 2:57 PM, Garrett Cooper wrote: >> >> What have I mangled, and how to I fix it? > > make -C /usr/src/lib/libpam/ all install > > Maybe? That _seems_ to have fixed things. If so, I have to wonder why this didn't happen during the installworld. Oh well .... THanks, Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 18:50:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06C6F106566B for ; Tue, 23 Aug 2011 18:50:59 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f38.mail.ru (f38.mail.ru [217.69.129.99]) by mx1.freebsd.org (Postfix) with ESMTP id 764C98FC08 for ; Tue, 23 Aug 2011 18:50:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=40GJdtK5hO0hNRyUGGNFamTFp/T1LAmTWu6Rik023EU=; b=TH849kUUehaeRyTW6234Q98TjGq9e9zemFembYYX3PnO5fKl8ES0FpibY6L1FPss78Palz7S/1WY3ibVT/ZYSoBA4/mbArE4usVCTJT3ly5FhsvOh+tG7nU/gNMyH4S6; Received: from mail by f38.mail.ru with local id 1Qvw3o-0000kC-00; Tue, 23 Aug 2011 22:50:52 +0400 Received: from [2.95.12.25] by e.mail.ru with HTTP; Tue, 23 Aug 2011 22:50:52 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: =?UTF-8?B?IkxpLCBRaW5nIg==?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.17.1.151 via proxy [2.95.12.25] Date: Tue, 23 Aug 2011 22:50:52 +0400 References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Tue, 23 Aug 2011 19:36:46 +0000 Cc: =?UTF-8?B?ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3Jn?= Subject: Re[2]: Kernel panic "rtfree 2" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:50:59 -0000 CgoKMTcg0LDQstCz0YPRgdGC0LAgMjAxMSwgMDQ6MDIg0L7RgiAiTGksIFFpbmciIDxxaW5nLmxp QGJsdWVjb2F0LmNvbT46Cj4gSGksCj4gCj4gQ291bGQgeW91IHBsZWFzZSBsZXQgbWUga25vdyBp ZiB0aGUgcGF0Y2ggZml4ZXMgeW91ciBjcmFzaCBwcm9ibGVtID8KPiAKPiBUaGFua3MsCj4gCj4g LS1RaW5nCj4gCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTogTGksIFFp bmcKPiA+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDEyLCAyMDExIDY6MjkgUE0KPiA+IFRvOiBMaSwg UWluZzsgTHVpeiBPdGF2aW8gTyBTb3V6YTsgQW5kcmV5IFNtYWdpbgo+ID4gQ2M6IGZyZWVic2Qt Y3VycmVudEBmcmVlYnNkLm9yZwo+ID4gU3ViamVjdDogUkU6IEtlcm5lbCBwYW5pYyAicnRmcmVl IDIiCj4gPgo+ID4gSGksCj4gPgo+ID4gUGxlYXNlIHJlLWVuYWJsZSBSQURJWF9NUEFUSCBvcHRp b24gaW4geW91ciBrZXJuZWwgY29uZmlnIGZpbGUsIGFuZAo+ID4gdHJ5IHRoZSBmb2xsb3dpbmcg cGF0Y2g6Cj4gPgo+ID4gCWh0dHA6Ly9wZW9wbGUuZnJlZWJzZC5vcmcvfnFpbmdsaS9yYWRpeF9t cGF0aC5jLmRpZmYKPiA+Cj4gPiBhbmQgbGV0IG1lIGtub3cgaWYgaXQgd29ya3Mgb3V0IGZvciB5 b3UuCj4gPgo+ID4gSSBwZXJmb3JtZWQgdmVyeSBsaW1pdGVkIHRlc3RpbmcuCj4gPgo+ID4gVGhh bmtzLAo+ID4KPiA+IC0tUWluZwo+ID4KPiAKPiAKVGhhbmtzLCBZb3VyIHBhdGNoIHJlc29sdmUg cHJvYmxlbSwgSSBoYXZlIDMgZGF5IHVwdGltZSB3aXRob3V0IHBhbmljCgo= From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 20:11:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32DE4106566B; Tue, 23 Aug 2011 20:11:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A3F768FC15; Tue, 23 Aug 2011 20:11:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALcIVE6DaFvO/2dsb2JhbABCFoQ2pBCBQAEBBSMEUhsYAgINGQJZBi6HWqsykh6BLIQMgRAEkxmRFg X-IronPort-AV: E=Sophos;i="4.68,271,1312171200"; d="scan'208";a="135309785" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 23 Aug 2011 16:11:20 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 82FB1B3F28; Tue, 23 Aug 2011 16:11:20 -0400 (EDT) Date: Tue, 23 Aug 2011 16:11:20 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110823151041.GA1697@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Hiroki Sato , current@FreeBSD.org, Benjamin Kaduk Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:11:28 -0000 Pawel Jakub Dawidek wrote: > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > Ok, I'll admit I wasn't very fond of a fixed table that would > > inevitably > > get out of date someday, either. > > > > I didn't think hashing for the cases not in the table was worth the > > effort, > > but doing a hash instead of a table seems reasonable. > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come > > up > > with an 8bit hash solution and will post a patch for testing/review > > soon. > > > > I don't think the vfs_sysctl() is that great a concern, given that > > it > > appears to be deprecated already anyhow. (With an 8bit hash, > > vfs_typenum > > won't be that sparse.) I'll also make sure that whatever hash I use > > doesn't collide for the current list of file names (although I will > > include > > code that handles a collision in the patch). > > Sounds great. Thanks! > Here's the patch. (Hiroki could you please test this, thanks, rick.) ps: If the white space gets trashed, the same patch is at: http://people.freebsd.org/~rmacklem/fsid.patch --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 +++ kern/vfs_init.c 2011-08-23 15:55:30.000000000 -0400 @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in #include #include +#include #include #include #include @@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc) struct sysctl_oid *oidp; struct vfsops *vfsops; static int once; + struct vfsconf *tvfc; + uint32_t hashval; if (!once) { vattr_null(&va_null); @@ -152,7 +155,27 @@ vfs_register(struct vfsconf *vfc) if (vfs_byname(vfc->vfc_name) != NULL) return EEXIST; - vfc->vfc_typenum = maxvfsconf++; + /* + * Calculate a hash on vfc_name to use for vfc_typenum. Unless + * a collision occurs, it is limited to 8bits since that is + * what ZFS uses from vfc_typenum and that also limits how sparsely + * distributed vfc_typenum becomes. + */ + hashval = hash32_str(vfc->vfc_name, 0); + hashval = ((hashval & 0xff) + ((hashval >> 8) & 0xff) + + ((hashval >> 16) & 0xff) + (hashval >> 24)) & 0xff; + do { + /* Look for and fix any collision. */ + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { + if (hashval == tvfc->vfc_typenum) { + hashval++; /* Can exceed 8bits, if needed. */ + break; + } + } + } while (tvfc != NULL); + vfc->vfc_typenum = hashval; + if (vfc->vfc_typenum >= maxvfsconf) + maxvfsconf = vfc->vfc_typenum + 1; TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); /* From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 21:23:23 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2162F106564A; Tue, 23 Aug 2011 21:23:23 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id CAB9E8FC12; Tue, 23 Aug 2011 21:23:22 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id B64AABDF; Tue, 23 Aug 2011 23:23:20 +0200 (CEST) Date: Tue, 23 Aug 2011 23:23:03 +0200 From: Pawel Jakub Dawidek To: Rick Macklem Message-ID: <20110823212301.GE1697@garage.freebsd.pl> References: <20110823151041.GA1697@garage.freebsd.pl> <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OZkY3AIuv2LYvjdk" Content-Disposition: inline In-Reply-To: <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hiroki Sato , current@FreeBSD.org, Benjamin Kaduk Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:23:23 -0000 --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > Pawel Jakub Dawidek wrote: > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > > Ok, I'll admit I wasn't very fond of a fixed table that would > > > inevitably > > > get out of date someday, either. > > > > > > I didn't think hashing for the cases not in the table was worth the > > > effort, > > > but doing a hash instead of a table seems reasonable. > > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come > > > up > > > with an 8bit hash solution and will post a patch for testing/review > > > soon. > > > > > > I don't think the vfs_sysctl() is that great a concern, given that > > > it > > > appears to be deprecated already anyhow. (With an 8bit hash, > > > vfs_typenum > > > won't be that sparse.) I'll also make sure that whatever hash I use > > > doesn't collide for the current list of file names (although I will > > > include > > > code that handles a collision in the patch). > >=20 > > Sounds great. Thanks! > >=20 > Here's the patch. (Hiroki could you please test this, thanks, rick.) > ps: If the white space gets trashed, the same patch is at: > http://people.freebsd.org/~rmacklem/fsid.patch The patch is fine by me. Thanks, Rick! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --OZkY3AIuv2LYvjdk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk5UGjUACgkQForvXbEpPzT0IACg4xRtqasZSLUzwefpWztWkkAc xtUAniO6KmXQCSIAUmBPksSKEj4hQDfc =MM+u -----END PGP SIGNATURE----- --OZkY3AIuv2LYvjdk-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 07:08:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33D551065677; Wed, 24 Aug 2011 07:08:21 +0000 (UTC) (envelope-from beech@freebsd.org) Received: from bsdevel2.freebsdnorth.com (unknown [IPv6:2001:470:7:d77::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC208FC20; Wed, 24 Aug 2011 07:08:21 +0000 (UTC) Received: from pinnacle.akherb.com (akbeech-1-pt.tunnel.tserv14.sea1.ipv6.he.net [IPv6:2001:470:a:333::2]) by bsdevel2.freebsdnorth.com (Postfix) with ESMTPA id 0F2BDC3AF2; Tue, 23 Aug 2011 07:06:40 +0000 (UTC) From: Beech Rintoul Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 23 Aug 2011 23:08:17 -0800 User-Agent: KMail/1.13.7 (FreeBSD/9.0-BETA1; KDE/4.6.5; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201108232308.18099.beech@freebsd.org> Cc: Beech Rintoul Subject: Failure with 9.0 Beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 07:08:21 -0000 Trying to build today's current I get the following: cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" - DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 - DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 - DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' - DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at - I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector - Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer- sign -o atrun atrun.o gloadavg.o -lpam -lutil /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' *** Error code 1 uname -a FreeBSD pinnacle.akherb.com 9.0-BETA1 FreeBSD 9.0-BETA1 #3: Fri Aug 12 22:55:05 AKDT 2011 root@pinnacle.akherb.com:/usr/obj/usr/src/sys/PINNACLE i386 I'm not building with clang and the only references I get from google don't seem to have any answers. Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --------------------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 07:43:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 126F2106566B for ; Wed, 24 Aug 2011 07:43:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E8A08FC1A for ; Wed, 24 Aug 2011 07:43:16 +0000 (UTC) Received: by wyh15 with SMTP id 15so821485wyh.13 for ; Wed, 24 Aug 2011 00:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lrEckPxbhXYhqSSfHNtSC8fdEnJLJzFB+76/qXsFBms=; b=cS+3D2XR1XyXEMXjp7bIVr3Ru0pVf6Q6a0vyX3LcknbeTVfHakuFnkipVz/myQEh6F DC+X15IVgfZF1GCgBfM0EiVMn6U7ffwL1QuErpAXWbwkjf+F0+YIwVQv2hXFGshEo4zg ZrJozlYgrUi4oX5uVOHkZIcPN8/X9l07JkOx8= MIME-Version: 1.0 Received: by 10.216.54.130 with SMTP id i2mr3469383wec.10.1314171795031; Wed, 24 Aug 2011 00:43:15 -0700 (PDT) Received: by 10.216.48.129 with HTTP; Wed, 24 Aug 2011 00:43:14 -0700 (PDT) In-Reply-To: <201108232308.18099.beech@freebsd.org> References: <201108232308.18099.beech@freebsd.org> Date: Wed, 24 Aug 2011 00:43:14 -0700 Message-ID: From: Garrett Cooper To: Beech Rintoul Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Failure with 9.0 Beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 07:43:17 -0000 On Wed, Aug 24, 2011 at 12:08 AM, Beech Rintoul wrote: > Trying to build today's current I get the following: Please update to HEAD and read UPDATING @ 20110815. There are several references in the archives last week and the week before to this build failure. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 08:06:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA72106566B for ; Wed, 24 Aug 2011 08:06:13 +0000 (UTC) (envelope-from beech@freebsd.org) Received: from bsdevel2.freebsdnorth.com (unknown [IPv6:2001:470:7:d77::2]) by mx1.freebsd.org (Postfix) with ESMTP id 237F28FC13 for ; Wed, 24 Aug 2011 08:06:13 +0000 (UTC) Received: from pinnacle.akherb.com (akbeech-1-pt.tunnel.tserv14.sea1.ipv6.he.net [IPv6:2001:470:a:333::2]) by bsdevel2.freebsdnorth.com (Postfix) with ESMTPA id 6BAE2C3AFC; Tue, 23 Aug 2011 08:04:31 +0000 (UTC) From: Beech Rintoul Organization: FreeBSD To: freebsd-current@freebsd.org Date: Wed, 24 Aug 2011 00:06:10 -0800 User-Agent: KMail/1.13.7 (FreeBSD/9.0-BETA1; KDE/4.6.5; i386; ; ) References: <201108232308.18099.beech@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108240006.10915.beech@freebsd.org> Cc: Garrett Cooper Subject: Re: Failure with 9.0 Beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 08:06:13 -0000 On Tuesday 23 August 2011 23:43:14 Garrett Cooper wrote: > On Wed, Aug 24, 2011 at 12:08 AM, Beech Rintoul wrote: > > Trying to build today's current I get the following: > Please update to HEAD and read UPDATING @ 20110815. There are > several references in the archives last week and the week before to > this build failure. > Cheers, > -Garrett Thanks, I missed the second part of that post. Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --------------------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 08:07:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0DA81065676 for ; Wed, 24 Aug 2011 08:07:25 +0000 (UTC) (envelope-from beech@freebsd.org) Received: from bsdevel2.freebsdnorth.com (unknown [IPv6:2001:470:7:d77::2]) by mx1.freebsd.org (Postfix) with ESMTP id 953CB8FC0C for ; Wed, 24 Aug 2011 08:07:25 +0000 (UTC) Received: from pinnacle.akherb.com (akbeech-1-pt.tunnel.tserv14.sea1.ipv6.he.net [IPv6:2001:470:a:333::2]) by bsdevel2.freebsdnorth.com (Postfix) with ESMTPA id DBCD5C3AFC; Tue, 23 Aug 2011 08:05:43 +0000 (UTC) From: Beech Rintoul Organization: FreeBSD To: "Conrad J. Sabatier" Date: Wed, 24 Aug 2011 00:07:23 -0800 User-Agent: KMail/1.13.7 (FreeBSD/9.0-BETA1; KDE/4.6.5; i386; ; ) References: <201108232308.18099.beech@freebsd.org> <20110824022430.6ceb4fcc@cox.net> In-Reply-To: <20110824022430.6ceb4fcc@cox.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108240007.23430.beech@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Failure with 9.0 Beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 08:07:25 -0000 On Tuesday 23 August 2011 23:24:30 Conrad J. Sabatier wrote: > On Tue, 23 Aug 2011 23:08:17 -0800 > > Beech Rintoul wrote: > > Trying to build today's current I get the following: > > > > cc -O2 -pipe -DATJOB_DIR=\"/var/at/jobs/\" - > > DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 - > > DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 - > > DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' - > > DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at - > > I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 > > -fstack-protector - Wsystem-headers -Werror -Wall -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer- sign -o atrun atrun.o gloadavg.o > > -lpam -lutil /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined > > reference to `_nsyylex' /usr/obj/usr/src/tmp/usr/lib/libc.so: > > undefined reference to > > `_nsyyin' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference > > to `_nsyytext' /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined > > reference to `_nsyyerror' /usr/obj/usr/src/tmp/usr/lib/libc.so: > > undefined reference to `_nsyylineno' *** Error code 1 > > > > uname -a > > FreeBSD pinnacle.akherb.com 9.0-BETA1 FreeBSD 9.0-BETA1 #3: Fri Aug > > 12 22:55:05 AKDT 2011 > > root@pinnacle.akherb.com:/usr/obj/usr/src/sys/PINNACLE i386 > > > > I'm not building with clang and the only references I get from google > > don't seem to have any answers. > > > > Beech > > There was a thread on this problem just a few weeks ago. Without going > into all of the technical explanations for what's happening, the short > answer is: build and install a new kernel (should work), reboot, *then* > do a buildworld. > > I can't recall the thread Subject: offhand, but it worked for me and > others, so it's "safe". If I think of the actual reference to point > you to, I'll let you know. > > Happy building. :-) Thanks, that's also what UPDATING implies. Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/8.2R/announce.html --------------------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 08:21:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19325106564A; Wed, 24 Aug 2011 08:21:24 +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 8DAE68FC12; Wed, 24 Aug 2011 08:21:23 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7O8LJLR030301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 11:21:19 +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.4/8.14.4) with ESMTP id p7O8LJU7054860; Wed, 24 Aug 2011 11:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7O8LJp4054859; Wed, 24 Aug 2011 11:21:19 +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: Wed, 24 Aug 2011 11:21:19 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> References: <20110823151041.GA1697@garage.freebsd.pl> <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> <20110823212301.GE1697@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sm8tznmXhqMF9oN0" Content-Disposition: inline In-Reply-To: <20110823212301.GE1697@garage.freebsd.pl> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Benjamin Kaduk , Rick Macklem , current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 08:21:24 -0000 --Sm8tznmXhqMF9oN0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > Pawel Jakub Dawidek wrote: > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > > > > inevitably > > > > get out of date someday, either. > > > > > > > > I didn't think hashing for the cases not in the table was worth the > > > > effort, > > > > but doing a hash instead of a table seems reasonable. > > > > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come > > > > up > > > > with an 8bit hash solution and will post a patch for testing/review > > > > soon. > > > > > > > > I don't think the vfs_sysctl() is that great a concern, given that > > > > it > > > > appears to be deprecated already anyhow. (With an 8bit hash, > > > > vfs_typenum > > > > won't be that sparse.) I'll also make sure that whatever hash I use > > > > doesn't collide for the current list of file names (although I will > > > > include > > > > code that handles a collision in the patch). > > >=20 > > > Sounds great. Thanks! > > >=20 > > Here's the patch. (Hiroki could you please test this, thanks, rick.) > > ps: If the white space gets trashed, the same patch is at: > > http://people.freebsd.org/~rmacklem/fsid.patch >=20 > The patch is fine by me. Thanks, Rick! Sorry, I am late. It seems that the probability of the collisions for the hash is quite high. Due to the fixup procedure, the resulting typenum will depend on the order of the module initialization, isn't it ? IMO, it makes the patch goal not met. --Sm8tznmXhqMF9oN0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5UtH4ACgkQC3+MBN1Mb4hWpwCghA4kC9ojHrWXH5hlBZyYbdk+ DncAni6QrkO3EihSbIoDaT1aFjt4Gmqt =Fh7T -----END PGP SIGNATURE----- --Sm8tznmXhqMF9oN0-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 12:38:57 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F0AB106566C; Wed, 24 Aug 2011 12:38:57 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9768FC12; Wed, 24 Aug 2011 12:38:54 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OCcdoj088226; Wed, 24 Aug 2011 21:38:49 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OCca6W043432; Wed, 24 Aug 2011 21:38:38 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 24 Aug 2011 21:34:58 +0900 (JST) Message-Id: <20110824.213458.806017948592590395.hrs@allbsd.org> To: rmacklem@uoguelph.ca, kostikbel@gmail.com From: Hiroki Sato In-Reply-To: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> References: <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> <20110823212301.GE1697@garage.freebsd.pl> <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Wed_Aug_24_21_34_58_2011_531)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 24 Aug 2011 21:38:51 +0900 (JST) X-Spam-Status: No, score=-104.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: pjd@FreeBSD.org, current@FreeBSD.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:38:57 -0000 ----Security_Multipart0(Wed_Aug_24_21_34_58_2011_531)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Aug_24_21_34_58_2011_131)--" Content-Transfer-Encoding: 7bit ----Next_Part(Wed_Aug_24_21_34_58_2011_131)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kostik Belousov wrote in <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>: ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: ko> > > Pawel Jakub Dawidek wrote: ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that would ko> > > > > inevitably ko> > > > > get out of date someday, either. ko> > > > > ko> > > > > I didn't think hashing for the cases not in the table was worth the ko> > > > > effort, ko> > > > > but doing a hash instead of a table seems reasonable. ko> > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll try and come ko> > > > > up ko> > > > > with an 8bit hash solution and will post a patch for testing/review ko> > > > > soon. ko> > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, given that ko> > > > > it ko> > > > > appears to be deprecated already anyhow. (With an 8bit hash, ko> > > > > vfs_typenum ko> > > > > won't be that sparse.) I'll also make sure that whatever hash I use ko> > > > > doesn't collide for the current list of file names (although I will ko> > > > > include ko> > > > > code that handles a collision in the patch). ko> > > > ko> > > > Sounds great. Thanks! ko> > > > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) ko> > > ps: If the white space gets trashed, the same patch is at: ko> > > http://people.freebsd.org/~rmacklem/fsid.patch ko> > ko> > The patch is fine by me. Thanks, Rick! ko> ko> Sorry, I am late. ko> ko> It seems that the probability of the collisions for the hash is quite high. ko> Due to the fixup procedure, the resulting typenum will depend on the order ko> of the module initialization, isn't it ? IMO, it makes the patch goal not ko> met. I tried the following two experiments (the complete results are attached) to confirm the probability: 1. [fsidhash1.txt] well-known vfc_name and the names "[a-z]fs" (# of names is 36) with no fix-up recalculation. 2. [fsidhash2.txt] well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) with no fix-up recalculation. There is no collision in the case 1. And when [a-z][a-z]fs are included the average number of the collided names in the same hash value is 4.43 (i.e. 160 different hash values are generated, the theoretical best number is (710 entries / 256 buckets) = 2.77). At least, vfc_names we currently have in our kernel code have no collision, fortunately. As you noticed "[a-z][a-z]fs" is an impractical data set and these results cannot explain the characteristics for all possible and practical vfc_names, so whether this hash is reasonable or not depends on how we think of them. Comments or other better idea? -- Hiroki ----Next_Part(Wed_Aug_24_21_34_58_2011_131)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsidhash1.txt" 0x09 = tfs 0x0b = tmpfs 0x0f = ifs 0x1f = xfs 0x24 = mfs 0x2a = bfs 0x39 = qfs 0x3b = msdosfs 0x3f = ffs 0x45 = ntfs 0x4e = ufs 0x54 = jfs 0x64 = yfs 0x69 = nfs 0x6f = cfs 0x7e = rfs 0x81 = devfs 0x84 = gfs 0x87 = ext2fs 0x89 = procfs 0x94 = vfs 0x99 = kfs 0x9c = hpfs 0xa1 = cd9660 0xa9 = zfs 0xae = ofs 0xb4 = dfs 0xc3 = sfs 0xca = hfs 0xcb = reiserfs 0xd9 = wfs 0xdf = lfs 0xe5 = afs 0xf4 = pfs 0xfa = efs 0xfe = udf ----Next_Part(Wed_Aug_24_21_34_58_2011_131)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsidhash2.txt" 0x00 = awfs, difs, infs, nsfs, qefs, sxfs, vjfs 0x02 = owfs 0x03 = emfs, jrfs, mdfs, rifs, wnfs 0x05 = fqfs, smfs 0x06 = alfs, icfs, kvfs, nhfs, xrfs 0x08 = jgfs, wcfs 0x09 = bpfs, ebfs, gufs, lzfs, olfs, tfs, tqfs, yvfs 0x0b = aafs, tmpfs, zzfs 0x0c = ctfs, fffs, hyfs, kkfs, ppfs, sbfs, uufs, xgfs 0x0e = dxfs, qtfs 0x0f = befs, gjfs, ifs, lofs, oafs, tffs, vyfs, ykfs 0x11 = hnfs, ujfs 0x12 = cifs, msfs, pefs, rxfs, zofs 0x14 = ldfs 0x15 = dmfs, irfs, nwfs, qifs, vnfs 0x18 = eqfs, hcfs, jvfs, mhfs, rmfs, wrfs, zdfs 0x1a = fufs, sqfs 0x1b = apfs, dbfs, igfs, kzfs, nlfs, vcfs, xvfs 0x1d = jkfs 0x1e = btfs, effs, gyfs, opfs, rbfs, tufs, wgfs, yzfs 0x1f = xfs 0x20 = aefs, nafs 0x21 = cxfs, fjfs, kofs, ptfs, sffs, uyfs, xkfs 0x24 = bifs, gnfs, lsfs, mfs, oefs, qxfs, tjfs, yofs 0x26 = hrfs 0x27 = cmfs, kdfs, mwfs, pifs, unfs, zsfs 0x2a = bfs, dqfs, gcfs, ivfs, lhfs, qmfs, vrfs, ydfs 0x2c = cbfs 0x2d = eufs, hgfs, jzfs, mlfs, rqfs, ucfs, wvfs, zhfs 0x2f = fyfs 0x30 = atfs, dffs, ikfs, npfs, qbfs, sufs, vgfs, xzfs 0x33 = bxfs, ejfs, jofs, mafs, otfs, rffs, tyfs, wkfs 0x36 = aifs, fnfs, ksfs, nefs, pxfs, sjfs, xofs 0x39 = bmfs, grfs, jdfs, lwfs, oifs, qfs, tnfs, ysfs 0x3b = msdosfs 0x3c = cqfs, fcfs, hvfs, khfs, pmfs, urfs, xdfs, zwfs 0x3f = bbfs, dufs, ffs, ggfs, izfs, llfs, qqfs, tcfs, vvfs, yhfs 0x42 = eyfs, hkfs, mpfs, pbfs, rufs, ugfs, wzfs, zlfs 0x43 = cffs 0x45 = axfs, djfs, iofs, lafs, ntfs, qffs, syfs, vkfs 0x48 = enfs, jsfs, mefs, oxfs, rjfs, wofs, zafs 0x4b = frfs, idfs, kwfs, nifs, snfs, xsfs 0x4c = amfs 0x4e = bqfs, gvfs, jhfs, omfs, trfs, ufs, wdfs, ywfs 0x4f = ecfs 0x51 = abfs, cufs, fgfs, hzfs, klfs, pqfs, scfs, uvfs, xhfs 0x54 = bffs, dyfs, gkfs, jfs, lpfs, obfs, qufs, tgfs, vzfs, ylfs 0x57 = hofs, kafs, mtfs, pffs, ryfs, ukfs, zpfs 0x58 = cjfs 0x5a = dnfs, isfs, lefs, nxfs, qjfs, vofs 0x5b = yafs 0x5d = erfs, hdfs, jwfs, mifs, rnfs, wsfs, zefs 0x60 = dcfs, fvfs, ihfs, nmfs, vdfs, xwfs 0x61 = aqfs, srfs 0x63 = bufs, gzfs, jlfs, oqfs, rcfs, tvfs 0x64 = egfs, whfs, yfs 0x66 = affs, cyfs, fkfs, kpfs, pufs, sgfs, uzfs, xlfs 0x67 = nbfs 0x69 = bjfs, gofs, jafs, ltfs, nfs, offs, tkfs, ypfs 0x6a = qyfs 0x6c = hsfs, kefs, mxfs, pjfs, xafs, ztfs 0x6d = cnfs, uofs 0x6f = cfs, drfs, iwfs, qnfs, vsfs 0x70 = gdfs, lifs, yefs 0x72 = ccfs, evfs, hhfs, mmfs, rrfs, udfs, wwfs, zifs 0x75 = dgfs, ilfs, nqfs, qcfs, vhfs 0x76 = aufs, fzfs, svfs 0x78 = byfs, mbfs, oufs, rgfs, tzfs 0x79 = ekfs, jpfs, wlfs 0x7b = fofs, ktfs, pyfs, skfs, xpfs 0x7c = ajfs, iafs, nffs 0x7e = bnfs, gsfs, jefs, lxfs, ojfs, rfs, tofs, wafs, ytfs 0x81 = devfs, fdfs, kifs, pnfs, xefs, zxfs 0x82 = crfs, hwfs, usfs 0x84 = bcfs, dvfs, gfs, qrfs, tdfs, vwfs 0x85 = ghfs, lmfs, yifs 0x87 = ext2fs, ezfs, hlfs, mqfs, rvfs, uhfs, zmfs 0x88 = cgfs, pcfs 0x89 = procfs 0x8a = dkfs, ipfs, lbfs, nufs, qgfs, vlfs 0x8b = ayfs, szfs 0x8d = hafs, mffs, oyfs, rkfs, zbfs 0x8e = eofs, jtfs, wpfs 0x90 = fsfs, kxfs, sofs, vafs, xtfs 0x91 = anfs, iefs, njfs 0x93 = brfs, gwfs, jifs, onfs, tsfs, wefs, yxfs 0x94 = edfs, vfs 0x96 = acfs, fhfs, kmfs, prfs, sdfs, xifs 0x97 = cvfs, uwfs 0x99 = bgfs, dzfs, kfs, ocfs, qvfs, thfs 0x9a = glfs, lqfs, ymfs 0x9c = hpfs, mufs, rzfs, zqfs 0x9d = ckfs, kbfs, pgfs, ulfs 0x9f = dofs, itfs, lffs, qkfs, vpfs 0xa0 = gafs, nyfs, ybfs 0xa1 = cd9660 0xa2 = hefs, mjfs, rofs, uafs, zffs 0xa3 = esfs, jxfs, wtfs 0xa5 = ddfs, fwfs, vefs, xxfs 0xa6 = arfs, iifs, nnfs, ssfs 0xa8 = bvfs, jmfs, orfs, twfs 0xa9 = ehfs, rdfs, wifs, zfs 0xab = agfs, flfs, kqfs, pvfs, shfs, xmfs 0xac = czfs, ncfs 0xae = bkfs, jbfs, ofs, ogfs, tlfs 0xaf = gpfs, lufs, qzfs, yqfs 0xb1 = fafs, myfs, xbfs, zufs 0xb2 = cofs, htfs, kffs, pkfs, upfs 0xb4 = dfs, dsfs, ixfs, qofs, vtfs 0xb5 = gefs, ljfs, tafs, yffs 0xb7 = hifs, mnfs, rsfs, uefs, zjfs 0xb8 = cdfs, ewfs, wxfs 0xba = dhfs, qdfs, vifs 0xbb = avfs, imfs, nrfs, swfs 0xbd = bzfs, ovfs 0xbe = elfs, jqfs, mcfs, rhfs, wmfs 0xc0 = fpfs, kufs, slfs, xqfs 0xc1 = akfs, ibfs, ngfs, pzfs 0xc3 = bofs, jffs, okfs, sfs, tpfs, wbfs 0xc4 = eafs, gtfs, lyfs, yufs 0xc6 = fefs, safs, xffs, zyfs 0xc7 = csfs, hxfs, kjfs, pofs, utfs 0xc9 = dwfs, qsfs, vxfs 0xca = bdfs, gifs, hfs, lnfs, tefs, yjfs 0xcb = reiserfs 0xcc = hmfs, mrfs, uifs, znfs 0xcd = chfs, pdfs, rwfs 0xcf = dlfs, lcfs, qhfs, vmfs 0xd0 = azfs, iqfs, nvfs 0xd2 = hbfs, ozfs, zcfs 0xd3 = epfs, jufs, mgfs, rlfs, wqfs 0xd5 = ftfs, kyfs, spfs, xufs 0xd6 = aofs, dafs, iffs, nkfs, vbfs 0xd8 = bsfs, jjfs, oofs 0xd9 = eefs, gxfs, rafs, ttfs, wffs, wfs, yyfs 0xdb = adfs, fifs, sefs, xjfs 0xdc = cwfs, knfs, psfs, uxfs 0xde = qwfs 0xdf = bhfs, gmfs, lfs, lrfs, odfs, tifs, ynfs 0xe1 = hqfs, mvfs, zrfs 0xe2 = clfs, kcfs, phfs, umfs 0xe4 = dpfs, lgfs, qlfs 0xe5 = afs, gbfs, iufs, nzfs, vqfs, ycfs 0xe7 = cafs, hffs, ubfs, zgfs 0xe8 = etfs, jyfs, mkfs, rpfs, wufs 0xea = fxfs, xyfs 0xeb = asfs, defs, ijfs, nofs, qafs, stfs, vffs 0xed = bwfs, osfs 0xee = eifs, jnfs, refs, txfs, wjfs 0xf0 = ahfs, fmfs, sifs, xnfs 0xf1 = krfs, ndfs, pwfs 0xf3 = jcfs 0xf4 = blfs, gqfs, lvfs, ohfs, pfs, tmfs, yrfs 0xf6 = mzfs, zvfs 0xf7 = cpfs, fbfs, hufs, kgfs, plfs, uqfs, xcfs 0xf9 = dtfs, qpfs 0xfa = bafs, efs, gffs, iyfs, lkfs, tbfs, vufs, ygfs 0xfc = hjfs, uffs, zkfs 0xfd = cefs, exfs, mofs, pafs, rtfs, wyfs 0xfe = udf ----Next_Part(Wed_Aug_24_21_34_58_2011_131)---- ----Security_Multipart0(Wed_Aug_24_21_34_58_2011_531)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5U7/IACgkQTyzT2CeTzy0s4QCePPIXokGTGVFpCmKgyOPhbE4e MMgAnAuEuSkcqwbyRP6bic7UPwsMf9dT =lXeM -----END PGP SIGNATURE----- ----Security_Multipart0(Wed_Aug_24_21_34_58_2011_531)---- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 12:57:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCE9510656DB; Wed, 24 Aug 2011 12:57:19 +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 67A068FC19; Wed, 24 Aug 2011 12:57:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7OCvFZZ048298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 15:57:15 +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.4/8.14.4) with ESMTP id p7OCvFu7065022; Wed, 24 Aug 2011 15:57:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7OCvFBK065021; Wed, 24 Aug 2011 15:57:15 +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: Wed, 24 Aug 2011 15:57:15 +0300 From: Kostik Belousov To: Hiroki Sato Message-ID: <20110824125715.GN17489@deviant.kiev.zoral.com.ua> References: <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> <20110823212301.GE1697@garage.freebsd.pl> <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <20110824.213458.806017948592590395.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cgvqJugwi0EWj/n7" Content-Disposition: inline In-Reply-To: <20110824.213458.806017948592590395.hrs@allbsd.org> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: kostikbel@gmail.com, rmacklem@uoguelph.ca, pjd@freebsd.org, current@freebsd.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:57:19 -0000 --cgvqJugwi0EWj/n7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote: > Kostik Belousov wrote > in <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>: >=20 > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > ko> > > Pawel Jakub Dawidek wrote: > ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > ko> > > > > inevitably > ko> > > > > get out of date someday, either. > ko> > > > > > ko> > > > > I didn't think hashing for the cases not in the table was wor= th the > ko> > > > > effort, > ko> > > > > but doing a hash instead of a table seems reasonable. > ko> > > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll try an= d come > ko> > > > > up > ko> > > > > with an 8bit hash solution and will post a patch for testing/= review > ko> > > > > soon. > ko> > > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, given= that > ko> > > > > it > ko> > > > > appears to be deprecated already anyhow. (With an 8bit hash, > ko> > > > > vfs_typenum > ko> > > > > won't be that sparse.) I'll also make sure that whatever hash= I use > ko> > > > > doesn't collide for the current list of file names (although = I will > ko> > > > > include > ko> > > > > code that handles a collision in the patch). > ko> > > > > ko> > > > Sounds great. Thanks! > ko> > > > > ko> > > Here's the patch. (Hiroki could you please test this, thanks, ric= k.) > ko> > > ps: If the white space gets trashed, the same patch is at: > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch > ko> > > ko> > The patch is fine by me. Thanks, Rick! > ko> > ko> Sorry, I am late. > ko> > ko> It seems that the probability of the collisions for the hash is quite= high. > ko> Due to the fixup procedure, the resulting typenum will depend on the = order > ko> of the module initialization, isn't it ? IMO, it makes the patch goal= not > ko> met. >=20 > I tried the following two experiments (the complete results are > attached) to confirm the probability: >=20 > 1. [fsidhash1.txt] > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > with no fix-up recalculation. >=20 > 2. [fsidhash2.txt] > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) > with no fix-up recalculation. >=20 > There is no collision in the case 1. And when [a-z][a-z]fs are > included the average number of the collided names in the same hash > value is 4.43 (i.e. 160 different hash values are generated, the > theoretical best number is (710 entries / 256 buckets) =3D 2.77). >=20 > At least, vfc_names we currently have in our kernel code have no > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > impractical data set and these results cannot explain the > characteristics for all possible and practical vfc_names, so whether > this hash is reasonable or not depends on how we think of them. > Comments or other better idea? Might be, add a new byte field to struct vfsconf, containing the suggested= =20 byte to be used by fsid. Divide the namespace into two half by the highest bit 7. Use the byte values with the highest bit clear for statically assignment for in-tree modules. Kernel will still check for the uniquiness on initialization. Reserve the value '0' to mean that kernel must assign the next unused value >=3D 128. This is done to support out-of-tree modules. Might be, also reserve the value 0 to mean 'kernel Main drawback is that is sounds complicated. --cgvqJugwi0EWj/n7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5U9SsACgkQC3+MBN1Mb4ikBACgkHDdtJysuFjPe8eO1bl8ef+c IG0An1LPRgk1iHPhTqjV1PXahAhErB4d =CpRt -----END PGP SIGNATURE----- --cgvqJugwi0EWj/n7-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 13:24:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DFC81065674; Wed, 24 Aug 2011 13:24:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 22A758FC13; Wed, 24 Aug 2011 13:24:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEX7VE6DaFvO/2dsb2JhbABCFoQ2pCKBQAEBBSNWGxgCAg0ZAlkGLodaqVuSAoEshA2BEASTGZEX X-IronPort-AV: E=Sophos;i="4.68,275,1312171200"; d="scan'208";a="135383348" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 24 Aug 2011 09:24:54 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C298BB3F5D; Wed, 24 Aug 2011 09:24:54 -0400 (EDT) Date: Wed, 24 Aug 2011 09:24:54 -0400 (EDT) From: Rick Macklem To: Kostik Belousov Message-ID: <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Pawel Jakub Dawidek , Benjamin Kaduk , current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:24:56 -0000 Kostik Belousov wrote: > On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > > Pawel Jakub Dawidek wrote: > > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: > > > > > Ok, I'll admit I wasn't very fond of a fixed table that would > > > > > inevitably > > > > > get out of date someday, either. > > > > > > > > > > I didn't think hashing for the cases not in the table was > > > > > worth the > > > > > effort, > > > > > but doing a hash instead of a table seems reasonable. > > > > > > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and > > > > > come > > > > > up > > > > > with an 8bit hash solution and will post a patch for > > > > > testing/review > > > > > soon. > > > > > > > > > > I don't think the vfs_sysctl() is that great a concern, given > > > > > that > > > > > it > > > > > appears to be deprecated already anyhow. (With an 8bit hash, > > > > > vfs_typenum > > > > > won't be that sparse.) I'll also make sure that whatever hash > > > > > I use > > > > > doesn't collide for the current list of file names (although I > > > > > will > > > > > include > > > > > code that handles a collision in the patch). > > > > > > > > Sounds great. Thanks! > > > > > > > Here's the patch. (Hiroki could you please test this, thanks, > > > rick.) > > > ps: If the white space gets trashed, the same patch is at: > > > http://people.freebsd.org/~rmacklem/fsid.patch > > > > The patch is fine by me. Thanks, Rick! > > Sorry, I am late. > > It seems that the probability of the collisions for the hash is quite > high. > Due to the fixup procedure, the resulting typenum will depend on the > order > of the module initialization, isn't it ? IMO, it makes the patch goal > not > met. Well, the about 15 file system types currently in FreeBSD don't collide. (At least with the patch I posted. I'll test it again with "hash & 0xff;".) Also, since the collision results in the second one using the next higher value (usually, until you get something like 50+ file system types), it works for those cases unless the order that these 2 file systems call vfs_register() is reversed. (The likelyhood of this reversal is lower than the likelyhood of vfs_register() just being called in a different order, I think?) Since it now changes whenever a different kernel config or different module loading order is used and there aren't a lot of complaints, I think "usually works" is good enough. However, it doesn't matter to me, so I'll let others decide. Yet another option is to go back to what hrs@ originally suggested, which was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't conflict with any assigned vfc_typenum values, since they start at 1 and 255 would also probably be safe, since its unlikely there ever will be 255 different file system types.) The problem with this is no future FS can use the same trick. From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 13:36:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997F9106566B; Wed, 24 Aug 2011 13:36:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 257248FC14; Wed, 24 Aug 2011 13:36:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJ/9VE6DaFvO/2dsb2JhbABCFoQ2pCKBQAEBBAEjVgUWGAICDRkCIzYGExuHVgSpX5ICgSyEDYEQBJMZiXeHIA X-IronPort-AV: E=Sophos;i="4.68,275,1312171200"; d="scan'208";a="132070115" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 24 Aug 2011 09:36:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 36D69B3F67; Wed, 24 Aug 2011 09:36:37 -0400 (EDT) Date: Wed, 24 Aug 2011 09:36:37 -0400 (EDT) From: Rick Macklem To: Kostik Belousov Message-ID: <1673984146.274156.1314192997207.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110824125715.GN17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: pjd@freebsd.org, current@freebsd.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:36:38 -0000 Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote: > > Kostik Belousov wrote > > in <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>: > > > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek > > wrote: > > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > ko> > > Pawel Jakub Dawidek wrote: > > ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem > > wrote: > > ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that > > would > > ko> > > > > inevitably > > ko> > > > > get out of date someday, either. > > ko> > > > > > > ko> > > > > I didn't think hashing for the cases not in the table > > was worth the > > ko> > > > > effort, > > ko> > > > > but doing a hash instead of a table seems reasonable. > > ko> > > > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll > > try and come > > ko> > > > > up > > ko> > > > > with an 8bit hash solution and will post a patch for > > testing/review > > ko> > > > > soon. > > ko> > > > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, > > given that > > ko> > > > > it > > ko> > > > > appears to be deprecated already anyhow. (With an 8bit > > hash, > > ko> > > > > vfs_typenum > > ko> > > > > won't be that sparse.) I'll also make sure that whatever > > hash I use > > ko> > > > > doesn't collide for the current list of file names > > (although I will > > ko> > > > > include > > ko> > > > > code that handles a collision in the patch). > > ko> > > > > > ko> > > > Sounds great. Thanks! > > ko> > > > > > ko> > > Here's the patch. (Hiroki could you please test this, > > thanks, rick.) > > ko> > > ps: If the white space gets trashed, the same patch is at: > > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch > > ko> > > > ko> > The patch is fine by me. Thanks, Rick! > > ko> > > ko> Sorry, I am late. > > ko> > > ko> It seems that the probability of the collisions for the hash is > > quite high. > > ko> Due to the fixup procedure, the resulting typenum will depend on > > the order > > ko> of the module initialization, isn't it ? IMO, it makes the patch > > goal not > > ko> met. > > > > I tried the following two experiments (the complete results are > > attached) to confirm the probability: > > > > 1. [fsidhash1.txt] > > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > > with no fix-up recalculation. > > > > 2. [fsidhash2.txt] > > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is > > 710) > > with no fix-up recalculation. > > > > There is no collision in the case 1. And when [a-z][a-z]fs are > > included the average number of the collided names in the same hash > > value is 4.43 (i.e. 160 different hash values are generated, the > > theoretical best number is (710 entries / 256 buckets) = 2.77). > > > > At least, vfc_names we currently have in our kernel code have no > > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > > impractical data set and these results cannot explain the > > characteristics for all possible and practical vfc_names, so > > whether > > this hash is reasonable or not depends on how we think of them. > > Comments or other better idea? > > Might be, add a new byte field to struct vfsconf, containing the > suggested > byte to be used by fsid. Divide the namespace into two half by the > highest > bit 7. Use the byte values with the highest bit clear for statically > assignment for in-tree modules. Kernel will still check for the > uniquiness > on initialization. > Well, doesn't this result in the same issue as the fixed table? In other words, the developer has to supply the "suggested byte" for fsid and make sure that it doesn't conflict with other "suggested byte" values or suffer the same consequence as forgetting to update the fixed table. (ie. It just puts the fixed value in a different place, from what I see, for in-tree modules. Also, with a fixed table, they are all in one place, so it's easy to choose a non-colliding value?) > Reserve the value '0' to mean that kernel must assign the next unused > value >= 128. This is done to support out-of-tree modules. > > Might be, also reserve the value 0 to mean 'kernel > Main drawback is that is sounds complicated. From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 14:03:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA27106564A; Wed, 24 Aug 2011 14:03:31 +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 365E68FC12; Wed, 24 Aug 2011 14:03:31 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7OE3MFl052449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 17:03:27 +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.4/8.14.4) with ESMTP id p7ODfQNi066651; Wed, 24 Aug 2011 16:41:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7ODfPmE066650; Wed, 24 Aug 2011 16:41:25 +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: Wed, 24 Aug 2011 16:41:25 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20110824134125.GP17489@deviant.kiev.zoral.com.ua> References: <20110824125715.GN17489@deviant.kiev.zoral.com.ua> <1673984146.274156.1314192997207.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gbc0iEmq9s77YLcW" Content-Disposition: inline In-Reply-To: <1673984146.274156.1314192997207.JavaMail.root@erie.cs.uoguelph.ca> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: pjd@freebsd.org, current@freebsd.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:03:31 -0000 --gbc0iEmq9s77YLcW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: > Kostik Belousov wrote: > > On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote: > > > Kostik Belousov wrote > > > in <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>: > > > > > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek > > > wrote: > > > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > > > ko> > > Pawel Jakub Dawidek wrote: > > > ko> > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem > > > wrote: > > > ko> > > > > Ok, I'll admit I wasn't very fond of a fixed table that > > > would > > > ko> > > > > inevitably > > > ko> > > > > get out of date someday, either. > > > ko> > > > > > > > ko> > > > > I didn't think hashing for the cases not in the table > > > was worth the > > > ko> > > > > effort, > > > ko> > > > > but doing a hash instead of a table seems reasonable. > > > ko> > > > > > > > ko> > > > > I see that ZFS only uses the low order 8 bits, so I'll > > > try and come > > > ko> > > > > up > > > ko> > > > > with an 8bit hash solution and will post a patch for > > > testing/review > > > ko> > > > > soon. > > > ko> > > > > > > > ko> > > > > I don't think the vfs_sysctl() is that great a concern, > > > given that > > > ko> > > > > it > > > ko> > > > > appears to be deprecated already anyhow. (With an 8bit > > > hash, > > > ko> > > > > vfs_typenum > > > ko> > > > > won't be that sparse.) I'll also make sure that whatever > > > hash I use > > > ko> > > > > doesn't collide for the current list of file names > > > (although I will > > > ko> > > > > include > > > ko> > > > > code that handles a collision in the patch). > > > ko> > > > > > > ko> > > > Sounds great. Thanks! > > > ko> > > > > > > ko> > > Here's the patch. (Hiroki could you please test this, > > > thanks, rick.) > > > ko> > > ps: If the white space gets trashed, the same patch is at: > > > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch > > > ko> > > > > ko> > The patch is fine by me. Thanks, Rick! > > > ko> > > > ko> Sorry, I am late. > > > ko> > > > ko> It seems that the probability of the collisions for the hash is > > > quite high. > > > ko> Due to the fixup procedure, the resulting typenum will depend on > > > the order > > > ko> of the module initialization, isn't it ? IMO, it makes the patch > > > goal not > > > ko> met. > > > > > > I tried the following two experiments (the complete results are > > > attached) to confirm the probability: > > > > > > 1. [fsidhash1.txt] > > > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > > > with no fix-up recalculation. > > > > > > 2. [fsidhash2.txt] > > > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is > > > 710) > > > with no fix-up recalculation. > > > > > > There is no collision in the case 1. And when [a-z][a-z]fs are > > > included the average number of the collided names in the same hash > > > value is 4.43 (i.e. 160 different hash values are generated, the > > > theoretical best number is (710 entries / 256 buckets) =3D 2.77). > > > > > > At least, vfc_names we currently have in our kernel code have no > > > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > > > impractical data set and these results cannot explain the > > > characteristics for all possible and practical vfc_names, so > > > whether > > > this hash is reasonable or not depends on how we think of them. > > > Comments or other better idea? > >=20 > > Might be, add a new byte field to struct vfsconf, containing the > > suggested > > byte to be used by fsid. Divide the namespace into two half by the > > highest > > bit 7. Use the byte values with the highest bit clear for statically > > assignment for in-tree modules. Kernel will still check for the > > uniquiness > > on initialization. > >=20 > Well, doesn't this result in the same issue as the fixed table? > In other words, the developer has to supply the "suggested byte" for > fsid and make sure that it doesn't conflict with other "suggested byte" > values or suffer the same consequence as forgetting to update the fixed > table. (ie. It just puts the fixed value in a different place, from what > I see, for in-tree modules. Also, with a fixed table, they are all in > one place, so it's easy to choose a non-colliding value?) The reason for my proposal was Pawel note that a porter of the filesystem should be aware of some place in kern/ where to register, besides writing the module. Anyway, do whatever you prefer. >=20 > > Reserve the value '0' to mean that kernel must assign the next unused > > value >=3D 128. This is done to support out-of-tree modules. > >=20 > > Might be, also reserve the value 0 to mean 'kernel > > Main drawback is that is sounds complicated. --gbc0iEmq9s77YLcW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5U/4UACgkQC3+MBN1Mb4iv3wCgpE0FTtSOIyi9i14O2789zK6p N8MAn1uQBBDMjwp3qA9feBeyz7mSJRm1 =QEE4 -----END PGP SIGNATURE----- --gbc0iEmq9s77YLcW-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 14:54:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88DF4106566B for ; Wed, 24 Aug 2011 14:54:40 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from web01.lando.us (web01.lando.us [77.232.247.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE2C8FC08 for ; Wed, 24 Aug 2011 14:54:40 +0000 (UTC) Received: from R2D2 (bridge.aixit.com [82.149.224.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: uwe@grohnwaldt.eu) by web01.lando.us (Postfix) with ESMTPSA id 8F8267D831 for ; Wed, 24 Aug 2011 16:37:18 +0200 (CEST) From: "Uwe Grohnwaldt" To: References: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> <201108230743.10489.jhb@freebsd.org> In-Reply-To: <201108230743.10489.jhb@freebsd.org> Date: Wed, 24 Aug 2011 16:37:20 +0200 Message-ID: <055101cc626b$54aedb30$fe0c9190$@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8/ALEYr63kQpPHfBEQNtjoABymAHlJRZwlbuya7A= Content-Language: de Subject: AW: Panic with 9.0 Beta 1 (arcmsr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:54:40 -0000 Hi, I upgraded a fresh RELENG_8_2 to CURRENT and nearly everything works = fine. I only have to wait about 3 minutes during boot. In dmesg I have many = messages like this: arcmsr1: scsi id 17 lun 0 cmd=3D0x12 = srb=3D'0xffffff8462bd9780' ccb command time out! http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt Thanks, Uwe > -----Urspr=FCngliche Nachricht----- > Von: John Baldwin [mailto:jhb@freebsd.org] > Gesendet: Dienstag, 23. August 2011 13:43 > An: freebsd-current@freebsd.org > Cc: Uwe Grohnwaldt > Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) >=20 > On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: > > Hi, > > > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped > > with a kernel panic: > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q > > buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > > > A screenshot from the panic can be found here: > > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png >=20 > Looks like this was fixed after BETA1 was released. >=20 > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 14:57:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9C31065679 for ; Wed, 24 Aug 2011 14:57:04 +0000 (UTC) (envelope-from victordetoni@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9E7968FC1B for ; Wed, 24 Aug 2011 14:57:04 +0000 (UTC) Received: by qwc9 with SMTP id 9so987606qwc.13 for ; Wed, 24 Aug 2011 07:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=7gljHsI/g8hMANCGIAw4WCVNTfoOHfxifFwF/YTwKyI=; b=mhWHhUGid5dAiJTydt9y8GKBlQMKAsualFlbCetDdA7pPSvEmzDMnCnX+9xVwVOfeC gVmG19IuctwCMh4lKUpSmuQNR8N7Cn0Qu6579cScmpwiEdOjMAbfDSnNf5gxDAnyY2EY ql8QfjuCPx0DxQ/+CEbYZDP6Prs/rNpJ+VNtM= MIME-Version: 1.0 Received: by 10.229.42.10 with SMTP id q10mr3643629qce.45.1314197823834; Wed, 24 Aug 2011 07:57:03 -0700 (PDT) Received: by 10.229.170.7 with HTTP; Wed, 24 Aug 2011 07:57:03 -0700 (PDT) Date: Wed, 24 Aug 2011 11:57:03 -0300 Message-ID: From: Victor Detoni To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:57:04 -0000 Oh shit guys! http://pastebin.com/dyKLRr0v From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 14:59:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27D0C106564A for ; Wed, 24 Aug 2011 14:59:02 +0000 (UTC) (envelope-from victordetoni@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7FFD8FC0A for ; Wed, 24 Aug 2011 14:59:01 +0000 (UTC) Received: by qwc9 with SMTP id 9so989836qwc.13 for ; Wed, 24 Aug 2011 07:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LONRY8Ez8ZnKZQfuYcwRHvYw9+A3DQtTY/mbLK6HU3g=; b=Yia8Z8zaEElWiIQNPi/zEZmzhfxhcgez8NCgpDDb71iG2NcGp75Uhup6bN53z1K756 Q6ht+xysC7IxnkVYfSfHsAEncQRq/jvWjPQqzMHc4lr7ma1l5y25E+ZZCHMyTWSTSQh0 Fe0ifHeQp3RslVkYfbvuk0SyG6FbWO/KeR/+I= MIME-Version: 1.0 Received: by 10.229.232.73 with SMTP id jt9mr465073qcb.121.1314197941296; Wed, 24 Aug 2011 07:59:01 -0700 (PDT) Received: by 10.229.170.7 with HTTP; Wed, 24 Aug 2011 07:59:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 11:59:01 -0300 Message-ID: From: Victor Detoni To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:59:02 -0000 Does Someone know if this was fixed? On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni wrote: > Oh shit guys! > > http://pastebin.com/dyKLRr0v > From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 15:18:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A2E1065670 for ; Wed, 24 Aug 2011 15:18:04 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from web01.lando.us (web01.lando.us [77.232.247.17]) by mx1.freebsd.org (Postfix) with ESMTP id ACACA8FC14 for ; Wed, 24 Aug 2011 15:18:04 +0000 (UTC) Received: from R2D2 (bridge.aixit.com [82.149.224.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: uwe@grohnwaldt.eu) by web01.lando.us (Postfix) with ESMTPSA id EA3A07D91C for ; Wed, 24 Aug 2011 17:18:03 +0200 (CEST) From: "Uwe Grohnwaldt" To: References: <049301cc6183$7d3299e0$7797cda0$@grohnwaldt.eu> <201108230743.10489.jhb@freebsd.org> <055101cc626b$54aedb30$fe0c9190$@grohnwaldt.eu> In-Reply-To: <055101cc626b$54aedb30$fe0c9190$@grohnwaldt.eu> Date: Wed, 24 Aug 2011 17:18:05 +0200 Message-ID: <055701cc6271$0637abc0$12a70340$@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF8/ALEYr63kQpPHfBEQNtjoABymAHlJRZwAnjWImmVp/j/YA== Content-Language: de Subject: AW: Panic with 9.0 Beta 1 (arcmsr.c) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:18:05 -0000 After this messages there are no visible disks. A camcontrol rescan all leads tot he same timeouts. > -----Urspr=FCngliche Nachricht----- > Von: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] Im Auftrag von Uwe Grohnwaldt > Gesendet: Mittwoch, 24. August 2011 16:37 > An: freebsd-current@freebsd.org > Betreff: AW: Panic with 9.0 Beta 1 (arcmsr.c) >=20 > Hi, >=20 > I upgraded a fresh RELENG_8_2 to CURRENT and nearly everything works > fine. I only have to wait about 3 minutes during boot. In dmesg I have many > messages like this: arcmsr1: scsi id 17 lun 0 cmd=3D0x12 > srb=3D'0xffffff8462bd9780' ccb command time out! >=20 > http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt >=20 > Thanks, > Uwe >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: John Baldwin [mailto:jhb@freebsd.org] > > Gesendet: Dienstag, 23. August 2011 13:43 > > An: freebsd-current@freebsd.org > > Cc: Uwe Grohnwaldt > > Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) > > > > On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: > > > Hi, > > > > > > i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped > > > with a kernel panic: > > > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q > > > buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 > > > > > > A screenshot from the panic can be found here: > > > http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png > > > > Looks like this was fixed after BETA1 was released. > > > > -- > > John Baldwin >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 15:27:40 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 523A1106564A; Wed, 24 Aug 2011 15:27:40 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B0CCC8FC12; Wed, 24 Aug 2011 15:27:39 +0000 (UTC) Received: by fxe4 with SMTP id 4so1381078fxe.13 for ; Wed, 24 Aug 2011 08:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zYu10u4PSZzmMbm+A5Cq2c2/34BVRLl69ZQO9gnqn9E=; b=dbJg4UudsXlpg/RNBxvmUILKSAt/kKsC0HLnu2AoY3QoeciAcpfN7isiPs3HVH9E/P 32pp/c7LgUHCtYUGjhrhyO04FuvlDvUZ8BYUqf9iU7TE1BMRWOp7glHjkaBoRv3qIwXn zIl2cbwxSeJ9XwJeq7dwH6mXTdXOFZqis+PrA= Received: by 10.223.55.203 with SMTP id v11mr7337019fag.78.1314198253060; Wed, 24 Aug 2011 08:04:13 -0700 (PDT) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id r12sm903172fam.14.2011.08.24.08.04.10 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 08:04:11 -0700 (PDT) Date: Wed, 24 Aug 2011 18:02:35 +0300 From: Gleb Kurtsou To: Hiroki Sato Message-ID: <20110824150235.GA46460@tops> References: <1614657395.247867.1314130280524.JavaMail.root@erie.cs.uoguelph.ca> <20110823212301.GE1697@garage.freebsd.pl> <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <20110824.213458.806017948592590395.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110824.213458.806017948592590395.hrs@allbsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kostikbel@gmail.com, rmacklem@uoguelph.ca, pjd@FreeBSD.org, current@FreeBSD.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:27:40 -0000 On (24/08/2011 21:34), Hiroki Sato wrote: > Kostik Belousov wrote > in <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>: > > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) > ko> > > ps: If the white space gets trashed, the same patch is at: > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch > ko> > > ko> > The patch is fine by me. Thanks, Rick! > ko> > ko> Sorry, I am late. > ko> > ko> It seems that the probability of the collisions for the hash is quite high. > ko> Due to the fixup procedure, the resulting typenum will depend on the order > ko> of the module initialization, isn't it ? IMO, it makes the patch goal not > ko> met. > > I tried the following two experiments (the complete results are > attached) to confirm the probability: > > 1. [fsidhash1.txt] > well-known vfc_name and the names "[a-z]fs" (# of names is 36) > with no fix-up recalculation. > > 2. [fsidhash2.txt] > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) > with no fix-up recalculation. > > There is no collision in the case 1. And when [a-z][a-z]fs are > included the average number of the collided names in the same hash > value is 4.43 (i.e. 160 different hash values are generated, the > theoretical best number is (710 entries / 256 buckets) = 2.77). Could you run the same test with fnv_32_buf()? Collision rate is likely to be lower. > At least, vfc_names we currently have in our kernel code have no > collision, fortunately. As you noticed "[a-z][a-z]fs" is an > impractical data set and these results cannot explain the > characteristics for all possible and practical vfc_names, so whether > this hash is reasonable or not depends on how we think of them. > Comments or other better idea? > > -- Hiroki From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 15:42:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCB981065676 for ; Wed, 24 Aug 2011 15:42:54 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (wrz3028.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 92FC08FC13 for ; Wed, 24 Aug 2011 15:42:54 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0EECA5AC44; Wed, 24 Aug 2011 17:42:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0BAC75AC3D; Wed, 24 Aug 2011 17:42:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id DFCE05CBD8; Wed, 24 Aug 2011 17:42:52 +0200 (CEST) Received: from lexx.ifp.tuwien.ac.at ([128.131.127.223]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.2FP3HF61) with ESMTP id 2011082417425179-63000 ; Wed, 24 Aug 2011 17:42:51 +0200 Date: Wed, 24 Aug 2011 17:42:51 +0200 From: Alexey Shuvaev To: Victor Detoni Message-ID: <20110824154251.GA21876@lexx.ifp.tuwien.ac.at> References: MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.2FP3HF61 | August 2, 2011) at 08/24/2011 05:42:51 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.2FP3HF61 | August 2, 2011) at 08/24/2011 05:42:51 PM, Serialize complete at 08/24/2011 05:42:51 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:42:54 -0000 On Wed, Aug 24, 2011 at 11:59:01AM -0300, Victor Detoni wrote: > Does Someone know if this was fixed? > > On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni wrote: > > > Oh shit guys! > > > > http://pastebin.com/dyKLRr0v > > > It is already one year old... and it was fixed before this pastebin: http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf.asc Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 15:56:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73240106564A for ; Wed, 24 Aug 2011 15:56:32 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1868FC19 for ; Wed, 24 Aug 2011 15:56:31 +0000 (UTC) Received: from [192.168.12.4] (unknown [192.168.12.4]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 43FE739834 for ; Wed, 24 Aug 2011 17:39:12 +0200 (CEST) Message-ID: <4E551B1B.7030905@stillbilde.net> Date: Wed, 24 Aug 2011 17:39:07 +0200 From: "Svein Skogen (Listmail account)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC68AFB488192EC6E872F340" Subject: Re: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:56:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC68AFB488192EC6E872F340 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 24.08.2011 16:59, Victor Detoni wrote: > Does Someone know if this was fixed? >=20 > On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni wrote: >=20 >> Oh shit guys! >> >> http://pastebin.com/dyKLRr0v >> http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf.asc Isn't this the one? //Svein --=20 --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =D8stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE --------+-------------------+------------------------------- 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? ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ ------------------------------------------------------------ --------------enigCC68AFB488192EC6E872F340 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5VGx8ACgkQODUnwSLUlKTufACeNBD2on8Ny2g5Q/SdeSNoRPpA hCAAnjsSeiqACuJLSTdaHqjSf7TyDaAX =F6Hr -----END PGP SIGNATURE----- --------------enigCC68AFB488192EC6E872F340-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 16:04:53 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13E0106564A; Wed, 24 Aug 2011 16:04:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 477EC8FC12; Wed, 24 Aug 2011 16:04:51 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OG4aRd038253; Thu, 25 Aug 2011 01:04:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OG4XQO045481; Thu, 25 Aug 2011 01:04:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 25 Aug 2011 01:04:24 +0900 (JST) Message-Id: <20110825.010424.484677638916081204.hrs@allbsd.org> To: gleb.kurtsou@gmail.com From: Hiroki Sato In-Reply-To: <20110824150235.GA46460@tops> References: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <20110824.213458.806017948592590395.hrs@allbsd.org> <20110824150235.GA46460@tops> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Thu_Aug_25_01_04_24_2011_949)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 25 Aug 2011 01:04:47 +0900 (JST) X-Spam-Status: No, score=-104.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: kostikbel@gmail.com, rmacklem@uoguelph.ca, pjd@FreeBSD.org, current@FreeBSD.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:04:53 -0000 ----Security_Multipart0(Thu_Aug_25_01_04_24_2011_949)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_25_01_04_24_2011_827)--" Content-Transfer-Encoding: 7bit ----Next_Part(Thu_Aug_25_01_04_24_2011_827)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gleb Kurtsou wrote in <20110824150235.GA46460@tops>: gl> On (24/08/2011 21:34), Hiroki Sato wrote: gl> > Kostik Belousov wrote gl> > in <20110824082119.GJ17489@deviant.kiev.zoral.com.ua>: gl> > gl> > ko> On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: gl> > ko> > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: gl> > ko> > > Here's the patch. (Hiroki could you please test this, thanks, rick.) gl> > ko> > > ps: If the white space gets trashed, the same patch is at: gl> > ko> > > http://people.freebsd.org/~rmacklem/fsid.patch gl> > ko> > gl> > ko> > The patch is fine by me. Thanks, Rick! gl> > ko> gl> > ko> Sorry, I am late. gl> > ko> gl> > ko> It seems that the probability of the collisions for the hash is quite high. gl> > ko> Due to the fixup procedure, the resulting typenum will depend on the order gl> > ko> of the module initialization, isn't it ? IMO, it makes the patch goal not gl> > ko> met. gl> > gl> > I tried the following two experiments (the complete results are gl> > attached) to confirm the probability: gl> > gl> > 1. [fsidhash1.txt] gl> > well-known vfc_name and the names "[a-z]fs" (# of names is 36) gl> > with no fix-up recalculation. gl> > gl> > 2. [fsidhash2.txt] gl> > well-known vfc_name and the names "[a-z][a-z]fs" (# of names is 710) gl> > with no fix-up recalculation. gl> > gl> > There is no collision in the case 1. And when [a-z][a-z]fs are gl> > included the average number of the collided names in the same hash gl> > value is 4.43 (i.e. 160 different hash values are generated, the gl> > theoretical best number is (710 entries / 256 buckets) = 2.77). gl> Could you run the same test with fnv_32_buf()? Collision rate is likely gl> to be lower. The results by fnv_32_str() are attached. The number of the collisions reduced but this time there were four collisions in the "well-known ones + [a-z]fs" case though no collision within the well-known names. The generated hash values for the case 2 was 235, so the rate is 3.02. This is certainly better than hash32_str(). -- Hiroki ----Next_Part(Thu_Aug_25_01_04_24_2011_827)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsidhash_fnv1.txt" 0x0d = yfs 0x13 = mfs 0x19 = procfs 0x1a = kfs 0x30 = bfs 0x34 = ufs 0x3a = gfs 0x40 = sfs, udf 0x56 = jfs 0x5a = ntfs 0x5d = ext2fs 0x61 = devfs 0x6f = hpfs 0x75 = hfs 0x7a = pfs 0x7b = ofs 0x7c = dfs 0x81 = wfs 0x88 = msdosfs 0xa0 = cd9660 0xa1 = lfs, xfs 0xa8 = cfs, tfs 0xbf = tmpfs 0xc0 = afs 0xc2 = reiserfs 0xc6 = ifs 0xc8 = ffs, rfs 0xec = qfs 0xed = zfs 0xee = efs 0xef = nfs 0xf4 = vfs ----Next_Part(Thu_Aug_25_01_04_24_2011_827)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsidhash_fnv2.txt" 0x01 = mcfs, prfs, xufs 0x02 = iafs, jifs, kpfs, xifs 0x04 = bzfs, dbfs, ehfs, ewfs, klfs, yhfs 0x05 = ycfs 0x06 = dyfs, ecfs, ipfs, qdfs, qpfs 0x07 = pnfs, ywfs 0x08 = qofs, xafs 0x09 = bmfs, iffs, iyfs, kdfs, pufs, vffs 0x0a = imfs 0x0b = bffs, dmfs 0x0c = idfs, yofs 0x0d = adfs, nmfs, pafs, vqfs, yfs 0x0e = aifs, qwfs 0x0f = hafs, nffs, vzfs 0x10 = zafs 0x11 = wcfs 0x12 = zjfs 0x13 = mfs, nqfs, wwfs 0x14 = nefs, vcfs 0x15 = bkfs 0x16 = clfs, zifs 0x17 = njfs, zrfs 0x18 = ocfs, owfs, tvfs, wdfs 0x19 = fefs, procfs, tbfs, vwfs, zffs 0x1a = fnfs, fqfs, kfs 0x1b = gofs, ryfs 0x1d = fzfs, rmfs, rrfs, skfs 0x1e = odfs, tqfs 0x1f = lvfs, oofs, oxfs, rffs, tzfs 0x20 = eefs, gwfs, kmfs, tmfs, xcfs 0x21 = ulfs, yqfs 0x22 = fbfs, hrfs, mtfs, qifs, sxfs, xjfs 0x23 = dofs, sdfs, ssfs, ugfs 0x24 = etfs, kofs, usfs, uxfs 0x25 = kqfs, ljfs, mkfs, opfs, pcfs 0x26 = jrfs, pwfs, qxfs 0x27 = ghfs 0x28 = hjfs, xvfs 0x29 = hufs, ikfs, jpfs, ksfs, slfs 0x2a = byfs, jefs, khfs, ukfs 0x2b = brfs, dhfs, jnfs, ytfs 0x2c = defs, hwfs, msfs 0x2d = apfs, qlfs 0x2e = pdfs, pifs, vefs 0x2f = befs, cgfs, hmfs, iwfs, jlfs, vnfs 0x30 = bfs, bjfs, jwfs 0x31 = csfs, cxfs 0x33 = alfs, axfs, vyfs 0x34 = ufs 0x35 = acfs, jcfs, vvfs 0x36 = awfs, bcfs, vbfs 0x37 = wkfs 0x38 = tofs 0x3a = fmfs, gfs 0x3b = nvfs 0x3c = nbfs, rqfs 0x3d = tgfs, tsfs, zwfs 0x3e = wlfs, zzfs 0x3f = fkfs, wgfs, znfs 0x40 = dvfs, gcfs, sfs, thfs, udf, wpfs 0x41 = fwfs 0x42 = pzfs, rwfs, udfs 0x43 = dgfs, lgfs, sgfs 0x44 = rkfs 0x45 = dnfs, llfs, lsfs, ogfs 0x46 = lxfs, pkfs, wxfs 0x47 = dqfs, eofs, gdfs, xofs 0x48 = dzfs, pbfs, upfs, xdfs, xpfs 0x49 = qcfs 0x4a = dsfs, pvfs, rcfs 0x4b = exfs, jzfs, mhfs, ohfs 0x4c = esfs, gpfs, ylfs 0x4d = qtfs, ygfs 0x4e = hbfs, hofs, ihfs 0x4f = bhfs, hvfs, icfs, uvfs 0x50 = bwfs, ktfs, mnfs, stfs 0x51 = ejfs 0x53 = itfs 0x54 = qffs, vkfs, vtfs 0x56 = bofs, cofs, jfs, jkfs 0x57 = iofs, yjfs 0x59 = qrfs 0x5a = atfs, ntfs, vsfs 0x5b = akfs 0x5d = ccfs, chfs, ctfs, ext2fs, zlfs, zxfs 0x5e = fvfs, wzfs 0x60 = nsfs, rjfs, wsfs 0x61 = devfs, ftfs, nofs, nxfs 0x62 = agfs, fjfs, xbfs 0x63 = ojfs 0x64 = grfs, kgfs, rhfs, rvfs, tkfs, wofs, zcfs, ztfs 0x65 = lofs, ttfs 0x66 = fhfs, gffs 0x67 = mgfs, ngfs, svfs, xsfs 0x68 = fsfs, sbfs 0x69 = ppfs, rtfs, zkfs 0x6a = jxfs, rofs, uhfs 0x6b = dkfs, elfs, kkfs, mefs, mpfs, ucfs 0x6c = omfs, txfs, yxfs 0x6d = egfs, fgfs, pgfs, ysfs 0x6e = gufs, gxfs, kbfs, plfs, uafs, xgfs 0x6f = hpfs 0x70 = myfs, qkfs, sqfs, uzfs 0x71 = epfs, jtfs, kxfs 0x72 = mbfs, ydfs 0x73 = hgfs, hsfs 0x74 = ekfs, ykfs 0x75 = cvfs, hfs, qsfs, unfs 0x76 = btfs, hhfs 0x77 = jgfs, mvfs, qgfs 0x78 = evfs, ybfs 0x7a = pfs 0x7b = ahfs, cjfs, isfs, ofs, qzfs, vhfs 0x7c = bgfs, dfs 0x7d = blfs, cefs, cqfs, igfs 0x7f = anfs 0x80 = osfs 0x81 = aefs, arfs, gkfs, nlfs, vgfs, vpfs, wfs 0x83 = bsfs, obfs, wbfs 0x84 = twfs, wifs 0x85 = sofs, wvfs 0x86 = gzfs, okfs, otfs 0x87 = azfs, ltfs, npfs, vofs 0x88 = glfs, gsfs, msdosfs, nkfs 0x89 = ggfs 0x8a = ovfs, shfs, swfs, xhfs 0x8b = gnfs, tcfs, uwfs, zgfs 0x8c = dtfs, lcfs, scfs, wefs 0x8d = lhfs, mofs, psfs 0x8e = fofs 0x8f = kzfs, pxfs, sjfs 0x90 = kwfs, rsfs, xtfs, zsfs 0x91 = dcfs, dwfs, lqfs, tefs 0x92 = dlfs, ebfs, eifs, kcfs, yifs 0x93 = pofs, yvfs 0x94 = qnfs, qqfs 0x95 = dxfs, xmfs 0x96 = jhfs, qefs, uffs 0x97 = lefs 0x98 = ezfs, ptfs 0x99 = iqfs, ynfs 0x9a = hkfs, xyfs 0x9b = bqfs, qvfs 0x9c = iefs 0x9d = asfs, bxfs, htfs, jofs 0x9e = jdfs, jsfs 0x9f = vmfs 0xa0 = cd9660 0xa1 = aqfs, cffs, ijfs, ivfs, lfs, vdfs, xfs 0xa2 = hlfs 0xa3 = aofs, bdfs, cmfs, crfs 0xa4 = cyfs, wjfs 0xa6 = amfs, nifs 0xa7 = avfs, oyfs, tlfs, vxfs 0xa8 = cfs, fdfs, gafs, ibfs, tfs, zefs, zqfs 0xa9 = fpfs 0xaa = cafs, rxfs, uufs 0xab = mmfs, rgfs, tnfs 0xac = fyfs, lwfs, onfs, rlfs, sefs, tpfs 0xad = abfs, gvfs, oefs 0xae = nwfs, nzfs, refs 0xaf = fcfs, knfs, umfs, xkfs 0xb0 = srfs, zvfs 0xb1 = lkfs, mufs, syfs, tifs, trfs, urfs 0xb2 = kefs, mafs, mjfs, uyfs 0xb4 = ldfs, lpfs, xwfs 0xb6 = jqfs, kffs, krfs, ujfs, xxfs 0xb7 = eufs, xlfs 0xb8 = difs, lmfs, mrfs, yafs 0xb9 = ddfs, eafs, kifs 0xba = pefs, qyfs, yufs 0xbb = dpfs, hcfs, jmfs, phfs, qmfs, xqfs 0xbc = jyfs 0xbd = jbfs 0xbe = erfs, jvfs 0xbf = enfs, eyfs, tmpfs, yffs 0xc0 = afs, hefs, ymfs, yzfs 0xc1 = bifs, hnfs, hyfs, iifs 0xc2 = bbfs, ndfs, qbfs, qufs, reiserfs 0xc3 = bvfs, cnfs 0xc5 = effs, vufs, zhfs 0xc6 = ifs, nufs, vafs, yrfs 0xc7 = qjfs, vjfs 0xc8 = czfs, ffs, hqfs, infs, iufs, rfs, wqfs, zyfs 0xc9 = ncfs, nhfs 0xca = bnfs 0xcb = wffs, zofs, zpfs 0xcc = nafs, ozfs, wmfs, zdfs 0xcd = gbfs, izfs, oqfs 0xce = ajfs, fafs, flfs, gifs, tdfs, vrfs 0xcf = fxfs, zmfs 0xd0 = rpfs, sffs 0xd1 = lffs, offs, orfs, smfs 0xd2 = oifs, rdfs, wtfs 0xd3 = gjfs, lrfs, lyfs 0xd4 = xzfs 0xd5 = gqfs, snfs, szfs, xefs 0xd6 = gefs, uefs, uqfs, xnfs 0xd7 = dffs, sufs 0xd8 = drfs, lafs, safs, tufs 0xd9 = mifs, pjfs 0xdd = bpfs, dafs, edfs, kjfs, ubfs, uifs 0xde = djfs, hxfs, kafs, kufs, mqfs, mzfs, ypfs 0xdf = emfs, mffs, qhfs 0xe0 = pmfs, yyfs 0xe1 = bafs, hzfs, pffs, pqfs 0xe2 = ayfs, jafs, qafs, vlfs 0xe3 = hdfs, jjfs, jufs 0xe4 = dufs, eqfs 0xe5 = cufs, ixfs, kyfs, yefs 0xe7 = aafs, hffs, ilfs, pyfs 0xe8 = bufs 0xe9 = aufs, cwfs, nnfs 0xea = cbfs, jffs 0xeb = cifs, tffs 0xec = qfs, wrfs, zbfs 0xed = hifs, nyfs, vifs, wyfs, zfs 0xee = affs, ckfs, efs, fufs, nrfs 0xef = cpfs, irfs, nfs 0xf0 = rifs, zufs 0xf1 = wnfs 0xf2 = fifs, rbfs, tafs, tjfs 0xf3 = wafs 0xf4 = vfs 0xf5 = cdfs, rufs, wufs 0xf6 = fffs, frfs, rafs 0xf7 = mdfs, rzfs 0xf8 = lnfs, olfs, whfs 0xf9 = gtfs, lzfs, oafs, rnfs, tyfs 0xfa = gyfs, xrfs 0xfb = oufs 0xfc = gmfs, spfs, utfs, xffs 0xfd = kvfs, mlfs, mxfs, uofs 0xfe = mwfs 0xff = lbfs, lifs, lufs, sifs ----Next_Part(Thu_Aug_25_01_04_24_2011_827)---- ----Security_Multipart0(Thu_Aug_25_01_04_24_2011_949)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5VIQgACgkQTyzT2CeTzy0QiQCfZfD5Yao56/yxNjatrGSi8ld+ P9gAn2tUMb36BF3apcHk6lsgdQH6w6lp =Ubz3 -----END PGP SIGNATURE----- ----Security_Multipart0(Thu_Aug_25_01_04_24_2011_949)---- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 19:13:37 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3ECD106564A; Wed, 24 Aug 2011 19:13:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1D98F8FC12; Wed, 24 Aug 2011 19:13:36 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OJDMSA085253; Thu, 25 Aug 2011 04:13:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7OJDJbX048186; Thu, 25 Aug 2011 04:13:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 25 Aug 2011 04:13:15 +0900 (JST) Message-Id: <20110825.041315.156163335542976067.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> References: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Aug_25_04_13_15_2011_895)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 25 Aug 2011 04:13:34 +0900 (JST) X-Spam-Status: No, score=-104.1 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: kostikbel@gmail.com, pjd@FreeBSD.org, kaduk@MIT.EDU, current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:13:37 -0000 ----Security_Multipart(Thu_Aug_25_04_13_15_2011_895)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca>: rm> Kostik Belousov wrote: rm> > On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote: rm> > > On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote: rm> > > > Pawel Jakub Dawidek wrote: rm> > > > > On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote: rm> > > > > > Ok, I'll admit I wasn't very fond of a fixed table that would rm> > > > > > inevitably rm> > > > > > get out of date someday, either. rm> > > > > > rm> > > > > > I didn't think hashing for the cases not in the table was rm> > > > > > worth the rm> > > > > > effort, rm> > > > > > but doing a hash instead of a table seems reasonable. rm> > > > > > rm> > > > > > I see that ZFS only uses the low order 8 bits, so I'll try and rm> > > > > > come rm> > > > > > up rm> > > > > > with an 8bit hash solution and will post a patch for rm> > > > > > testing/review rm> > > > > > soon. rm> > > > > > rm> > > > > > I don't think the vfs_sysctl() is that great a concern, given rm> > > > > > that rm> > > > > > it rm> > > > > > appears to be deprecated already anyhow. (With an 8bit hash, rm> > > > > > vfs_typenum rm> > > > > > won't be that sparse.) I'll also make sure that whatever hash rm> > > > > > I use rm> > > > > > doesn't collide for the current list of file names (although I rm> > > > > > will rm> > > > > > include rm> > > > > > code that handles a collision in the patch). rm> > > > > rm> > > > > Sounds great. Thanks! rm> > > > > rm> > > > Here's the patch. (Hiroki could you please test this, thanks, rm> > > > rick.) rm> > > > ps: If the white space gets trashed, the same patch is at: rm> > > > http://people.freebsd.org/~rmacklem/fsid.patch rm> > > rm> > > The patch is fine by me. Thanks, Rick! rm> > rm> > Sorry, I am late. rm> > rm> > It seems that the probability of the collisions for the hash is quite rm> > high. rm> > Due to the fixup procedure, the resulting typenum will depend on the rm> > order rm> > of the module initialization, isn't it ? IMO, it makes the patch goal rm> > not rm> > met. rm> Well, the about 15 file system types currently in FreeBSD don't collide. rm> (At least with the patch I posted. I'll test it again with "hash & 0xff;".) rm> rm> Also, since the collision results in the second one using the next higher rm> value (usually, until you get something like 50+ file system types), it works rm> for those cases unless the order that these 2 file systems call vfs_register() rm> is reversed. (The likelyhood of this reversal is lower than the likelyhood rm> of vfs_register() just being called in a different order, I think?) rm> rm> Since it now changes whenever a different kernel config or different module rm> loading order is used and there aren't a lot of complaints, I think "usually rm> works" is good enough. However, it doesn't matter to me, so I'll let others rm> decide. rm> rm> Yet another option is to go back to what hrs@ originally suggested, which rm> was change ZFS to not use vfc_typenum in its fsid. (I now see that 0 won't rm> conflict with any assigned vfc_typenum values, since they start at 1 and rm> 255 would also probably be safe, since its unlikely there ever will be rm> 255 different file system types.) The problem with this is no future FS rm> can use the same trick. My opinion is using a hash function which occurs no collision in the well-known names is sufficient for our purpose because the number of file systems on a running system is small anyway and not changed frequently in most cases. I am not sure which function is best; fnv_32_str() seemed better against a large data set but it is not likely to have >30 file systems, for example. -- Hiroki ----Security_Multipart(Thu_Aug_25_04_13_15_2011_895)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5VTUsACgkQTyzT2CeTzy3QqgCeIJwG0uxBz3Sjg0fMUNbBmfre hjQAn1BzuAX6EeCHlg2rHuwRh8rCcmnG =WhV4 -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Aug_25_04_13_15_2011_895)---- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 19:24:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F536106566B; Wed, 24 Aug 2011 19:24:52 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id CE6658FC14; Wed, 24 Aug 2011 19:24:51 +0000 (UTC) X-AuditID: 12074424-b7bcaae000000a05-f4-4e55502ec082 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.51.02565.E20555E4; Wed, 24 Aug 2011 15:25:34 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p7OJOoL8015751; Wed, 24 Aug 2011 15:24:51 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7OJOn6j012042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 15:24:50 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7OJOmMm024903; Wed, 24 Aug 2011 15:24:48 -0400 (EDT) Date: Wed, 24 Aug 2011 15:24:48 -0400 (EDT) From: Benjamin Kaduk To: Hiroki Sato In-Reply-To: <20110825.041315.156163335542976067.hrs@allbsd.org> Message-ID: References: <20110824082119.GJ17489@deviant.kiev.zoral.com.ua> <920337541.272757.1314192294772.JavaMail.root@erie.cs.uoguelph.ca> <20110825.041315.156163335542976067.hrs@allbsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT19ULCPUzuPKAz2LClR9MFrfaVzFb NEx7zGZxeepSNouHy64xObB6zPg0n8Vj56y77B6/N+9lCmCO4rJJSc3JLEst0rdL4Mq4uDWo 4C1bxfIXm1kbGDezdjFyckgImEjcfryNGcIWk7hwbz1bFyMXh5DAPkaJNSeOs0A4GxglFvW3 MUI4B5gk5t7+zAzhNDBK7Nx1nBGkn0VAW2LqkiNgc9kEVCRmvtkINIuDQ0RAUaL/iDdImFkg RuLp0g9sILawgILEhLvrmEBsTgEHiZ6HU8HivED23P/vmCDmb2WUePRrOdh8UQEdidX7p7BA FAlKnJz5hAViqKXEv7W/WCcwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrle bmaJXmpK6SZGcEi7qOxgbD6kdIhRgINRiYf3gkOonxBrYllxZe4hRkkOJiVR3jd+QCG+pPyU yozE4oz4otKc1OJDjBIczEoivKfOhfgJ8aYkVlalFuXDpKQ5WJTEeW12OvgJCaQnlqRmp6YW pBbBZGU4OJQkePX8gYYKFqWmp1akZeaUIKSZODhBhvMADX8Aspi3uCAxtzgzHSJ/ilFRSpzX FaRZACSRUZoH1wtLOa8YxYFeEeaNBaniAaYruO5XQIOZgAZz/AoCGVySiJCSamCsU1T8svHV R4H0JRd6nhq2lNywldyW8VzN70bXOh1RzWL1ix6t9eeWFd821X75tbE+3nbZlqca9c+mrdi7 6sMd/ZVGjxYf0XRm2N43S2LDtELnsnMMpvvEYie/uJQXqXF3a8OVlQeEz2k+nrJp9cOsrZFz FcUEerQ3pERMnVi6kCtBPP9YymspJZbijERDLeai4kQAdUpSFhQDAAA= Cc: kostikbel@gmail.com, rmacklem@uoguelph.ca, pjd@freebsd.org, current@freebsd.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:24:52 -0000 On Thu, 25 Aug 2011, Hiroki Sato wrote: > > My opinion is using a hash function which occurs no collision in the > well-known names is sufficient for our purpose because the number of > file systems on a running system is small anyway and not changed > frequently in most cases. I am not sure which function is best; > fnv_32_str() seemed better against a large data set but it is not > likely to have >30 file systems, for example. This was a large part of my reasoning when proposing a hash table initially -- there are 256 (maybe 255 if you want to reserve one) slots, and only 14 or so filesystems currently in the tree. It seems very unlikely that any single machine would ever have more than another five out-of-tree filesystem types on it (right?), so putting 20 items into 250 hash bins is a pretty good chance of being collision-free. -Ben From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 20:08:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62EA3106566C; Wed, 24 Aug 2011 20:08:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 141878FC16; Wed, 24 Aug 2011 20:08:32 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id A3A3346; Wed, 24 Aug 2011 22:08:31 +0200 (CEST) Date: Wed, 24 Aug 2011 22:08:14 +0200 From: Pawel Jakub Dawidek To: Kostik Belousov Message-ID: <20110824200813.GC1688@garage.freebsd.pl> References: <20110824125715.GN17489@deviant.kiev.zoral.com.ua> <1673984146.274156.1314192997207.JavaMail.root@erie.cs.uoguelph.ca> <20110824134125.GP17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: <20110824134125.GP17489@deviant.kiev.zoral.com.ua> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rick Macklem , current@freebsd.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:08:33 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: > > Well, doesn't this result in the same issue as the fixed table? > > In other words, the developer has to supply the "suggested byte" for > > fsid and make sure that it doesn't conflict with other "suggested byte" > > values or suffer the same consequence as forgetting to update the fixed > > table. (ie. It just puts the fixed value in a different place, from what > > I see, for in-tree modules. Also, with a fixed table, they are all in > > one place, so it's easy to choose a non-colliding value?) > The reason for my proposal was Pawel note that a porter of the filesystem > should be aware of some place in kern/ where to register, besides writing > the module. Well, he has to be aware, but we should do all we can to minimize the number of place he needs to update, as it is easy to forget some. I agree with Rick that what you proposed is similar to fixed table of file system names and I'd prefer to avoid that. If we can have name-based hash that produces no collision for in-tree file systems and know current 3rd party file systems plus collision detection for the future then it is good enough, IMHO. And this is what Rick proposed with his patch. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk5VWi0ACgkQForvXbEpPzRlbwCg5jmtdAPHJwEVo0iSXLHkvDX5 LiYAn0K+1u1VV3u4a2VHtxYHr1dFS2Fi =OyGc -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 21:01:22 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF679106566B; Wed, 24 Aug 2011 21:01:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 51E3C8FC1C; Wed, 24 Aug 2011 21:01:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPJlVU6DaFvO/2dsb2JhbABChEykK4FAAQEFIwRSGxgCAg0ZAlkGLrAjkWCBLIQNgRAEkxmRFw X-IronPort-AV: E=Sophos;i="4.68,277,1312171200"; d="scan'208";a="135448654" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 24 Aug 2011 17:01:21 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8C7B7B3F76; Wed, 24 Aug 2011 17:01:21 -0400 (EDT) Date: Wed, 24 Aug 2011 17:01:21 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <1700752765.310013.1314219681559.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110824200813.GC1688@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Kostik Belousov , current@freebsd.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:01:22 -0000 Pawel Jakub Dawidek wrote: > On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote: > > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: > > > Well, doesn't this result in the same issue as the fixed table? > > > In other words, the developer has to supply the "suggested byte" > > > for > > > fsid and make sure that it doesn't conflict with other "suggested > > > byte" > > > values or suffer the same consequence as forgetting to update the > > > fixed > > > table. (ie. It just puts the fixed value in a different place, > > > from what > > > I see, for in-tree modules. Also, with a fixed table, they are all > > > in > > > one place, so it's easy to choose a non-colliding value?) > > The reason for my proposal was Pawel note that a porter of the > > filesystem > > should be aware of some place in kern/ where to register, besides > > writing > > the module. > > Well, he has to be aware, but we should do all we can to minimize the > number of place he needs to update, as it is easy to forget some. > > I agree with Rick that what you proposed is similar to fixed table of > file system names and I'd prefer to avoid that. If we can have > name-based hash that produces no collision for in-tree file systems > and > know current 3rd party file systems plus collision detection for the > future then it is good enough, IMHO. And this is what Rick proposed > with > his patch. > Ok, here is the list of file system names I've been checking and there haven't been any collisions (either hash function). If you know of other well known file type names, please email and I'll add them to the list and check for collisions again. "cd9660" "ufs" "procfs" "devfs" "msdosfs" "nfs" "xfs" "reiserfs" "tmpfs" "hpfs" "ntfs" "ext2fs" "udf" "zfs" "afs" and here is my current rendition of the patch. (I took Gleb's suggestion and switched to fnv_32_str(). I'll leave it that way unless there is a collision after adding any names people post to the above list.) It sounds like people have agreed that this is a reasonable solution. If hrs@ can confirm that testing shows it fixes the original problem (the ZFS file handles don't change when it's loaded at different times), I'll pass it along to re@. Thanks for the helpful suggestions, rick --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 +++ kern/vfs_init.c 2011-08-24 16:15:24.000000000 -0400 @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in #include #include +#include #include #include #include @@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc) struct sysctl_oid *oidp; struct vfsops *vfsops; static int once; + struct vfsconf *tvfc; + uint32_t hashval; if (!once) { vattr_null(&va_null); @@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc) if (vfs_byname(vfc->vfc_name) != NULL) return EEXIST; - vfc->vfc_typenum = maxvfsconf++; + /* + * Calculate a hash on vfc_name to use for vfc_typenum. Unless + * a collision occurs, it is limited to 8bits since that is + * what ZFS uses from vfc_typenum and that also limits how sparsely + * distributed vfc_typenum becomes. + */ + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); + hashval &= 0xff; + do { + /* Look for and fix any collision. */ + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { + if (hashval == tvfc->vfc_typenum) { + hashval++; /* Can exceed 8bits, if needed. */ + break; + } + } + } while (tvfc != NULL); + vfc->vfc_typenum = hashval; + if (vfc->vfc_typenum >= maxvfsconf) + maxvfsconf = vfc->vfc_typenum + 1; TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); /* From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 21:01:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A12106564A; Wed, 24 Aug 2011 21:01:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id F08DE8FC1E; Wed, 24 Aug 2011 21:01:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPJlVU6DaFvO/2dsb2JhbABChEykK4FAAQEFIwRSGxgCAg0ZAlkGLrAjkWCBLIQNgRAEkxmRFw X-IronPort-AV: E=Sophos;i="4.68,277,1312171200"; d="scan'208";a="135448656" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 24 Aug 2011 17:01:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 980F2B3F77; Wed, 24 Aug 2011 17:01:22 -0400 (EDT) Date: Wed, 24 Aug 2011 17:01:22 -0400 (EDT) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110824200813.GC1688@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Kostik Belousov , current@freebsd.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:01:23 -0000 Pawel Jakub Dawidek wrote: > On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote: > > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: > > > Well, doesn't this result in the same issue as the fixed table? > > > In other words, the developer has to supply the "suggested byte" > > > for > > > fsid and make sure that it doesn't conflict with other "suggested > > > byte" > > > values or suffer the same consequence as forgetting to update the > > > fixed > > > table. (ie. It just puts the fixed value in a different place, > > > from what > > > I see, for in-tree modules. Also, with a fixed table, they are all > > > in > > > one place, so it's easy to choose a non-colliding value?) > > The reason for my proposal was Pawel note that a porter of the > > filesystem > > should be aware of some place in kern/ where to register, besides > > writing > > the module. > > Well, he has to be aware, but we should do all we can to minimize the > number of place he needs to update, as it is easy to forget some. > > I agree with Rick that what you proposed is similar to fixed table of > file system names and I'd prefer to avoid that. If we can have > name-based hash that produces no collision for in-tree file systems > and > know current 3rd party file systems plus collision detection for the > future then it is good enough, IMHO. And this is what Rick proposed > with > his patch. > Ok, here is the list of file system names I've been checking and there haven't been any collisions (either hash function). If you know of other well known file type names, please email and I'll add them to the list and check for collisions again. "cd9660" "ufs" "procfs" "devfs" "msdosfs" "nfs" "xfs" "reiserfs" "tmpfs" "hpfs" "ntfs" "ext2fs" "udf" "zfs" "afs" and here is my current rendition of the patch. (I took Gleb's suggestion and switched to fnv_32_str(). I'll leave it that way unless there is a collision after adding any names people post to the above list.) It sounds like people have agreed that this is a reasonable solution. If hrs@ can confirm that testing shows it fixes the original problem (the ZFS file handles don't change when it's loaded at different times), I'll pass it along to re@. Thanks for the helpful suggestions, rick --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 +++ kern/vfs_init.c 2011-08-24 16:15:24.000000000 -0400 @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in #include #include +#include #include #include #include @@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc) struct sysctl_oid *oidp; struct vfsops *vfsops; static int once; + struct vfsconf *tvfc; + uint32_t hashval; if (!once) { vattr_null(&va_null); @@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc) if (vfs_byname(vfc->vfc_name) != NULL) return EEXIST; - vfc->vfc_typenum = maxvfsconf++; + /* + * Calculate a hash on vfc_name to use for vfc_typenum. Unless + * a collision occurs, it is limited to 8bits since that is + * what ZFS uses from vfc_typenum and that also limits how sparsely + * distributed vfc_typenum becomes. + */ + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); + hashval &= 0xff; + do { + /* Look for and fix any collision. */ + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { + if (hashval == tvfc->vfc_typenum) { + hashval++; /* Can exceed 8bits, if needed. */ + break; + } + } + } while (tvfc != NULL); + vfc->vfc_typenum = hashval; + if (vfc->vfc_typenum >= maxvfsconf) + maxvfsconf = vfc->vfc_typenum + 1; TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); /* From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 21:17:21 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A9E4106564A for ; Wed, 24 Aug 2011 21:17:21 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id B1A6D8FC13 for ; Wed, 24 Aug 2011 21:17:20 +0000 (UTC) X-AuditID: 12074424-b7bcaae000000a05-0c-4e556a8bcf08 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.17.02565.B8A655E4; Wed, 24 Aug 2011 17:18:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p7OLHJt8006928; Wed, 24 Aug 2011 17:17:19 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7OLHHxt001649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 17:17:19 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7OLHHf2026706; Wed, 24 Aug 2011 17:17:17 -0400 (EDT) Date: Wed, 24 Aug 2011 17:17:17 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrdudFepnsO8zp8WEKz+YLB4uu8bk wOQx49N8Fo/fm/cyBTBFcdmkpOZklqUW6dslcGUse9PEVtAlWtF58SZ7A+MxgS5GTg4JAROJ T5+fs0LYYhIX7q1n62Lk4hAS2McoMaXjChOEs4FR4u2OhYwQzgEmie1TXrNAOA2MEs8PbmcB 6WcR0Jb4cPMWG4jNJqAiMfPNRjBbREBdYvPqfmYQm1lAXOLJ7Xdg+4QFFCQm3F3HBGJzCvhL NH16A2bzCjhIrLx4DaxXSMBPYmL/IrD5ogI6Eqv3T2GBqBGUODnzCQvETEuJc3+us01gFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoGBld1HZwdh8SOkQ owAHoxIP7wWHUD8h1sSy4srcQ4ySHExKorwrM4FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhP nQvxE+JNSaysSi3Kh0lJc7AoifPa7HTwExJITyxJzU5NLUgtgsnKcHAoSfBuBhkqWJSanlqR lplTgpBm4uAEGc4DNDwVpIa3uCAxtzgzHSJ/ilFRSpz3KEhCACSRUZoH1wtLJq8YxYFeEeZd AFLFA0xEcN2vgAYzAQ3m+BUEMrgkESEl1cCoePiCwiNWg937inUV2C4/f5hV9HbGRTPHmV4h KauUakTeqKsLvo0umtTdGJlv4DTP2UJY/2aYt1bduq0KfFW6sxVtHu/r3rPpcPmNeU8LCj8p cbxXU1zuLxnI+eOT6Uerxatueu0u2vDDLiun5Ntk1vh3k1lLRQ/9ON7AWPfv3f6Xx+rcX9so sRRnJBpqMRcVJwIAOs0FwwEDAAA= Cc: current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:17:21 -0000 On Wed, 24 Aug 2011, Rick Macklem wrote: > "afs" The current OpenAFS codebase uses the all-caps "AFS". Judging by the omitted text, perhaps this should change. (We also don't use VFS_SET to set it, which I filed a bug about.) > > and here is my current rendition of the patch. (I took Gleb's suggestion > and switched to fnv_32_str(). I'll leave it that way unless there is a > collision after adding any names people post to the above list.) > > It sounds like people have agreed that this is a reasonable solution. > If hrs@ can confirm that testing shows it fixes the original problem > (the ZFS file handles don't change when it's loaded at different times), > I'll pass it along to re@. > > Thanks for the helpful suggestions, rick > > --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 > +++ kern/vfs_init.c 2011-08-24 16:15:24.000000000 -0400 > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in > > #include > #include > +#include > #include > #include > #include > @@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc) > struct sysctl_oid *oidp; > struct vfsops *vfsops; > static int once; > + struct vfsconf *tvfc; > + uint32_t hashval; > > if (!once) { > vattr_null(&va_null); > @@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc) > if (vfs_byname(vfc->vfc_name) != NULL) > return EEXIST; > > - vfc->vfc_typenum = maxvfsconf++; > + /* > + * Calculate a hash on vfc_name to use for vfc_typenum. Unless > + * a collision occurs, it is limited to 8bits since that is > + * what ZFS uses from vfc_typenum and that also limits how sparsely > + * distributed vfc_typenum becomes. > + */ > + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); > + hashval &= 0xff; > + do { > + /* Look for and fix any collision. */ > + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { > + if (hashval == tvfc->vfc_typenum) { > + hashval++; /* Can exceed 8bits, if needed. */ If we're confident that we won't ever fully fill the hash table, I would think that this should wrap around back to zero (or one?) instead of overflowing. Do we need to care about something attempting to add the same vfc_name twice? This code will happily add a second entry at the next available index. > + break; > + } > + } > + } while (tvfc != NULL); > + vfc->vfc_typenum = hashval; > + if (vfc->vfc_typenum >= maxvfsconf) > + maxvfsconf = vfc->vfc_typenum + 1; I guess we're holding off on killing maxvfsconf until after 9.0 is out? -Ben > TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); > > /* > > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 24 21:28:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96008106564A; Wed, 24 Aug 2011 21:28:42 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6468FC0A; Wed, 24 Aug 2011 21:28:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p7OLSg6a059113; Wed, 24 Aug 2011 21:28:42 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p7OLSg1k059112; Wed, 24 Aug 2011 21:28:42 GMT (envelope-from jwd) Date: Wed, 24 Aug 2011 21:28:42 +0000 From: John To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20110824212842.GA50140@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: F_RDLCK lock to FreeBSD NFS server fails to R/O target file X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:28:42 -0000 Hi Fellow NFS'ers, I believe I have found the problem we've been having with read locks while attaching to a FreeBSD NFS server. In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there is a call to VOP_ACCESS() as follows: /* * Check cred. */ NLM_DEBUG(3, "nlm_get_vfs_state(): Calling VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); if (error) { NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s VOP_ACCESS() returns %d\n", host->nh_caller_name, error); goto out; } The file being accessed is read only to the user, and open()ed with O_RDONLY. The lock being requested is for a read. fd = open(filename, O_RDONLY, 0); ... lblk.l_type = F_RDLCK; lblk.l_start = 0; lblk.l_whence= SEEK_SET; lblk.l_len = 0; lblk.l_pid = 0; rc = fcntl(fd, F_SETLK, &lblk); Running the above from a remote system, the lock call fails with errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is my uid on the remote system. Since the file is R/O to me, and the VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, Permission denied. The above operations work correctly to some of our other favorite big-name nfs vendors :-) Opinions on the "correct" way to fix this? 1. Since we're only asking for a read lock, why do we need to ask for VWRITE? I may not understand an underlying requirement for the VWRITE so please feel free to educate me if needed. Something like: request == F_RDLCK ? VREAD : VWRITE (need to figure out where to get the request from in this context). 2. Attempt VWRITE, fallback to VREAD... seems off to me though. 3. Other? I appreciate any thoughts on this. Thanks, John While they might not follow style(9) completely, I've uploaded my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. I'd appreciate it if someone would consider committing them so who ever debugs this file next will have them available. http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 00:38:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18D9106564A for ; Thu, 25 Aug 2011 00:38:53 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 778F58FC13 for ; Thu, 25 Aug 2011 00:38:53 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p7P0Jg5q013528 for ; Wed, 24 Aug 2011 20:19:42 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Wed, 24 Aug 2011 20:19:42 -0400 (EDT) Date: Wed, 24 Aug 2011 20:19:42 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 00:38:53 -0000 Hello, I have an older Dell 4150 laptop that takes forever to build world, so I don't update it that often. The last time I updated it was March 1, 2010. I just updated the system yesterday and ath0 (a Linksys PCCard) no longer attaches. The interesting thing is that ath0 is detected at different addresses between the working kernel and the non-working kernel: March 1, 2010 kernel -------------------- ath0: mem 0x88000000-0x8800ffff irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: AR5212 mac 5.9 RF5112 phy 4.3 Aug 23, 2011 kernel ------------------- ath0: mem 0xf8f10000-0xf8f1ffff irq 11 at device 0.0 on cardbus0 I've tried forcing successful returns from ar5212SetPowerModeAwake() and ar5212SetResetReg() but it doesn't help (diffs below). Any suggestions on how to get this to work? Full dmesg from working and non-working kernels at http://people.freebsd.org/~deischen/ath/ath.dmesg -- DE [deischen@orion /usr/src/sys/dev/ath]$ svn diff Index: ath_hal/ar5212/ar5212_reset.c =================================================================== --- ath_hal/ar5212/ar5212_reset.c (revision 225101) +++ ath_hal/ar5212/ar5212_reset.c (working copy) @@ -1145,7 +1145,8 @@ /* track PHY power state so we don't try to r/w BB registers */ AH5212(ah)->ah_phyPowerOn = ((resetMask & AR_RC_BB) == 0); - return rt; +// return rt; + return AH_TRUE; } int16_t Index: ath_hal/ar5212/ar5212_power.c =================================================================== --- ath_hal/ar5212/ar5212_power.c (revision 225101) +++ ath_hal/ar5212/ar5212_power.c (working copy) @@ -77,7 +77,9 @@ ath_hal_printf(ah, "%s: Failed to wakeup in %ums\n", __func__, POWER_UP_TIME/50); #endif +#if 0 return AH_FALSE; +#endif } } -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 04:49:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40636106566B; Thu, 25 Aug 2011 04:49:11 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE6CA8FC08; Thu, 25 Aug 2011 04:49:10 +0000 (UTC) Received: by vxh11 with SMTP id 11so1800266vxh.13 for ; Wed, 24 Aug 2011 21:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=gLxXKwQAS9vXAaANtbgALVtCafTMwM4VwmDRwT8Dt1A=; b=MaM/SsqIbqoCzljGblZviV+KVxG8IIxN4OGHATAOLryxCJm8ijuROiIJ+b4ESOaB4k UszqAsbR3aNdHqK5AFqwZL4MiACLUHcUrDYn9cgvFkJx/YObbXBG3MjYEUNJ50d1QgjR 2nF6meRQereCA9KJrU9S7+mcFsvTyQX9Xgdxc= MIME-Version: 1.0 Received: by 10.52.173.111 with SMTP id bj15mr5357293vdc.46.1314247750019; Wed, 24 Aug 2011 21:49:10 -0700 (PDT) Received: by 10.224.19.131 with HTTP; Wed, 24 Aug 2011 21:49:09 -0700 (PDT) Date: Wed, 24 Aug 2011 21:49:09 -0700 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: if_ath - should it be compiled without ath_hal support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 04:49:11 -0000 I ran into the panic shown below because it appears that some array indexing went off into the weeds. I haven't seen this happen but once though when running a buildworld last night using r225089 on i386. This begs the question - is it wise to compile if_ath without ath_hal support today? I've been doing this recently because ath_hal isn't available under /sys/modules , and unless I unload the module, things like suspend and resume don't work because if_ath doesn't support suspend/resume yet). There are a lot of references to the ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as well which concern me.. TIA! -Garrett Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc5ec97f0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0c58968 stack pointer = 0x28:0xd87e2bfc frame pointer = 0x28:0xd87e2c78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (ath0 taskq) Physical memory: 1001 MB Dumping 103 MB: 88 72 56 40 24 8 ... (kgdb) list 3659 m->m_pkthdr.rcvif = ifp; 3660 m->m_pkthdr.len = len; 3661 } 3662 3663 ifp->if_ipackets++; 3664 sc->sc_stats.ast_ant_rx[rs->rs_antenna]++; 3665 3666 /* 3667 * Populate the rx status block. When there are bpf 3668 * listeners we do the additional work to provide (kgdb) p sc->sc_stats.ast_ant_rx $6 = {0, 3458, 0, 0, 0, 0, 0, 0} (kgdb) p rs->rs_antenna $7 = 8399232 (kgdb) From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 05:32:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFC01065673 for ; Thu, 25 Aug 2011 05:32:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1509D8FC1B for ; Thu, 25 Aug 2011 05:32:30 +0000 (UTC) Received: by gyd10 with SMTP id 10so1712798gyd.13 for ; Wed, 24 Aug 2011 22:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=85HwFHQCuNUEW01DE3LlWDV2IvWlgFAIR9v1P7zYZn0=; b=FV2Ybp/Q6bIwk6eEbmcKsw1norY5cWvELJcn+FO2nSIsYk0243gAdCm0CdzHEZQOHl Usp5SJkRTBUdpfZE3YVPihaNC3niXpnSUPxsxOqR8dn+TCTKAcZDdEO7syGGT4R9bZxY /y/nmBofr3ujS4GuQ7tTOVjs8PXIb7LLrfVPI= MIME-Version: 1.0 Received: by 10.151.42.16 with SMTP id u16mr371023ybj.372.1314250350348; Wed, 24 Aug 2011 22:32:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Wed, 24 Aug 2011 22:32:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Aug 2011 13:32:30 +0800 X-Google-Sender-Auth: Irmezu24R2aPuI_v6nfLz32gAps Message-ID: From: Adrian Chadd To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 05:32:31 -0000 On 25 August 2011 08:19, Daniel Eischen wrote: > I have an older Dell 4150 laptop that takes forever to build > world, so I don't update it that often. =A0The last time I > updated it was March 1, 2010. =A0I just updated the system > yesterday and ath0 (a Linksys PCCard) no longer attaches. > > The interesting thing is that ath0 is detected at different > addresses between the working kernel and the non-working > kernel: [snip] Yup, looks like another cardbus/pci allocation issue. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 05:37:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE1BE106564A for ; Thu, 25 Aug 2011 05:37:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB9A8FC16 for ; Thu, 25 Aug 2011 05:37:19 +0000 (UTC) Received: by gyd10 with SMTP id 10so1715321gyd.13 for ; Wed, 24 Aug 2011 22:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v+idLQLoHkDomB4FsY2o08HH3287EM55RkAJV9twGCw=; b=VXKlbQ5iPP+9GK2uBWEwVWY2t3EX2c+2LXSz8NRjmqNG+F+TQMsPXk6yO4ZE8F+8YV OLi3XQkgp4A0gc2F1Wxa7QrtzdW8arRXHtFqlDXapxVn9oXe17jh9PqP7Crqj3rZF2NI LwnKasj85mswL22tg3eIvkMezwpjDu7ggHB1w= MIME-Version: 1.0 Received: by 10.150.238.17 with SMTP id l17mr395037ybh.144.1314250638711; Wed, 24 Aug 2011 22:37:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Wed, 24 Aug 2011 22:37:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Aug 2011 13:37:18 +0800 X-Google-Sender-Auth: Rw9PcFVGFzb-pEUilAmO9EdDHyo Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: if_ath - should it be compiled without ath_hal support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 05:37:19 -0000 Hi, On 25 August 2011 12:49, Garrett Cooper wrote: > =A0 =A0I ran into the panic shown below because it appears that some > array indexing went off into the weeds. I haven't seen this happen but > once though when running a buildworld last night using r225089 on > i386. > =A0 =A0This begs the question - is it wise to compile if_ath without > ath_hal support today? I've been doing this recently because ath_hal > isn't available under /sys/modules , and unless I unload the module, > things like suspend and resume don't work because if_ath doesn't > support suspend/resume yet). There are a lot of references to the > ath_hal APIs in if_ath.c now that don't have #ifdefs guarding them as > well which concern me.. Well, the ath_hal code should be built in as part of the ath module. ath needs ath_hal to speak to the MAC/baseband/radio. There's no need for #ifdef's to guard them as .. well, they're needed. I'd like to eventually split out the ath_hal again into a separate module and re-instate the separation between HAL and driver code (primarily to enforce cleaner code and more stable APIs.) If you're seeing issues like the above, chances are that you're seeing some corruption. Can you please print out the whole value of *rs (ie, all the fields of the ath_rx_status struct) so I can see how valid it is? Adrian From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 07:50:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01981106566B for ; Thu, 25 Aug 2011 07:50:13 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id B6F6F8FC0A for ; Thu, 25 Aug 2011 07:50:12 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p7P7oBvd017947; Thu, 25 Aug 2011 03:50:11 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Thu, 25 Aug 2011 03:50:11 -0400 (EDT) Date: Thu, 25 Aug 2011 03:50:11 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Adrian Chadd In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1314258611=:26304" Cc: current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 07:50:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1314258611=:26304 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 25 Aug 2011, Adrian Chadd wrote: > On 25 August 2011 08:19, Daniel Eischen wrote: > >> I have an older Dell 4150 laptop that takes forever to build >> world, so I don't update it that often. =A0The last time I >> updated it was March 1, 2010. =A0I just updated the system >> yesterday and ath0 (a Linksys PCCard) no longer attaches. >> >> The interesting thing is that ath0 is detected at different >> addresses between the working kernel and the non-working >> kernel: > > [snip] > > Yup, looks like another cardbus/pci allocation issue. :-) Who do I ping about it? I tried with "nooption NEW_PCIB" but that didn't work either. --=20 DE ---559023410-851401618-1314258611=:26304-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 08:22:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B8341065676; Thu, 25 Aug 2011 08:22:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1972C8FC15; Thu, 25 Aug 2011 08:22:20 +0000 (UTC) Received: by gyd10 with SMTP id 10so1814982gyd.13 for ; Thu, 25 Aug 2011 01:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fMBw8XWoO8sLQhSx74FJkS4lHe8hgJXmbvUdL62vLa4=; b=mThwC7/Zf/7cJD/PT70kN7nZu7+RsH5gvrlKR02DdPsP7GwUom7qmlLwNgOlYp7vWA syP713nywfBSCMufEDgKM/51ka0nZMpXeMkfietqM7DGVLE55suNysFjUGBtuZ5hto8O fx59+FOcPaZLktsd39C2T+JAufcKF6vIArVJ0= MIME-Version: 1.0 Received: by 10.150.229.12 with SMTP id b12mr593002ybh.30.1314260540411; Thu, 25 Aug 2011 01:22:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Thu, 25 Aug 2011 01:22:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Aug 2011 16:22:20 +0800 X-Google-Sender-Auth: uTgNk77xRjxzBDqZfc77UBFQrm8 Message-ID: From: Adrian Chadd To: Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 08:22:21 -0000 On 25 August 2011 15:50, Daniel Eischen wrote: >> [snip] >> >> Yup, looks like another cardbus/pci allocation issue. :-) > > Who do I ping about it? =A0I tried with "nooption NEW_PCIB" > but that didn't work either. Whoever looks after the cardbus/pci code? I know you don't want to, but it may be worthwhile bisecting the kernel version (as booting alone is enough to see if it's working, so you don't have to build a whole world each time) and figure out when it broke. I bet that'll be a big, big help. I'd appreciate it too, you're not the first user who has a non-functioning ath cardbus nic, and I'd really like to see those resolved for 9.0. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 10:01:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E21F1065673; Thu, 25 Aug 2011 10:01:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 287528FC13; Thu, 25 Aug 2011 10:01:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p7PA11In083228; Thu, 25 Aug 2011 06:01:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p7PA11qd083222; Thu, 25 Aug 2011 10:01:01 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 25 Aug 2011 10:01:01 GMT Message-Id: <201108251001.p7PA11qd083222@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 10:01:02 -0000 TB --- 2011-08-25 10:00:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-08-25 10:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-08-25 10:00:00 - cleaning the object tree TB --- 2011-08-25 10:00:35 - cvsupping the source tree TB --- 2011-08-25 10:00:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-08-25 10:00:51 - building world TB --- 2011-08-25 10:00:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-08-25 10:00:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-08-25 10:00:51 - TARGET=pc98 TB --- 2011-08-25 10:00:51 - TARGET_ARCH=i386 TB --- 2011-08-25 10:00:51 - TZ=UTC TB --- 2011-08-25 10:00:51 - __MAKE_CONF=/dev/null TB --- 2011-08-25 10:00:51 - cd /src TB --- 2011-08-25 10:00:51 - /usr/bin/make -B buildworld >>> World build started on Thu Aug 25 10:00:53 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] mkdep -f .depend -a -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -I/obj/pc98.i386/src/tmp/legacy/usr/include /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSInt.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allocator.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Atomic.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/BranchProbability.cpp /src/lib/clang/libllvmsupport/../../../contri! b/llvm/lib/Support/CommandLine.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConstantRange.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CrashRecoveryContext.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGDeltaAlgorithm.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DeltaAlgorithm.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DynamicLibrary.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Errno.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ErrorHandling.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FoldingSet.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FormattedStream.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support! /GraphWriter.cpp /src/lib/clang/libllvmsupport/../../../contri! b/llvm/lib/Support/Host.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IntervalMap.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IntEqClasses.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ManagedStatic.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Memory.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/MemoryBuffer.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Mutex.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Path.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PathV2.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PluginLoader.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PrettyStackTrace.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Process.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Program.cpp /src/lib/clang/libllv! msupport/../../../contrib/llvm/lib/Support/RWMutex.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Regex.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SearchForAddressOfSpecialSymbol.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Signals.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SmallPtrSet.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SmallVector.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SourceMgr.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Statistic.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringExtras.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringMap.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringPool.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringRef.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm! /lib/Support/TargetRegistry.cpp /src/lib/clang/libllvmsupport/../../../! contrib/llvm/lib/Support/ThreadLocal.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Threading.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/TimeValue.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Timer.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ToolOutputFile.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Triple.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Twine.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Valgrind.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/circular_raw_ostream.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_os_ostream.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_ostream.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/system_error.cpp c++ -O2 -pipe -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -c /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp c++ -O2 -pipe -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -c /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp: In member function 'llvm::APInt::ms llvm::APInt::magic() const': /src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp:1478: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/lib/clang/libllvmsupport. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-08-25 10:01:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-08-25 10:01:01 - ERROR: failed to build world TB --- 2011-08-25 10:01:01 - 7.84 user 17.94 system 60.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 13:45:44 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BA9106566C; Thu, 25 Aug 2011 13:45:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0EF8FC08; Thu, 25 Aug 2011 13:45:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 34A9E46B06; Thu, 25 Aug 2011 09:45:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A19BD8A02F; Thu, 25 Aug 2011 09:45:43 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Daniel Eischen Date: Thu, 25 Aug 2011 09:40:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; 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: <201108250940.44847.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 25 Aug 2011 09:45:43 -0400 (EDT) Cc: current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:45:44 -0000 On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: > Hello, > > I have an older Dell 4150 laptop that takes forever to build > world, so I don't update it that often. The last time I > updated it was March 1, 2010. I just updated the system > yesterday and ath0 (a Linksys PCCard) no longer attaches. > > The interesting thing is that ath0 is detected at different > addresses between the working kernel and the non-working > kernel: > > March 1, 2010 kernel > -------------------- > ath0: mem 0x88000000-0x8800ffff irq 11 > at device 0.0 on cardbus0 > ath0: [ITHREAD] > ath0: AR5212 mac 5.9 RF5112 phy 4.3 > > > Aug 23, 2011 kernel > ------------------- > ath0: mem 0xf8f10000-0xf8f1ffff irq 11 > at device 0.0 on cardbus0 > > > I've tried forcing successful returns from > ar5212SetPowerModeAwake() and ar5212SetResetReg() > but it doesn't help (diffs below). > > Any suggestions on how to get this to work? > Full dmesg from working and non-working kernels at > > http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 13:45:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BA9106566C; Thu, 25 Aug 2011 13:45:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0EF8FC08; Thu, 25 Aug 2011 13:45:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 34A9E46B06; Thu, 25 Aug 2011 09:45:44 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A19BD8A02F; Thu, 25 Aug 2011 09:45:43 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, Daniel Eischen Date: Thu, 25 Aug 2011 09:40:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; 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: <201108250940.44847.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 25 Aug 2011 09:45:43 -0400 (EDT) Cc: current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:45:44 -0000 On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: > Hello, > > I have an older Dell 4150 laptop that takes forever to build > world, so I don't update it that often. The last time I > updated it was March 1, 2010. I just updated the system > yesterday and ath0 (a Linksys PCCard) no longer attaches. > > The interesting thing is that ath0 is detected at different > addresses between the working kernel and the non-working > kernel: > > March 1, 2010 kernel > -------------------- > ath0: mem 0x88000000-0x8800ffff irq 11 > at device 0.0 on cardbus0 > ath0: [ITHREAD] > ath0: AR5212 mac 5.9 RF5112 phy 4.3 > > > Aug 23, 2011 kernel > ------------------- > ath0: mem 0xf8f10000-0xf8f1ffff irq 11 > at device 0.0 on cardbus0 > > > I've tried forcing successful returns from > ar5212SetPowerModeAwake() and ar5212SetResetReg() > but it doesn't help (diffs below). > > Any suggestions on how to get this to work? > Full dmesg from working and non-working kernels at > > http://people.freebsd.org/~deischen/ath/ath.dmesg You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a test. If that doesn't work, a verbose dmesg from the broken case as well as devinfo -u and devinfo -r output from the working and broken cases would be most useful. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 13:51:59 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CA0C106564A for ; Thu, 25 Aug 2011 13:51:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id EC23F8FC13 for ; Thu, 25 Aug 2011 13:51:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKdSVk6DaFvO/2dsb2JhbABCDoQ+pCyBQAEBAQECAQEBASAEJyALBRYYAgINGQIpAQkmBggHBAEaAgSHUQSpGpFZgSyED4ERBJEJghCQQ1Q X-IronPort-AV: E=Sophos;i="4.68,281,1312171200"; d="scan'208";a="132206459" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Aug 2011 09:51:57 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8DC0AB3F52; Thu, 25 Aug 2011 09:51:57 -0400 (EDT) Date: Thu, 25 Aug 2011 09:51:57 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <2096772200.330408.1314280317504.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:51:59 -0000 Benjamin Kaduk wrote: > On Wed, 24 Aug 2011, Rick Macklem wrote: > > > "afs" > > The current OpenAFS codebase uses the all-caps "AFS". Judging by the > omitted text, perhaps this should change. (We also don't use VFS_SET > to > set it, which I filed a bug about.) > > > > > and here is my current rendition of the patch. (I took Gleb's > > suggestion > > and switched to fnv_32_str(). I'll leave it that way unless there is > > a > > collision after adding any names people post to the above list.) > > > > It sounds like people have agreed that this is a reasonable > > solution. > > If hrs@ can confirm that testing shows it fixes the original problem > > (the ZFS file handles don't change when it's loaded at different > > times), > > I'll pass it along to re@. > > > > Thanks for the helpful suggestions, rick > > > > --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 > > +++ kern/vfs_init.c 2011-08-24 16:15:24.000000000 -0400 > > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in > > > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -138,6 +139,8 @@ vfs_register(struct vfsconf *vfc) > > struct sysctl_oid *oidp; > > struct vfsops *vfsops; > > static int once; > > + struct vfsconf *tvfc; > > + uint32_t hashval; > > > > if (!once) { > > vattr_null(&va_null); > > @@ -152,7 +155,26 @@ vfs_register(struct vfsconf *vfc) > > if (vfs_byname(vfc->vfc_name) != NULL) > > return EEXIST; > > > > - vfc->vfc_typenum = maxvfsconf++; > > + /* > > + * Calculate a hash on vfc_name to use for vfc_typenum. Unless > > + * a collision occurs, it is limited to 8bits since that is > > + * what ZFS uses from vfc_typenum and that also limits how sparsely > > + * distributed vfc_typenum becomes. > > + */ > > + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); > > + hashval &= 0xff; > > + do { > > + /* Look for and fix any collision. */ > > + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { > > + if (hashval == tvfc->vfc_typenum) { > > + hashval++; /* Can exceed 8bits, if needed. */ > > If we're confident that we won't ever fully fill the hash table, I > would > think that this should wrap around back to zero (or one?) instead of > overflowing. > I did it that way so that it could overflow for the highly unlikely case of more than 255 file system types. I suppose I should scan for an unused value 1<->255 and only allow it to go past 255 if all of them are used. I'll post yet another patch soon, rick > Do we need to care about something attempting to add the same vfc_name > twice? This code will happily add a second entry at the next available > index. > > > + break; > > + } > > + } > > + } while (tvfc != NULL); > > + vfc->vfc_typenum = hashval; > > + if (vfc->vfc_typenum >= maxvfsconf) > > + maxvfsconf = vfc->vfc_typenum + 1; > > I guess we're holding off on killing maxvfsconf until after 9.0 is > out? > > -Ben > > > TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); > > > > /* > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 15:18:22 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF251065672 for ; Thu, 25 Aug 2011 15:18:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 789508FC0C for ; Thu, 25 Aug 2011 15:18:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJ5mVk6DaFvO/2dsb2JhbABCDoQ+pC2BQAEBBAEjBFIFFhgCAg0ZAlkGiAWpH5FVgSyED4ERBJMZkENU X-IronPort-AV: E=Sophos;i="4.68,281,1312171200"; d="scan'208";a="132220468" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Aug 2011 11:18:21 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6CA16B3F3E; Thu, 25 Aug 2011 11:18:21 -0400 (EDT) Date: Thu, 25 Aug 2011 11:18:21 -0400 (EDT) From: Rick Macklem To: Benjamin Kaduk Message-ID: <1252487773.337126.1314285501432.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:18:22 -0000 Benjamin Kaduk wrote: > > If we're confident that we won't ever fully fill the hash table, I > would > think that this should wrap around back to zero (or one?) instead of > overflowing. > Here's my updated patch (it will wrap to 1 the first time and then exceed 255 if 1<->255 are all in use). --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 +++ kern/vfs_init.c 2011-08-25 11:09:14.000000000 -0400 @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in #include #include +#include #include #include #include @@ -138,6 +139,9 @@ vfs_register(struct vfsconf *vfc) struct sysctl_oid *oidp; struct vfsops *vfsops; static int once; + struct vfsconf *tvfc; + uint32_t hashval; + int secondpass; if (!once) { vattr_null(&va_null); @@ -152,7 +156,31 @@ vfs_register(struct vfsconf *vfc) if (vfs_byname(vfc->vfc_name) != NULL) return EEXIST; - vfc->vfc_typenum = maxvfsconf++; + /* + * Calculate a hash on vfc_name to use for vfc_typenum. Unless + * all of 1<->255 are assigned, it is limited to 8bits since that is + * what ZFS uses from vfc_typenum and is also the preferred range + * for vfs_getnewfsid(). + */ + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); + hashval &= 0xff; + secondpass = 0; + do { + /* Look for and fix any collision. */ + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { + if (hashval == tvfc->vfc_typenum) { + if (hashval == 255 && secondpass == 0) { + hashval = 1; + secondpass = 1; + } else + hashval++; + break; + } + } + } while (tvfc != NULL); + vfc->vfc_typenum = hashval; + if (vfc->vfc_typenum >= maxvfsconf) + maxvfsconf = vfc->vfc_typenum + 1; TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); /* > Do we need to care about something attempting to add the same vfc_name > twice? This code will happily add a second entry at the next available > index. > If file systems use VFS_SET(), I don't think this can happen, since the same vfc_name would imply "same module name" and the 2nd one wouldn't load. (Been there, w.r.t. nfs.) > > + break; > > + } > > + } > > + } while (tvfc != NULL); > > + vfc->vfc_typenum = hashval; > > + if (vfc->vfc_typenum >= maxvfsconf) > > + maxvfsconf = vfc->vfc_typenum + 1; > > I guess we're holding off on killing maxvfsconf until after 9.0 is > out? Well, I still don't know if anything has a use for vfs_sysctl(), so I'm not volunteering to take it out. (If others feel it should come out for 9.0, maybe... But I would still consider that a separate patch.) rick From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 15:41:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D151065672 for ; Thu, 25 Aug 2011 15:41:29 +0000 (UTC) (envelope-from labeachgeek@gmail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id 926858FC08 for ; Thu, 25 Aug 2011 15:41:28 +0000 (UTC) Received: by eye4 with SMTP id 4so1543916eye.31 for ; Thu, 25 Aug 2011 08:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=o2rP5nlBjmocbg7Tydp0cpS0Rlx7GCAxzhnNhjIsww0=; b=D1A+MOZqx4tnM2iWNeAfPJcQHuCuAmYwoMEwUk3HKAEt/vQm1Iznnar+PtMMoxViOb Y5ZuNOzacLc+YiDSQ4s05fBIU3v33bMkAsZMpT6IrcWPtQ3gc62DmbBb+WQCDzsiAxVa zXQ46bEjUit+o0AeN6r1RGXBAw7Q/yO0FJZao= MIME-Version: 1.0 Received: by 10.213.35.195 with SMTP id q3mr429594ebd.5.1314285145756; Thu, 25 Aug 2011 08:12:25 -0700 (PDT) Received: by 10.213.105.75 with HTTP; Thu, 25 Aug 2011 08:12:25 -0700 (PDT) Date: Thu, 25 Aug 2011 10:12:25 -0500 Message-ID: From: Beach Geek To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: buildworld failure r223619 to 225128 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:41:29 -0000 make buildworld failed trying to upgrade from r223619 to r225128. (Note: Updating other boxes from r224774 to r225119 went flawless) On failing laptop (Toshibs Sat C655D) uname -v FreeBSD 9.0-CURRENT #0 r223619 Tue Jun 28 CDT 2011 ... svn info /usr/src URL: svn.freebsd.org/base/head ... Revision: 225128 ... Last changed Rev:225125 Last changed Date: 2011-08-23 // Begin last part of "make buildworld" ouput (by hand) In file included from /usr/include/c++/4.2/string:50, from /usr/src/lib/clang/libllvmsupport/../ ../../contrib/llvm/include/llvm/Support/DOTGraphTraits.h:20, from /usr/src/lib/clang/libllvmsupport/../ ../../contrib/llvm/Support/GraphWriter.h:26, from /usr/src/lib/clang/libllvmsupport/../ ../../contrib/llvm/lib/Support/GraphWriter.cpp:14: /usr/include/c++/4.2/bits/basic_string.tcc:979: instantiated from here /usr/include/c++/4.2/bits/stringfwd.h:56: internal compiler error: Segmentation fault: 11 Please submit full report, ... ... *** Error code 1 Stop in /usr/src/lib/clang/libllvmsupport. *** Error code 1 Stop in /usr/src. *** Error code 1 (above 2 lines repeated twice) // End of output. I do "rm -r /usr/obj/*" and make clean (in /usr/src) before doing buildworld on all boxes. I also tried compiling new GENERIC kernel then doing buildworld. It failed with same message. Reverted to old/original kernel and tried "make depend" in /usr/src. It failed with... (by hand again) ===> lib/clang/libllvmarmasmparser (depend) tblgen -l /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target -gen-asm-matcher -o ARMGenAsm Matcher.inc.h /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM/ARM.td tblgen: Record 'CCR', field 'MemberList' does not have a list initializer! *** Error code 1 Stop in /usr/src/lib/clang/libllvmarmasmparser. I tried my best to make sure there are no typos. Any suggestions? I thought of 3 options... 1) update to r224774 first, then to r225119 (or r225128). To mimic other boxes. 2) build/install new kernel then "make depend" and then try buildworld. 3) find help from mailing list to fix this buildworld error. ;-)) Number 1 .... might work. Shot in the dark. Number 2 ... I'm already past r221543, so "make depend" shouldn't be required, and I'm not in that small version window that requires installing new kernel before buildworld. Number 3 .... email mailing list for help....tada!!! Any help or suggestions will be appreciated. Thanks, Beach Geek PS. If I missed a relevant post or link, please post link (and I'll sit in corner with hat) From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 15:53:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EA1106564A for ; Thu, 25 Aug 2011 15:53:01 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id 820818FC0C for ; Thu, 25 Aug 2011 15:53:01 +0000 (UTC) Received: by eye4 with SMTP id 4so1559223eye.31 for ; Thu, 25 Aug 2011 08:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=XmXd81QJQvWq3Ut9NDEyOjaNf/3jedDBwSV5/O+E44c=; b=tWY5ujLtrWnx8sX+HdpxrRiSswEPKNXpnMIWOM5CC4MZGX39Z/NRF1E65WeKcbAOdy lxkQ4KmjR1w1/ehDe6OQbc6gXVk8XbHo5bJAL4WDUT87hbBD7vriUhZG7XCq/lq0jIlh kMkxsN/zUMAD/APtUioSyv+OeVfIQ8Fafqh/8= MIME-Version: 1.0 Received: by 10.142.136.18 with SMTP id j18mr3548561wfd.284.1314287579690; Thu, 25 Aug 2011 08:52:59 -0700 (PDT) Received: by 10.68.66.106 with HTTP; Thu, 25 Aug 2011 08:52:59 -0700 (PDT) Date: Thu, 25 Aug 2011 15:52:59 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org, George Neville-Neil , "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Updating our TCP and socket sysctl values... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:53:02 -0000 > >> I believe it's time to up these values to something that's in line with higher speed > >> local networks, such as 10G. Perhaps it's time to move these to 2MB instead of 256K. > >> > >> Thoughts? > > > > > > This never happened, did it? Was there a reason? > > > > I went back and looked at the mail thread. I didn't see any strong objections > so I think you should commit this for 9.x. > > np@ did point out that nmbclusters also lags on modern hardware so consider upping > that at the same time. I thought Bruce's observation, in: http://lists.freebsd.org/pipermail/freebsd-arch/2011-March/011193.html that: "...there is an mostly-unrelated bufferbloat problem that is purely local. If you have a buffer that is larger than an Ln cache (or about half than), then actually using just a single buffer of that size guarantees thrashing of the Ln cache, so that almost every memory access is an Ln cache miss. Even with current hardware, a buffer of size 256K will thrash most L1 caches and a buffer of size a few MB will thrash most L2 caches." , and his suggestion for some sort of auto-tuning, deserve consideration. Are you going to address this problem (at least the L2 and higher cache thrashing), or give some suggestions for tuning in UPDATING and the relevant manpages? b. From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 17:21:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2768106564A for ; Thu, 25 Aug 2011 17:21:18 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 654AE8FC0A for ; Thu, 25 Aug 2011 17:21:18 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p7PHLHHE009932; Thu, 25 Aug 2011 13:21:17 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Thu, 25 Aug 2011 13:21:17 -0400 (EDT) Date: Thu, 25 Aug 2011 13:21:17 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201108250940.44847.jhb@freebsd.org> Message-ID: References: <201108250940.44847.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 17:21:18 -0000 On Thu, 25 Aug 2011, John Baldwin wrote: > On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: >> Hello, >> >> I have an older Dell 4150 laptop that takes forever to build >> world, so I don't update it that often. The last time I >> updated it was March 1, 2010. I just updated the system >> yesterday and ath0 (a Linksys PCCard) no longer attaches. >> >> The interesting thing is that ath0 is detected at different >> addresses between the working kernel and the non-working >> kernel: >> >> March 1, 2010 kernel >> -------------------- >> ath0: mem 0x88000000-0x8800ffff irq 11 >> at device 0.0 on cardbus0 >> ath0: [ITHREAD] >> ath0: AR5212 mac 5.9 RF5112 phy 4.3 >> >> >> Aug 23, 2011 kernel >> ------------------- >> ath0: mem 0xf8f10000-0xf8f1ffff irq 11 >> at device 0.0 on cardbus0 >> >> >> I've tried forcing successful returns from >> ar5212SetPowerModeAwake() and ar5212SetResetReg() >> but it doesn't help (diffs below). >> >> Any suggestions on how to get this to work? >> Full dmesg from working and non-working kernels at >> >> http://people.freebsd.org/~deischen/ath/ath.dmesg > > You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a > test. If that doesn't work, a verbose dmesg from the broken case as well as > devinfo -u and devinfo -r output from the working and broken cases would be > most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x88000000-0x8800ffff for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ There are verbose boots and devinfo -u/-r output for the working kernel and the non-working kernel (with and without debug.acpi.disable=hostres). Anything else you'd like me to try? -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 17:38:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A5A106564A; Thu, 25 Aug 2011 17:38:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D56BB8FC08; Thu, 25 Aug 2011 17:38:53 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p7PHLHHE009932; Thu, 25 Aug 2011 13:21:17 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Thu, 25 Aug 2011 13:21:17 -0400 (EDT) Date: Thu, 25 Aug 2011 13:21:17 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201108250940.44847.jhb@freebsd.org> Message-ID: References: <201108250940.44847.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 17:38:54 -0000 On Thu, 25 Aug 2011, John Baldwin wrote: > On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: >> Hello, >> >> I have an older Dell 4150 laptop that takes forever to build >> world, so I don't update it that often. The last time I >> updated it was March 1, 2010. I just updated the system >> yesterday and ath0 (a Linksys PCCard) no longer attaches. >> >> The interesting thing is that ath0 is detected at different >> addresses between the working kernel and the non-working >> kernel: >> >> March 1, 2010 kernel >> -------------------- >> ath0: mem 0x88000000-0x8800ffff irq 11 >> at device 0.0 on cardbus0 >> ath0: [ITHREAD] >> ath0: AR5212 mac 5.9 RF5112 phy 4.3 >> >> >> Aug 23, 2011 kernel >> ------------------- >> ath0: mem 0xf8f10000-0xf8f1ffff irq 11 >> at device 0.0 on cardbus0 >> >> >> I've tried forcing successful returns from >> ar5212SetPowerModeAwake() and ar5212SetResetReg() >> but it doesn't help (diffs below). >> >> Any suggestions on how to get this to work? >> Full dmesg from working and non-working kernels at >> >> http://people.freebsd.org/~deischen/ath/ath.dmesg > > You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a > test. If that doesn't work, a verbose dmesg from the broken case as well as > devinfo -u and devinfo -r output from the working and broken cases would be > most useful. Setting debug.acpi.disable=hostres did not work. Strange thing is that ath0 is now at mem 0x88000000-0x8800ffff for both working and non-working kernels (with and without debug.acpi.disable=hostres). ath0 still doesn't attach, but it seems funny that the memory address changes. These are all soft reboots, not hard reboots, after a working kernel. All the information you requested is here: http://people.freebsd.org/~deischen/ath/ There are verbose boots and devinfo -u/-r output for the working kernel and the non-working kernel (with and without debug.acpi.disable=hostres). Anything else you'd like me to try? -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 18:52:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 572C0106564A for ; Thu, 25 Aug 2011 18:52:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 19CD38FC1C for ; Thu, 25 Aug 2011 18:52:53 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:b536:379a:a51e:eaad] (unknown [IPv6:2001:7b8:3a7:0:b536:379a:a51e:eaad]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9D38A5C59; Thu, 25 Aug 2011 20:52:50 +0200 (CEST) Message-ID: <4E569A02.30206@FreeBSD.org> Date: Thu, 25 Aug 2011 20:52:50 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Beach Geek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: buildworld failure r223619 to 225128 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 18:52:53 -0000 On 2011-08-25 17:12, Beach Geek wrote: > make buildworld failed trying to upgrade from r223619 to r225128. > (Note: Updating other boxes from r224774 to r225119 went flawless) > > On failing laptop (Toshibs Sat C655D) .... > /usr/include/c++/4.2/bits/stringfwd.h:56: internal compiler error: > Segmentation fault: 11 > Please submit full report, That is most likely a hardware problem. Please run a full memtest, and/or any other hardware diagnostics you can find. It could also be running out of memory, but that is less likely, and you usually get another signal then. But who knows what might happen if you choke a compiler. :) > I do "rm -r /usr/obj/*" and make clean (in /usr/src) before doing > buildworld on all boxes. > I also tried compiling new GENERIC kernel then doing buildworld. It > failed with same message. It dies on exactly the same file? > Reverted to old/original kernel and tried "make depend" in /usr/src. You can't do that, you must run buildworld. > It failed with... (by hand again) > > ===> lib/clang/libllvmarmasmparser (depend) > tblgen -l /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM > -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/include > -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target > -gen-asm-matcher -o ARMGenAsm Matcher.inc.h > /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM/ARM.td > > tblgen: Record 'CCR', field 'MemberList' does not have a list initializer! > *** Error code 1 > Stop in /usr/src/lib/clang/libllvmarmasmparser. Yes, this is expected. When you do not use the buildworld target, the tblgen used above will be run from /usr/bin, which is too old. This is why buildworld first builds an up-to-date tblgen under /usr/obj, and uses that to generate the needed files. From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 20:31:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3026A106566B; Thu, 25 Aug 2011 20:31:52 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 04C678FC12; Thu, 25 Aug 2011 20:31:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p7PKVpgs080537; Thu, 25 Aug 2011 20:31:51 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p7PKVp3T080536; Thu, 25 Aug 2011 20:31:51 GMT (envelope-from jwd) Date: Thu, 25 Aug 2011 20:31:51 +0000 From: John To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20110825203151.GA61776@FreeBSD.org> References: <20110824212842.GA50140@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824212842.GA50140@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:31:52 -0000 After pondering the best way to allow the VOP_ACCESS() call to only query for the permissions really needed, I've come up with a patch that minimally adds one parameter to the nlm_get_vfs_state() function call with the lock type from the original argp. http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch I'd appreciate a review and seeing what might be required to commit this prior to 9 release. Thanks, John ----- John's Original Message ----- > Hi Fellow NFS'ers, > > I believe I have found the problem we've been having with read locks > while attaching to a FreeBSD NFS server. > > In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there is a call > to VOP_ACCESS() as follows: > > /* > * Check cred. > */ > NLM_DEBUG(3, "nlm_get_vfs_state(): Calling VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); > error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); > if (error) { > NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s VOP_ACCESS() returns %d\n", > host->nh_caller_name, error); > goto out; > } > > The file being accessed is read only to the user, and open()ed with > O_RDONLY. The lock being requested is for a read. > > fd = open(filename, O_RDONLY, 0); > ... > > lblk.l_type = F_RDLCK; > lblk.l_start = 0; > lblk.l_whence= SEEK_SET; > lblk.l_len = 0; > lblk.l_pid = 0; > rc = fcntl(fd, F_SETLK, &lblk); > > Running the above from a remote system, the lock call fails with > errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is > my uid on the remote system. Since the file is R/O to me, and the > VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, > Permission denied. > > The above operations work correctly to some of our other > favorite big-name nfs vendors :-) > > Opinions on the "correct" way to fix this? > > 1. Since we're only asking for a read lock, why do we need to ask > for VWRITE? I may not understand an underlying requirement for > the VWRITE so please feel free to educate me if needed. > > Something like: request == F_RDLCK ? VREAD : VWRITE > (need to figure out where to get the request from in this context). > > 2. Attempt VWRITE, fallback to VREAD... seems off to me though. > > 3. Other? > > I appreciate any thoughts on this. > > Thanks, > John > > While they might not follow style(9) completely, I've uploaded > my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. > I'd appreciate it if someone would consider committing them so > who ever debugs this file next will have them available. > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch > From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 21:30:45 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3541A106564A; Thu, 25 Aug 2011 21:30:45 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 519AF8FC12; Thu, 25 Aug 2011 21:30:42 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7PLUQ0I071784; Fri, 26 Aug 2011 06:30:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7PLUNk5062670; Fri, 26 Aug 2011 06:30:25 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 26 Aug 2011 06:30:17 +0900 (JST) Message-Id: <20110826.063017.934842008473299966.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> References: <20110824200813.GC1688@garage.freebsd.pl> <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Aug_26_06_30_17_2011_258)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 26 Aug 2011 06:30:38 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: kostikbel@gmail.com, pjd@FreeBSD.org, current@FreeBSD.org, kaduk@MIT.EDU Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:30:45 -0000 ----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in <468764384.310026.1314219682612.JavaMail.root@erie.cs.uoguelph.ca>: rm> Pawel Jakub Dawidek wrote: rm> > On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote: rm> > > On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote: rm> > > > Well, doesn't this result in the same issue as the fixed table? rm> > > > In other words, the developer has to supply the "suggested byte" rm> > > > for rm> > > > fsid and make sure that it doesn't conflict with other "suggested rm> > > > byte" rm> > > > values or suffer the same consequence as forgetting to update the rm> > > > fixed rm> > > > table. (ie. It just puts the fixed value in a different place, rm> > > > from what rm> > > > I see, for in-tree modules. Also, with a fixed table, they are all rm> > > > in rm> > > > one place, so it's easy to choose a non-colliding value?) rm> > > The reason for my proposal was Pawel note that a porter of the rm> > > filesystem rm> > > should be aware of some place in kern/ where to register, besides rm> > > writing rm> > > the module. rm> > rm> > Well, he has to be aware, but we should do all we can to minimize the rm> > number of place he needs to update, as it is easy to forget some. rm> > rm> > I agree with Rick that what you proposed is similar to fixed table of rm> > file system names and I'd prefer to avoid that. If we can have rm> > name-based hash that produces no collision for in-tree file systems rm> > and rm> > know current 3rd party file systems plus collision detection for the rm> > future then it is good enough, IMHO. And this is what Rick proposed rm> > with rm> > his patch. rm> > rm> Ok, here is the list of file system names I've been checking and there rm> haven't been any collisions (either hash function). If you know of other rm> well known file type names, please email and I'll add them to the list rm> and check for collisions again. rm> rm> "cd9660" rm> "ufs" rm> "procfs" rm> "devfs" rm> "msdosfs" rm> "nfs" rm> "xfs" rm> "reiserfs" rm> "tmpfs" rm> "hpfs" rm> "ntfs" rm> "ext2fs" rm> "udf" rm> "zfs" rm> "afs" rm> rm> and here is my current rendition of the patch. (I took Gleb's suggestion rm> and switched to fnv_32_str(). I'll leave it that way unless there is a rm> collision after adding any names people post to the above list.) rm> rm> It sounds like people have agreed that this is a reasonable solution. rm> If hrs@ can confirm that testing shows it fixes the original problem rm> (the ZFS file handles don't change when it's loaded at different times), rm> I'll pass it along to re@. Thank you! I will try the latest patch by Saturday. -- Hiroki ----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5WvukACgkQTyzT2CeTzy1MBwCgiwegt+ORXMY7/dz0GwP9v2k0 eKkAn1nlk7i8JUvvyTK+i0mE4huKcffa =Onxk -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Aug_26_06_30_17_2011_258)---- From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 22:09:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEAB0106564A; Thu, 25 Aug 2011 22:09:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3C98FC14; Thu, 25 Aug 2011 22:09:25 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p7PM9Ouq026546; Thu, 25 Aug 2011 18:09:24 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Thu, 25 Aug 2011 18:09:24 -0400 (EDT) Date: Thu, 25 Aug 2011 18:09:24 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: Message-ID: References: <201108250940.44847.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:09:26 -0000 On Thu, 25 Aug 2011, Daniel Eischen wrote: > On Thu, 25 Aug 2011, John Baldwin wrote: > >> On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: >>> Hello, >>> >>> I have an older Dell 4150 laptop that takes forever to build >>> world, so I don't update it that often. The last time I >>> updated it was March 1, 2010. I just updated the system >>> yesterday and ath0 (a Linksys PCCard) no longer attaches. >>> >>> The interesting thing is that ath0 is detected at different >>> addresses between the working kernel and the non-working >>> kernel: >>> >>> March 1, 2010 kernel >>> -------------------- >>> ath0: mem 0x88000000-0x8800ffff irq 11 >>> at device 0.0 on cardbus0 >>> ath0: [ITHREAD] >>> ath0: AR5212 mac 5.9 RF5112 phy 4.3 >>> >>> >>> Aug 23, 2011 kernel >>> ------------------- >>> ath0: mem 0xf8f10000-0xf8f1ffff irq 11 >>> at device 0.0 on cardbus0 >>> >>> >>> I've tried forcing successful returns from >>> ar5212SetPowerModeAwake() and ar5212SetResetReg() >>> but it doesn't help (diffs below). >>> >>> Any suggestions on how to get this to work? >>> Full dmesg from working and non-working kernels at >>> >>> http://people.freebsd.org/~deischen/ath/ath.dmesg >> >> You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a >> test. If that doesn't work, a verbose dmesg from the broken case as well >> as >> devinfo -u and devinfo -r output from the working and broken cases would be >> most useful. > > Setting debug.acpi.disable=hostres did not work. Strange thing is > that ath0 is now at mem 0x88000000-0x8800ffff for both working > and non-working kernels (with and without debug.acpi.disable=hostres). > ath0 still doesn't attach, but it seems funny that the memory > address changes. These are all soft reboots, not hard reboots, > after a working kernel. I removed all changes I made to src/sys/dev/ath/ and am now using the driver unchanged. ath0 is now back at mem 0xf8f10000-0xf8f1ffff. > All the information you requested is here: > > http://people.freebsd.org/~deischen/ath/ The devinfo and dmesg outputs have been updated in the above. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 22:09:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEAB0106564A; Thu, 25 Aug 2011 22:09:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3C98FC14; Thu, 25 Aug 2011 22:09:25 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p7PM9Ouq026546; Thu, 25 Aug 2011 18:09:24 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Thu, 25 Aug 2011 18:09:24 -0400 (EDT) Date: Thu, 25 Aug 2011 18:09:24 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: Message-ID: References: <201108250940.44847.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: ath0 no longer attaches, cardbus problems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:09:26 -0000 On Thu, 25 Aug 2011, Daniel Eischen wrote: > On Thu, 25 Aug 2011, John Baldwin wrote: > >> On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: >>> Hello, >>> >>> I have an older Dell 4150 laptop that takes forever to build >>> world, so I don't update it that often. The last time I >>> updated it was March 1, 2010. I just updated the system >>> yesterday and ath0 (a Linksys PCCard) no longer attaches. >>> >>> The interesting thing is that ath0 is detected at different >>> addresses between the working kernel and the non-working >>> kernel: >>> >>> March 1, 2010 kernel >>> -------------------- >>> ath0: mem 0x88000000-0x8800ffff irq 11 >>> at device 0.0 on cardbus0 >>> ath0: [ITHREAD] >>> ath0: AR5212 mac 5.9 RF5112 phy 4.3 >>> >>> >>> Aug 23, 2011 kernel >>> ------------------- >>> ath0: mem 0xf8f10000-0xf8f1ffff irq 11 >>> at device 0.0 on cardbus0 >>> >>> >>> I've tried forcing successful returns from >>> ar5212SetPowerModeAwake() and ar5212SetResetReg() >>> but it doesn't help (diffs below). >>> >>> Any suggestions on how to get this to work? >>> Full dmesg from working and non-working kernels at >>> >>> http://people.freebsd.org/~deischen/ath/ath.dmesg >> >> You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a >> test. If that doesn't work, a verbose dmesg from the broken case as well >> as >> devinfo -u and devinfo -r output from the working and broken cases would be >> most useful. > > Setting debug.acpi.disable=hostres did not work. Strange thing is > that ath0 is now at mem 0x88000000-0x8800ffff for both working > and non-working kernels (with and without debug.acpi.disable=hostres). > ath0 still doesn't attach, but it seems funny that the memory > address changes. These are all soft reboots, not hard reboots, > after a working kernel. I removed all changes I made to src/sys/dev/ath/ and am now using the driver unchanged. ath0 is now back at mem 0xf8f10000-0xf8f1ffff. > All the information you requested is here: > > http://people.freebsd.org/~deischen/ath/ The devinfo and dmesg outputs have been updated in the above. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Aug 25 23:02:45 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D97D106566C for ; Thu, 25 Aug 2011 23:02:45 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id B3CAE8FC0C for ; Thu, 25 Aug 2011 23:02:44 +0000 (UTC) X-AuditID: 1209190d-b7be0ae000000a16-15-4e56d3d549de Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 48.9C.02582.5D3D65E4; Thu, 25 Aug 2011 18:59:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p7PN2hAO008039; Thu, 25 Aug 2011 19:02:43 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p7PN2gtq021755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Aug 2011 19:02:43 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p7PN2fCM015129; Thu, 25 Aug 2011 19:02:41 -0400 (EDT) Date: Thu, 25 Aug 2011 19:02:41 -0400 (EDT) From: Benjamin Kaduk To: Rick Macklem In-Reply-To: <1252487773.337126.1314285501432.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <1252487773.337126.1314285501432.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nonv1cpifwfVFshYTrvxgsni47BqT A5PHjE/zWTx+b97LFMAUxWWTkpqTWZZapG+XwJXx4NtVtoKr4hVXL+5nbGDcKNTFyMkhIWAi sf7qbjYIW0ziwr31QDYXh5DAPkaJl9Mns0A4Gxgl3k2/zQ7hHGCSuPHiOROE08Ao0Xe2A6yf RUBb4sfu54wgNpuAisTMNxvB4iIC6hKbV/czg9jMAuIST26/YwWxhQUUJCbcXQc0iIODUyBA 4vt2TZAwr4CDxIemb2BjhAT8JSb/n8QCYosK6Eis3j+FBaJGUOLkzCcsECMtJc79uc42gVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MYJClVOSdwfju4NK hxgFOBiVeHgv5oT5CbEmlhVX5h5ilORgUhLl7QQGuhBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3uZQoBxvSmJlVWpRPkxKmoNFSZy3cIeDn5BAemJJanZqakFqEUxWhoNDSYL3FMhQwaLU9NSK tMycEoQ0EwcnyHAeoOE+IDW8xQWJucWZ6RD5U4yKUuK8M0ESAiCJjNI8uF5YKnnFKA70ijDv bpAqHmAagut+BTSYCWgwx68gkMEliQgpqQbGpez+DM/lJFez/fzrznRHzcaqvznuqH5I6evv F6VUdG7+Z09zsO2ef7rn3wPnc7IxdSvKG/nWv/O1fPuG9bPKqatlh3zfXfbebllve+/hn+Ib boH3XnvfcDGYa2Bq1G2vcFIsR/pB0cKmqt93/gsIL59dpvx0zuRH5Rp33DgEDdOzN/Q3f3RW YinOSDTUYi4qTgQAfL7SmwADAAA= Cc: current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 23:02:45 -0000 On Thu, 25 Aug 2011, Rick Macklem wrote: > Benjamin Kaduk wrote: >> >> If we're confident that we won't ever fully fill the hash table, I >> would >> think that this should wrap around back to zero (or one?) instead of >> overflowing. >> > Here's my updated patch (it will wrap to 1 the first time and then > exceed 255 if 1<->255 are all in use). > --- kern/vfs_init.c.sav 2011-06-11 18:58:33.000000000 -0400 > +++ kern/vfs_init.c 2011-08-25 11:09:14.000000000 -0400 > @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: head/sys/kern/vfs_in > > #include > #include > +#include > #include > #include > #include > @@ -138,6 +139,9 @@ vfs_register(struct vfsconf *vfc) > struct sysctl_oid *oidp; > struct vfsops *vfsops; > static int once; > + struct vfsconf *tvfc; > + uint32_t hashval; > + int secondpass; > > if (!once) { > vattr_null(&va_null); > @@ -152,7 +156,31 @@ vfs_register(struct vfsconf *vfc) > if (vfs_byname(vfc->vfc_name) != NULL) > return EEXIST; > > - vfc->vfc_typenum = maxvfsconf++; > + /* > + * Calculate a hash on vfc_name to use for vfc_typenum. Unless > + * all of 1<->255 are assigned, it is limited to 8bits since that is > + * what ZFS uses from vfc_typenum and is also the preferred range > + * for vfs_getnewfsid(). > + */ > + hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); > + hashval &= 0xff; > + secondpass = 0; > + do { > + /* Look for and fix any collision. */ > + TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { > + if (hashval == tvfc->vfc_typenum) { > + if (hashval == 255 && secondpass == 0) { > + hashval = 1; > + secondpass = 1; > + } else > + hashval++; > + break; > + } > + } > + } while (tvfc != NULL); > + vfc->vfc_typenum = hashval; > + if (vfc->vfc_typenum >= maxvfsconf) > + maxvfsconf = vfc->vfc_typenum + 1; > TAILQ_INSERT_TAIL(&vfsconf, vfc, vfc_list); > > /* > >> Do we need to care about something attempting to add the same vfc_name >> twice? This code will happily add a second entry at the next available >> index. >> > If file systems use VFS_SET(), I don't think this can happen, since the > same vfc_name would imply "same module name" and the 2nd one wouldn't load. > (Been there, w.r.t. nfs.) Ah. I guess I should get my act together and use VFS_SET, then. *hangs head sheepishly* > >>> + break; >>> + } >>> + } >>> + } while (tvfc != NULL); >>> + vfc->vfc_typenum = hashval; >>> + if (vfc->vfc_typenum >= maxvfsconf) >>> + maxvfsconf = vfc->vfc_typenum + 1; >> >> I guess we're holding off on killing maxvfsconf until after 9.0 is >> out? > > Well, I still don't know if anything has a use for vfs_sysctl(), so > I'm not volunteering to take it out. (If others feel it should come > out for 9.0, maybe... But I would still consider that a separate patch.) I don't particularly have an axe to grind, Danish or otherwise. Thanks for the update, Ben From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 00:56:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73C8106564A for ; Fri, 26 Aug 2011 00:56:08 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 706B28FC0C for ; Fri, 26 Aug 2011 00:56:08 +0000 (UTC) Received: from PortaPegIII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id p7Q0u5ml044310 for ; Fri, 26 Aug 2011 00:56:06 GMT (envelope-from ken@mthelicon.com) From: "Pegasus Mc Cleaft" To: Date: Fri, 26 Aug 2011 01:56:04 +0100 Message-ID: <003d01cc638a$ef75c050$ce6140f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acxjiu4chyi+e80ST2W8im+fPfL4pw== Content-Language: en-gb X-Spam-Status: No, score=0.9 required=15.0 tests=BAYES_00,DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hercules.mthelicon.com Subject: Console problem with ALT-F# keys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 00:56:08 -0000 Hello Current, I have recently discovered a problem and I was wondering if anyone has experienced this or if they can verify that it is not just my hardware. I am running FreeBSD 9.0-BETA1 r225125 compiled with LLVM on a Xeon processor (CPUTYPE=core2 and CFLAGS= -mmmx -msse -msse2 -msse3 -O2 -fno-strict-aliasing -pipe) I have recently installed this into a new machine and had chance to use the console for building kernel and ports (not to mention moving tons of files from one server to another.) What I am seeing is when I switch consoles from one to another, if I do them quickly there is no problem - Things work as I expect them to. However, if I keep the ALT key pressed for about 5 seconds and then hit another F key, it acts as if I had released the ALT key and presents only the F-key code to the console. I have tried a few experiments to try and help diagnose the problem. All the below tests were done with a keyboard attached to the PS2 port: 1) If you hold down the ALT key only for any length of time, the next F key will register as ALT-F# 2) If you do an ALT-F key and then continue to hold the ALT key down and within about 5 seconds strike another F-key, the console will see the ALT-F key correctly. 3) If you do an ALT-F key and the continue to hold the ALT key - wait more than about 5 seconds and then strike another f-key, the console will only see the F-Key strike. Since this is a new machine and the first install of BSD on it, I don't have anything to eliminate a hardware quirk with it. Its possible it may be the machine - I don't know. Would someone be willing to try the above tests and if its a BSD issue, I can submit a PR for it. Thanks Peg From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 06:41:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 550D2106566B for ; Fri, 26 Aug 2011 06:41:58 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1C38FC0C for ; Fri, 26 Aug 2011 06:41:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.16.7] by asmtp026.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQI00EXAT5L7Y10@asmtp026.mac.com> for freebsd-current@freebsd.org; Thu, 25 Aug 2011 22:41:47 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-08-26_01:2011-08-26, 2011-08-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108250348 From: Chuck Swiger In-reply-to: <003d01cc638a$ef75c050$ce6140f0$@com> Date: Thu, 25 Aug 2011 22:41:45 -0700 Message-id: References: <003d01cc638a$ef75c050$ce6140f0$@com> To: Pegasus Mc Cleaft X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: Console problem with ALT-F# keys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 06:41:58 -0000 Hi-- On Aug 25, 2011, at 5:56 PM, Pegasus Mc Cleaft wrote: > I am running FreeBSD 9.0-BETA1 r225125 compiled with LLVM on a Xeon > processor (CPUTYPE=core2 and CFLAGS= -mmmx -msse -msse2 -msse3 -O2 > -fno-strict-aliasing -pipe) The FreeBSD kernel doesn't use MMX or SSE by explicit design choice. See sys/conf/kern.mk: # [ ... ] Explicitly prohibit the use of SSE and other SIMD # operations inside the kernel itself. These operations are exclusively # reserved for user applications. # .if ${MACHINE_ARCH} == "i386" && ${CC} != "icc" CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 \ -mno-mmx -mno-3dnow -mno-sse -mno-sse2 INLINE_LIMIT?= 8000 .endif Trying to override the default compiler flags to force it to use MMX/SSE is simply not going to work. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 07:14:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B0D3106564A for ; Fri, 26 Aug 2011 07:14:36 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id A5A128FC0C for ; Fri, 26 Aug 2011 07:14:35 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward12.mail.yandex.net (Yandex) with ESMTP id D21CCC224B0 for ; Fri, 26 Aug 2011 11:14:34 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1314342874; bh=5lBhBI7tLQW40lvp9Wmx/48+TpY/8dvbOWXFC6OP+NI=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=efqnS1bNrIu2NKIjNMAuVNprSg3flKgQb11s3kut+/kKFVSD7u1T/vlXK1S7Ncjib xjji7j4uXkNbxhiNSH5nPLhhU6MvbapCPosgs3BxAjXZMwfVKVoPtl3vy3dFy7zQRd gquUB1Pd9croG/buuFJnNkrEzIgso5DVMQTd6BoI= Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id BDD90E4021E for ; Fri, 26 Aug 2011 11:14:34 +0400 (MSD) Received: from unknown (unknown [213.27.65.65]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id EYmSnfnO; Fri, 26 Aug 2011 11:14:34 +0400 X-Yandex-Spam: 1 Message-ID: <4E5747C5.9070705@yandex.ru> Date: Fri, 26 Aug 2011 11:14:13 +0400 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 26 Aug 2011 11:00:27 +0000 Subject: siba_bwn in GENERIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 07:14:36 -0000 Good day! Right now we have this line in GENERIC: #device bwn # Broadcom BCM43xx wireless NICs From user POV all he need to do to make his broadcom wifi work, is to uncomment this line and recompile his kernel. But this actually not sufficient - he also need to add device siba_bwn, and then install net/bwn-firmware-kmod. But he will know that after recompiling his kernel when his wireless adapter will not work as expected :). So may be we need to also add siba_bwn (commented out by default) in GENERIC and some reference about net/bwn-firmware-kmod? -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 11:15:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B2FC106564A for ; Fri, 26 Aug 2011 11:15:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4DB8FC0C for ; Fri, 26 Aug 2011 11:15:27 +0000 (UTC) Received: by gwb15 with SMTP id 15so3263738gwb.13 for ; Fri, 26 Aug 2011 04:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w0zFEc6chAzgPrjSdb8WU7LRJqZNOzjkASdfc61Vew0=; b=K46UJosHm+wHaqDJt0XIWd3JvAEUp0rAcCwruSDm/Fceh+XRoNWa4KY3zskZSW1QNr ylm87eb76e2a+LORCx44/hTkaKiZz50kSh+zksNLTQ8IVGTlNOzN3fwtGbTMcQTkCbaj 9vJGTo8kD8t8FxbG6fJrJcj8KF1emvf//fquY= MIME-Version: 1.0 Received: by 10.151.42.18 with SMTP id u18mr2106885ybj.429.1314357326645; Fri, 26 Aug 2011 04:15:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Fri, 26 Aug 2011 04:15:26 -0700 (PDT) In-Reply-To: <4E5747C5.9070705@yandex.ru> References: <4E5747C5.9070705@yandex.ru> Date: Fri, 26 Aug 2011 19:15:26 +0800 X-Google-Sender-Auth: 1AMv9cw05q9Q3hPdkjMP5CE9zgg Message-ID: From: Adrian Chadd To: Ruslan Mahmatkhanov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: siba_bwn in GENERIC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 11:15:27 -0000 On 26 August 2011 15:14, Ruslan Mahmatkhanov wrote: > Good day! > > Right now we have this line in GENERIC: > > #device =A0 =A0 =A0 =A0 bwn =A0 =A0 =A0 =A0 =A0 =A0 # Broadcom BCM43xx wi= reless NICs > > From user POV all he need to do to make his broadcom wifi work, is > to uncomment this line and recompile his kernel. But this actually not > sufficient - he also need to add device siba_bwn, and then install > net/bwn-firmware-kmod. But he will know that after recompiling his kernel > when his wireless adapter will not work as expected :). > > So may be we need to also add siba_bwn (commented out by default) in GENE= RIC > and some reference about net/bwn-firmware-kmod? I think it's a good idea, along with any other documentation related changes that need to occur. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 15:42:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D959E106564A for ; Fri, 26 Aug 2011 15:42:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB008FC0C for ; Fri, 26 Aug 2011 15:42:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9964E7302B; Fri, 26 Aug 2011 17:39:40 +0200 (CEST) Date: Fri, 26 Aug 2011 17:39:40 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20110826153940.GA3800@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: kqueue and device driver experience anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:42:09 -0000 a question for the kqueue experts out there: I am trying to add kqueue support to a device driver, and am puzzled on what the .f_event() function may assume. I see that some of the examples (e.g. bpf, audit_pipe.c) expect that the function is called with the device lock held (and even have a LOCK_ASSERT). Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock or explicitly acquire it. As far as i can tell the .f_event() function is called in two places: - within knote() which in turn (through KNOTE_*() ) is called by the driver itself near selrecord() . So it is up to the device driver to call it with the device lock held; - within kqueue_scan(), which instead is called from the upper half of the kernel as part of kern_kevent(). Here there seems to be no way that the device lock is acquired when .f_event() is called. Unless, of course, the knote's on which these .f_event() are called are not the same ones attached to devices -- so there is a different .f_event() function called ? So, is there a bug in the kqueue support for bpf.c and audit_pipe.c, or i am missing something important ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 17:13:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897EC1065672 for ; Fri, 26 Aug 2011 17:13:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 60F5F8FC17 for ; Fri, 26 Aug 2011 17:13:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 19A7246B51; Fri, 26 Aug 2011 13:13:05 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0CDE8A02F; Fri, 26 Aug 2011 13:13:04 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 26 Aug 2011 13:13:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20110826153940.GA3800@onelab2.iet.unipi.it> In-Reply-To: <20110826153940.GA3800@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108261313.03441.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 26 Aug 2011 13:13:04 -0400 (EDT) Cc: Luigi Rizzo Subject: Re: kqueue and device driver experience anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 17:13:05 -0000 On Friday, August 26, 2011 11:39:40 am Luigi Rizzo wrote: > a question for the kqueue experts out there: > > I am trying to add kqueue support to a device driver, and am puzzled > on what the .f_event() function may assume. > > I see that some of the examples (e.g. bpf, audit_pipe.c) > expect that the function is called with the device lock held > (and even have a LOCK_ASSERT). > > Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock > or explicitly acquire it. > > As far as i can tell the .f_event() function is called in two places: > > - within knote() which in turn (through KNOTE_*() ) is called > by the driver itself near selrecord() . So it is up to the > device driver to call it with the device lock held; > > - within kqueue_scan(), which instead is called from the upper half > of the kernel as part of kern_kevent(). Here there seems to be no > way that the device lock is acquired when .f_event() is called. > Unless, of course, the knote's on which these .f_event() are > called are not the same ones attached to devices -- so there is > a different .f_event() function called ? > > So, is there a bug in the kqueue support for bpf.c and audit_pipe.c, > or i am missing something important ? Note that the top-half code may end up locking the device's mutex if the mutex was tied to the knote list when the knote list was created (e.g. knlist_init_mtx()). In general if you want to use locking to protect your knlist, you should tell the knlist about the locking to use, then there are variants of KNOTE() that let it know if the calling code already holds the appropriate lock or not (KNOTE_LOCKED() and KNOTE_UNLOCKED()). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 18:22:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1DE106567A; Fri, 26 Aug 2011 18:22:36 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.freebsd.org (Postfix) with ESMTP id C9CF88FC15; Fri, 26 Aug 2011 18:22:35 +0000 (UTC) Received: from remote.double-l.nl (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id p7QIM3T0038699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Aug 2011 20:22:05 +0200 (CEST) (envelope-from Johan@double-l.nl) Received: from SRV01.double-l.local ([fe80::1128:e7bc:ba4a:a89a]) by SRV01.double-l.local ([fe80::1128:e7bc:ba4a:a89a%13]) with mapi id 14.01.0218.012; Fri, 26 Aug 2011 20:22:38 +0200 From: Johan Hendriks To: "Brian Seklecki (Mobile)" , "freebsd-questions@freebsd.org" Thread-Topic: CARP on 9.0 (was no subject) Thread-Index: AcxkBIZfpJv14nlbShODG/2S+Y/3sf//6VCAgAABsoCAAEJNew== Date: Fri, 26 Aug 2011 18:22:37 +0000 Message-ID: <6C3F8332272B7D4DA26909F15F1C90E1E5ACC4@SRV01.double-l.local> References: <6C3F8332272B7D4DA26909F15F1C90E1E5AC4C@SRV01.double-l.local> <20110826180517.4e4e585f@mr12941>, In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.50.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "freebsd-current@freebsd.org" Subject: RE: CARP on 9.0 (was no subject) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 18:22:36 -0000 >How about: > %sudo netstat -s carp >...on both machines. >A few years ago I submitted (or maybe it was Steve Polyack) a patch to add >debugging to CARP, not sure if it ever got commited. >Need-more-Cisco'sih-Debugging. >~BAS >On Fri, 26 Aug 2011, Patrick Lamaiziere wrote: >> Le Fri, 26 Aug 2011 15:26:28 +0000, >> Johan Hendriks a ?crit : >> >>> I am trying to set up CARP under 9.0 >> >> ... >> >>> Also with a higer value like advskew 200 or 254 the role of the >>> servers stays the same. >> >> Ok, there is something wrong so. >> >> Did you check that the sysctl net.inet.carp.suppress_preempt is equal >> to zero ? If yes, I don't have any more idea. >> >> Regards. Hello=20 first off all thanks for your time. sysctl -a | grep carp on both machines give me the following output sysctl -a | grep carp device carp net.inet.ip.same_prefix_carp_only: 0 net.inet.carp.allow: 1 net.inet.carp.preempt: 0 net.inet.carp.log: 2 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 netstat -s on the master carp: 260 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 11430 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error netstat -s on the slave carp: 11735 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 448 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error tcpdump -i bge0 on slave 20:10:48.868200 IP 192.168.50.40 > vrrp.mcast.net: VRRPv2, Advertisement, v= rid 1, prio 50, authtype none, intvl 1s, length 36 Here the advskew is set to 50, on the slave it is 20. So the slave should be the master. if i raise the advskew to 254, i see the change in the capture. Both machines are fresh install with nothing changed on them so far just a = fresh build from a csup this morning. And installed bash as the shell.. for freebsd-current@ the /etc/rc.conf file again Master=20 ifconfig_bge0=3D"inet 192.168.50.40 netmask 255.255.255.0" defaultrouter=3D"192.168.50.150" # CARP cloned_interfaces=3D"carp0" ifconfig_carp0=3D"vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 25= 5.255.255.0" On the slave i have the following in /etc/rc.conf ifconfig_bge0=3D"inet 192.168.50.41 netmask 255.255.255.0" defaultrouter=3D"192.168.50.150" # CARP cloned_interfaces=3D"carp0" ifconfig_carp0=3D"vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 25= 5.255.255.0" regards, Johan From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 19:21:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDAF8106566C; Fri, 26 Aug 2011 19:21:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 78AEB8FC13; Fri, 26 Aug 2011 19:21:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAIvxV06DaFvO/2dsb2JhbAA7CBaENqRRgUABAQEBAwEBARoGBCcgBgUbGAICDRkCKQEJJgYIBwQBHASHVahukWiBLIF/ghCBEQSRCoIQiD2IXw X-IronPort-AV: E=Sophos;i="4.68,286,1312171200"; d="scan'208";a="132379155" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 26 Aug 2011 15:21:07 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8D316B3F1F; Fri, 26 Aug 2011 15:21:07 -0400 (EDT) Date: Fri, 26 Aug 2011 15:21:07 -0400 (EDT) From: Rick Macklem To: John Message-ID: <470466580.417415.1314386467564.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110825203151.GA61776@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: F_RDLCK lock to FreeBSD NFS server fails to R/O target file [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:21:09 -0000 John wrote: > After pondering the best way to allow the VOP_ACCESS() call to > only query for the permissions really needed, I've come up with > a patch that minimally adds one parameter to the nlm_get_vfs_state() > function call with the lock type from the original argp. > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.accmode.patch > I took a look at it and it seemed mostly ok. However, please note that I am not familiar with the NLM code and try to avoid it like the plague.:-) One place I would suggest might want to be changed is the nlm_do_unlock() case. I don't think any file permission checking is needed for an unlock and it seems like it might fail when the called has VWRITE but not VREAD permissions on the file? Leaving a file locked is not a good situation. I would just not even do the VOP_ACCESS() call for that case. Maybe pass accmode == 0 into nlm_get_vfs_state() to indicate "skip the VOP_ACCESS() call". I think that this patch might be a little risky to put into head at this stage of the release cycle so, personally, I'd wait until after the 9.0 release before I'd look at committing it. Others might feel it's ok to go in now? rick > I'd appreciate a review and seeing what might be required to commit > this prior to 9 release. > > Thanks, > John > > ----- John's Original Message ----- > > Hi Fellow NFS'ers, > > > > I believe I have found the problem we've been having with read > > locks > > while attaching to a FreeBSD NFS server. > > > > In sys/nlm/nlm_prot_impl.c, function nlm_get_vfs_state(), there > > is a call > > to VOP_ACCESS() as follows: > > > > /* > > * Check cred. > > */ > > NLM_DEBUG(3, "nlm_get_vfs_state(): Calling > > VOP_ACCESS(VWRITE) with cred->cr_uid=%d\n",cred->cr_uid); > > error = VOP_ACCESS(vs->vs_vp, VWRITE, cred, curthread); > > if (error) { > > NLM_DEBUG(3, "nlm_get_vfs_state(): caller_name = %s > > VOP_ACCESS() returns %d\n", > > host->nh_caller_name, error); > > goto out; > > } > > > > The file being accessed is read only to the user, and open()ed > > with > > O_RDONLY. The lock being requested is for a read. > > > > fd = open(filename, O_RDONLY, 0); > > ... > > > > lblk.l_type = F_RDLCK; > > lblk.l_start = 0; > > lblk.l_whence= SEEK_SET; > > lblk.l_len = 0; > > lblk.l_pid = 0; > > rc = fcntl(fd, F_SETLK, &lblk); > > > > Running the above from a remote system, the lock call fails with > > errno set to ENOLCK. Given cred->cr_uid comes in as 227 which is > > my uid on the remote system. Since the file is R/O to me, and the > > VOP_ACCESS() is asking for VWRITE, it fails with errno 13, EACCES, > > Permission denied. > > > > The above operations work correctly to some of our other > > favorite big-name nfs vendors :-) > > > > Opinions on the "correct" way to fix this? > > > > 1. Since we're only asking for a read lock, why do we need to ask > > for VWRITE? I may not understand an underlying requirement for > > the VWRITE so please feel free to educate me if needed. > > > > Something like: request == F_RDLCK ? VREAD : VWRITE > > (need to figure out where to get the request from in this > > context). > > > > 2. Attempt VWRITE, fallback to VREAD... seems off to me though. > > > > 3. Other? > > > > I appreciate any thoughts on this. > > > > Thanks, > > John > > > > While they might not follow style(9) completely, I've uploaded > > my patch to nlm_prot.impl.c with the NLM_DEBUG() calls i've added. > > I'd appreciate it if someone would consider committing them so > > who ever debugs this file next will have them available. > > > > http://people.freebsd.org/~jwd/nlm_prot_impl.c.patch > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 20:45:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4469106566B; Fri, 26 Aug 2011 20:45:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 78BAE8FC08; Fri, 26 Aug 2011 20:45:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 662EA7302B; Fri, 26 Aug 2011 23:01:01 +0200 (CEST) Date: Fri, 26 Aug 2011 23:01:01 +0200 From: Luigi Rizzo To: John Baldwin Message-ID: <20110826210101.GA5822@onelab2.iet.unipi.it> References: <20110826153940.GA3800@onelab2.iet.unipi.it> <201108261313.03441.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108261313.03441.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: kqueue and device driver experience anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:45:59 -0000 On Fri, Aug 26, 2011 at 01:13:03PM -0400, John Baldwin wrote: > On Friday, August 26, 2011 11:39:40 am Luigi Rizzo wrote: > > a question for the kqueue experts out there: > > > > I am trying to add kqueue support to a device driver, and am puzzled > > on what the .f_event() function may assume. > > > > I see that some of the examples (e.g. bpf, audit_pipe.c) > > expect that the function is called with the device lock held > > (and even have a LOCK_ASSERT). > > > > Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock > > or explicitly acquire it. > > > > As far as i can tell the .f_event() function is called in two places: > > > > - within knote() which in turn (through KNOTE_*() ) is called > > by the driver itself near selrecord() . So it is up to the > > device driver to call it with the device lock held; > > > > - within kqueue_scan(), which instead is called from the upper half > > of the kernel as part of kern_kevent(). Here there seems to be no > > way that the device lock is acquired when .f_event() is called. > > Unless, of course, the knote's on which these .f_event() are > > called are not the same ones attached to devices -- so there is > > a different .f_event() function called ? > > > > So, is there a bug in the kqueue support for bpf.c and audit_pipe.c, > > or i am missing something important ? > > Note that the top-half code may end up locking the device's mutex > if the mutex was tied to the knote list when the knote list was > created (e.g. knlist_init_mtx()). In general if you want to use > locking to protect your knlist, you should tell the knlist about > the locking to use, then there are variants of KNOTE() that let it > know if the calling code already holds the appropriate lock or not > (KNOTE_LOCKED() and KNOTE_UNLOCKED()). ok, got it -- i see that bpf calls knlist_init_mtx() at init time. So i can try to do something similar in my case, though i need to deal with multiqueue cards which might be a bit trickier. The other thing i need (but i believe i know how to handle it) is tell whether .f_event() is called by KNOTE() or by kqueue_scan(), but i believe i can use the "hint" argument to tell the two. I guess i should add some notes to kqueue(9) once i understand it better. thanks for the clarification luigi The o > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 21:00:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 600731065677 for ; Fri, 26 Aug 2011 21:00:26 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA558FC1E for ; Fri, 26 Aug 2011 21:00:25 +0000 (UTC) Received: from remote.double-l.nl (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p7QKxsXd094629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Aug 2011 22:59:54 +0200 (CEST) (envelope-from Johan@double-l.nl) Received: from SRV01.double-l.local ([fe80::1128:e7bc:ba4a:a89a]) by SRV01.double-l.local ([fe80::1128:e7bc:ba4a:a89a%13]) with mapi id 14.01.0218.012; Fri, 26 Aug 2011 23:00:31 +0200 From: Johan Hendriks To: "freebsd-current@freebsd.org" Thread-Topic: CARP on 9.0 (was no subject) Thread-Index: AcxkBIZfpJv14nlbShODG/2S+Y/3sf//6VCAgAABsoCAAEJNe4AAL73E Date: Fri, 26 Aug 2011 21:00:31 +0000 Message-ID: <6C3F8332272B7D4DA26909F15F1C90E1E5B424@SRV01.double-l.local> References: <6C3F8332272B7D4DA26909F15F1C90E1E5AC4C@SRV01.double-l.local> <20110826180517.4e4e585f@mr12941>, , <6C3F8332272B7D4DA26909F15F1C90E1E5ACC4@SRV01.double-l.local> In-Reply-To: <6C3F8332272B7D4DA26909F15F1C90E1E5ACC4@SRV01.double-l.local> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.208.228.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: by XS4ALL Virus Scanner Subject: RE: CARP on 9.0 (was no subject) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 21:00:26 -0000 SOLVED!=0A= =0A= Was a typo in /etc/sysctl.conf=0A= Sorry for the noise=0A= =0A= and thanks for your time.=0A= =0A= regards=0A= Johan=0A= ________________________________________=0A= Van: owner-freebsd-current@freebsd.org [owner-freebsd-current@freebsd.org] = namens Johan Hendriks [Johan@double-l.nl]=0A= Verzonden: vrijdag 26 augustus 2011 20:22=0A= Aan: Brian Seklecki (Mobile); freebsd-questions@freebsd.org=0A= CC: freebsd-current@freebsd.org=0A= Onderwerp: RE: CARP on 9.0 (was no subject)=0A= =0A= >How about:=0A= =0A= > %sudo netstat -s carp=0A= =0A= >...on both machines.=0A= =0A= >A few years ago I submitted (or maybe it was Steve Polyack) a patch to add= =0A= >debugging to CARP, not sure if it ever got commited.=0A= =0A= >Need-more-Cisco'sih-Debugging.=0A= =0A= >~BAS=0A= =0A= =0A= >On Fri, 26 Aug 2011, Patrick Lamaiziere wrote:=0A= =0A= >> Le Fri, 26 Aug 2011 15:26:28 +0000,=0A= >> Johan Hendriks a ?crit :=0A= >>=0A= >>> I am trying to set up CARP under 9.0=0A= >>=0A= >> ...=0A= >>=0A= >>> Also with a higer value like advskew 200 or 254 the role of the=0A= >>> servers stays the same.=0A= >>=0A= >> Ok, there is something wrong so.=0A= >>=0A= >> Did you check that the sysctl net.inet.carp.suppress_preempt is equal=0A= >> to zero ? If yes, I don't have any more idea.=0A= >>=0A= >> Regards.=0A= =0A= Hello=0A= first off all thanks for your time.=0A= =0A= sysctl -a | grep carp on both machines give me the following output=0A= =0A= sysctl -a | grep carp=0A= device carp=0A= net.inet.ip.same_prefix_carp_only: 0=0A= net.inet.carp.allow: 1=0A= net.inet.carp.preempt: 0=0A= net.inet.carp.log: 2=0A= net.inet.carp.arpbalance: 0=0A= net.inet.carp.suppress_preempt: 0=0A= =0A= =0A= netstat -s on the master=0A= =0A= carp:=0A= 260 packets received (IPv4)=0A= 0 packets received (IPv6)=0A= 0 packets discarded for wrong TTL=0A= 0 packets shorter than header=0A= 0 discarded for bad checksums=0A= 0 discarded packets with a bad version=0A= 0 discarded because packet too short=0A= 0 discarded for bad authentication=0A= 0 discarded for bad vhid=0A= 0 discarded because of a bad address list=0A= 11430 packets sent (IPv4)=0A= 0 packets sent (IPv6)=0A= 0 send failed due to mbuf memory error=0A= =0A= netstat -s on the slave=0A= =0A= carp:=0A= 11735 packets received (IPv4)=0A= 0 packets received (IPv6)=0A= 0 packets discarded for wrong TTL=0A= 0 packets shorter than header=0A= 0 discarded for bad checksums=0A= 0 discarded packets with a bad version=0A= 0 discarded because packet too short=0A= 0 discarded for bad authentication=0A= 0 discarded for bad vhid=0A= 0 discarded because of a bad address list=0A= 448 packets sent (IPv4)=0A= 0 packets sent (IPv6)=0A= 0 send failed due to mbuf memory error=0A= =0A= tcpdump -i bge0 on slave=0A= =0A= 20:10:48.868200 IP 192.168.50.40 > vrrp.mcast.net: VRRPv2, Advertisement, v= rid 1, prio 50, authtype none, intvl 1s, length 36=0A= =0A= Here the advskew is set to 50, on the slave it is 20.=0A= So the slave should be the master.=0A= if i raise the advskew to 254, i see the change in the capture.=0A= =0A= Both machines are fresh install with nothing changed on them so far just a = fresh build from a csup this morning.=0A= And installed bash as the shell..=0A= =0A= for freebsd-current@ the /etc/rc.conf file again=0A= Master=0A= ifconfig_bge0=3D"inet 192.168.50.40 netmask 255.255.255.0"=0A= defaultrouter=3D"192.168.50.150"=0A= # CARP=0A= cloned_interfaces=3D"carp0"=0A= ifconfig_carp0=3D"vhid 1 advskew 10 pass letmepass 192.168.50.45 netmask 25= 5.255.255.0"=0A= =0A= On the slave i have the following in /etc/rc.conf=0A= ifconfig_bge0=3D"inet 192.168.50.41 netmask 255.255.255.0"=0A= defaultrouter=3D"192.168.50.150"=0A= # CARP=0A= cloned_interfaces=3D"carp0"=0A= ifconfig_carp0=3D"vhid 1 advskew 20 pass letmepass 192.168.50.45 netmask 25= 5.255.255.0"=0A= =0A= regards,=0A= Johan=0A= =0A= =0A= =0A= _______________________________________________=0A= freebsd-current@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= =0A= From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 21:07:36 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C891065674 for ; Fri, 26 Aug 2011 21:07:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 03AAE8FC15 for ; Fri, 26 Aug 2011 21:07:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA27129; Sat, 27 Aug 2011 00:07:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qx3ck-000Hf2-3B; Sat, 27 Aug 2011 00:07:34 +0300 Message-ID: <4E580B14.7090208@FreeBSD.org> Date: Sat, 27 Aug 2011 00:07:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: FreeBSD-Current , Marcel Moolenaar X-Enigmail-Version: undefined Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 21:07:36 -0000 It seems that after the introduction of the mountroot scripting language a user now has exactly one chance to try to specify a correct root device at the mountroot prompt. I am not sure that that is convenient/enough. I suspect that the following code is the cause: static void vfs_mountroot_conf0(struct sbuf *sb) { char *s, *tok, *mnt, *opt; int error; sbuf_printf(sb, ".onfail panic\n"); ... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 21:24:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 267481065674 for ; Fri, 26 Aug 2011 21:24:45 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E037C8FC0A for ; Fri, 26 Aug 2011 21:24:44 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p7QLOhi2035739 for ; Fri, 26 Aug 2011 17:24:43 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E580F15.4070904@sentex.net> Date: Fri, 26 Aug 2011 17:24:37 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Subject: ichwd attach failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 21:24:45 -0000 Got a newish Intel board in and decided to give it a spin. Trying to load the watchdog, I get this error below on CURRENT. Anyone able to get ichwd working on such a motherboard ? full dmesg and devinfo at http://www.tancsa.com/intel.txt and http://www.tancsa.com/intel-asl.txt isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 22:18:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 692CF106564A for ; Fri, 26 Aug 2011 22:18:52 +0000 (UTC) (envelope-from mxeconomou@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3066B8FC13 for ; Fri, 26 Aug 2011 22:18:51 +0000 (UTC) Received: by ywo32 with SMTP id 32so3910620ywo.13 for ; Fri, 26 Aug 2011 15:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=yYwH4mIFa3souVCsphlFgPRQazbKqBoluApyEp5uZ5o=; b=CxC/3Za9oQhXGGglZK2iIMsvBgd4Ji8+91pHdEaYi4BffkcuF52XQeukjEyKWaHwAR UhHgDTjaeXiAj7mC2Un+75L20upjA0894u/8HucUHy9EG26hsbHE35Q6QZOF07vye2kE SSuGWqr+iPFtZCS2W8+PpvCrb2z+jy7wcTYU8= MIME-Version: 1.0 Received: by 10.151.105.12 with SMTP id h12mr2622379ybm.124.1314395508691; Fri, 26 Aug 2011 14:51:48 -0700 (PDT) Received: by 10.147.125.18 with HTTP; Fri, 26 Aug 2011 14:51:48 -0700 (PDT) Date: Fri, 26 Aug 2011 17:51:48 -0400 Message-ID: From: Matthew Economou To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: "panic: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 22:18:52 -0000 I recently upgraded a firewall I'm using for performance testing from a March-ish 9-CURRENT to 9.0-BETA1 (csup run August 21 around 12:00 AM EDT). It's basically a GENERIC kernel with debugging disabled and things like IPsec and ALTQ enabled. Since the upgrade, after approximately an hour after it boots, the firewall stops passing any traffic (IPv4 and IPv6). OpenVPN, for example, logs the following errors: write UDPv4: Operation not permitted (code=1) Quagga, for another example, logs something similar: ripd[1696]: can't send packet : Operation not permitted0 ospfd[1702]: *** sendmsg in ospf_write failed to 172.30.0.3, id 0, off 0, len 76, interface tap0 mtu 1500: Operation not permitted If I try to ping something from the console, I get the same error message: # ping 4.2.2.2 ping: sendto: Operation not permitted It appears that PF isn't removing any entries from the state table. Note that the state table size is at its default of 10000 (which correlates to the amount of memory installed on the firewall - 256 MB). State Table Total Rate current entries 10013 searches 554801 13.4/s inserts 10013 0.2/s removals 0 0.0/s I've tried both my current (unmodified and working prior to the upgrade) and experimental PF configurations, neither of which have any effect on the problem. Reloading the PF configuration (/etc/rc.d/pf reload) or restarting PF altogether (/etc/rc.d/pf restart) also have no effect. Only if I shut down PF completely (/etc/rc.d/pf stop) do I regain network connectivity - I can do things like ping hosts (IPv4 and IPv6), browse the web, and pass traffic that's just routed through the firewall (i.e., not requiring NAT). Clearing the state table (pfsync -F state) has no effect. The kernel I'm was running had debugging disabled for performance testing purposes, so I booted a proper debug kernel. It panicked in pfsync_send_plus as soon as init enabled PF (backtrace included below). Starting pflog. pflog0: promiscuous mode enabled Aug 25 20:54:21 pflogd[1611]: [priv]: msg PRIV_OPEN_LOG received Enabling pfpanic: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163 cpuid = 0 KDB: enter: panic [ thread pid 1619 tid 100053 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 1619 tid 100053 td 0xc23da2e0 kdb_enter(c09777c9,c09777c9,c0975d7b,c6fd79e0,0,...) at kdb_enter+0x3a panic(c0975d7b,c0946080,c0944e87,c5b,c6fd7a0c,...) at panic+0x134 _mtx_assert(c0a1b388,0,c0944e87,c5b,c6fd7a24,...) at _mtx_assert+0x127 pfsync_send_plus(c6fd7a24,18,10,ad6,1000000,...) at pfsync_send_plus+0xf2 pfsync_clear_states(a218d664,c236fb78,c0945f1c,635,c09ae167,...) at pfsync_clear_states+0x8d pfioctl(c22a0800,c0cc4412,c236fb00,3,c23da2e0,...) at pfioctl+0x1b90 devfs_ioctl_f(c23ce578,c0cc4412,c236fb00,c216ce80,c23da2e0,...) at devfs_ioctl_f+0x10b kern_ioctl(c23da2e0,3,c0cc4412,c236fb00,1fd7cec,...) at kern_ioctl+0x21d ioctl(c23da2e0,c6fd7cec,c6fd7d28,c097d93a,0,...) at ioctl+0x134 syscallenter(c23da2e0,c6fd7ce4,c6fd7ce4,0,0,...) at syscallenter+0x263 syscall(c6fd7d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281e6263, esp = 0xbfbfe8ac, ebp = 0xbfbfe998 --- db> I'm at a loss as to how to proceed. Is this a known problem with PF? Can anyone suggest a work-around? Best wishes, Matthew From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 00:48:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E7EA31065670; Sat, 27 Aug 2011 00:48:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BEF3F1608A3; Sat, 27 Aug 2011 00:48:18 +0000 (UTC) Message-ID: <4E583ED1.4080202@FreeBSD.org> Date: Fri, 26 Aug 2011 17:48:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110824 Thunderbird/6.0 MIME-Version: 1.0 To: Mike Tancsa References: <4E580F15.4070904@sentex.net> In-Reply-To: <4E580F15.4070904@sentex.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , John Baldwin Subject: Re: ichwd attach failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 00:48:20 -0000 John was working on this, haven't seen an update recently though. Doug On 08/26/2011 14:24, Mike Tancsa wrote: > Got a newish Intel board in and decided to give it a spin. Trying to > load the watchdog, I get this error below on CURRENT. Anyone able to > get ichwd working on such a motherboard ? full dmesg and devinfo at > > http://www.tancsa.com/intel.txt > and > http://www.tancsa.com/intel-asl.txt > > > > isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer > ichwd0: on isa0 > isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer > pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 > pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > ppc0: cannot reserve I/O port range > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 01:53:59 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB4911065670 for ; Sat, 27 Aug 2011 01:53:59 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 7832F8FC08 for ; Sat, 27 Aug 2011 01:53:59 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p7R1fjI8068047 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 26 Aug 2011 21:41:46 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E584B58.8080904@FreeBSD.org> Date: Fri, 26 Aug 2011 21:41:44 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Fri, 26 Aug 2011 21:41:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: Subject: NFS mountd version 3 over TCP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 01:53:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0. When I attempt the mount, it logs this message: The NFS server does not support MOUNT version 3 over TCP Have I configured something wrong and if so what? Or is this something related to the new NFS code? Thanks, Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWEtYAAoJEPXPYrMgexuhWyAIAJ8Mfkjc8gtXxIYpbIDM2ECR B6ke25NNJj4Q41a77gqPsUr6nIePwoa6LlBcTNtQxx8xtC3CobB/QBjiGSLqQKoF cdcXj34tKE6e4cxptw+fYh7JXLalmmqd9BXgkKGf98UzXVDT0elIK7Ke/0thDp4s SOPO8VZ6tdMgo98oONk7qmv8nR2OhnXuJVBRBIc+Xfppq23/5u2GNeaqiJRv3Ace xVEusvPLAFtsCbyivoL27uqvJlNrA/cxA/VjzycYC+OhQ+deF3l8Ba0WNbVFSSjA tDXjT3acrHiAw7iej7Kqs9G1sZByFvymTl86E449+o6Y+1hs2Xn/3POUwWfaCqU= =U1iG -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 02:16:46 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 845E21065674 for ; Sat, 27 Aug 2011 02:16:46 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 284748FC0A for ; Sat, 27 Aug 2011 02:16:45 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p7R2GhMo068160 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 26 Aug 2011 22:16:44 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E58538B.3040607@FreeBSD.org> Date: Fri, 26 Aug 2011 22:16:43 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4E584B58.8080904@FreeBSD.org> In-Reply-To: <4E584B58.8080904@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Fri, 26 Aug 2011 22:16:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: Subject: Re: NFS mountd version 3 over TCP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 02:16:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/26/11 21:41, Steve Wills wrote: > Hi, > > I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0. > When I attempt the mount, it logs this message: > > The NFS server does not support MOUNT version 3 over TCP > > Have I configured something wrong and if so what? Or is this something > related to the new NFS code? I guess a little more info would be helpful... rc.conf has: nfs_server_enable="YES" rpcbind_enable="YES" mountd_enable="YES" rpc_statd_enable="YES" rpc_lockd_enable="YES" /etc/exports contains, amongst others: /boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask 255.255.255.0 rpcinfo shows: program version netid address service owner 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 4 udp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser 100000 4 tcp6 ::.0.111 rpcbind superuser 100000 3 tcp6 ::.0.111 rpcbind superuser 100000 4 udp6 ::.0.111 rpcbind superuser 100000 3 udp6 ::.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser 100005 1 udp6 ::.2.224 mountd superuser 100005 3 udp6 ::.2.224 mountd superuser 100005 1 tcp6 ::.2.224 mountd superuser 100005 3 tcp6 ::.2.224 mountd superuser 100005 1 udp 0.0.0.0.2.224 mountd superuser 100005 3 udp 0.0.0.0.2.224 mountd superuser 100005 1 tcp 0.0.0.0.2.224 mountd superuser 100005 3 tcp 0.0.0.0.2.224 mountd superuser tcpdump here: http://people.freebsd.org/~swills/nfs_debug.pcap Suggestions appreciated, thanks! Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWFOLAAoJEPXPYrMgexuhCvoH/1ky5qXxfQhgTdtYEDbCsfo4 J3xiFG9es+ajpNa1LtqlaMBrvs5fxfv0F7bzklOvUKmsVE4FPuFrcOd6IvIwTw+T U63UFocls3ZufNH+VjzxkFc5jfQ8hTDWXjKPfGMUxrCekt4pcEX4uze+I3YV/WRR IFLTkfUCLvgEJSHn39Yl7ZmHud6kJaUUQv5ne8vWgd8KRNt4IWQqvqltYZDvwY1f 8ajYxJDwKOkVRMhRwh+4O0Fgs3Owar1W0JyNzmJ+Se9/QIVzTwQS6Q4l3jQjfSrU YvRpMFQrb/ChZGZnH//FrXWhHK3TPg++XcRe1PGdY6KB+Fh1gjz+DRzbf5CzYBo= =dp9s -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 03:03:47 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA26106566C for ; Sat, 27 Aug 2011 03:03:47 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5ED8FC0A for ; Sat, 27 Aug 2011 03:03:47 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p7R33iYJ068295 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 26 Aug 2011 23:03:45 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E585E8F.2050701@FreeBSD.org> Date: Fri, 26 Aug 2011 23:03:43 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4E584B58.8080904@FreeBSD.org> <4E58538B.3040607@FreeBSD.org> In-Reply-To: <4E58538B.3040607@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Fri, 26 Aug 2011 23:03:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: rmacklem@uoguelph.ca Subject: Re: NFS mountd version 3 over TCP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 03:03:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/26/11 22:16, Steve Wills wrote: > On 08/26/11 21:41, Steve Wills wrote: >> Hi, > >> I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi 4.1.0. >> When I attempt the mount, it logs this message: > >> The NFS server does not support MOUNT version 3 over TCP > >> Have I configured something wrong and if so what? Or is this something >> related to the new NFS code? > > I guess a little more info would be helpful... > > rc.conf has: > > nfs_server_enable="YES" > rpcbind_enable="YES" > mountd_enable="YES" > rpc_statd_enable="YES" > rpc_lockd_enable="YES" > > /etc/exports contains, amongst others: > > /boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask 255.255.255.0 > > rpcinfo shows: > > program version netid address service owner > 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser > 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser > 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser > 100000 4 udp 0.0.0.0.0.111 rpcbind superuser > 100000 3 udp 0.0.0.0.0.111 rpcbind superuser > 100000 2 udp 0.0.0.0.0.111 rpcbind superuser > 100000 4 tcp6 ::.0.111 rpcbind superuser > 100000 3 tcp6 ::.0.111 rpcbind superuser > 100000 4 udp6 ::.0.111 rpcbind superuser > 100000 3 udp6 ::.0.111 rpcbind superuser > 100000 4 local /var/run/rpcbind.sock rpcbind superuser > 100000 3 local /var/run/rpcbind.sock rpcbind superuser > 100000 2 local /var/run/rpcbind.sock rpcbind superuser > 100005 1 udp6 ::.2.224 mountd superuser > 100005 3 udp6 ::.2.224 mountd superuser > 100005 1 tcp6 ::.2.224 mountd superuser > 100005 3 tcp6 ::.2.224 mountd superuser > 100005 1 udp 0.0.0.0.2.224 mountd superuser > 100005 3 udp 0.0.0.0.2.224 mountd superuser > 100005 1 tcp 0.0.0.0.2.224 mountd superuser > 100005 3 tcp 0.0.0.0.2.224 mountd superuser As you might guess, this rpcinfo output indicates nfsd wasn't running. I am seeing this: can't bind udp addr *: Address already in use in syslog. Setting this: nfs_server_flags="-t -n 4" allowed it to startup, but it then timed out an fsinfo call. Adding -o to the nfs_server_flags to use the old nfs server allowed vmware to mount. FWIW, I can't find any reason for the udp message above, nothing seems to be using it that I can find. Ideas? tcpdumps are available if anyone want them. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWF6PAAoJEPXPYrMgexuhHPYIAJ6SVxtORDbesvU35ktAS/id 5iWyTWO3CTHXT42uP4IZBT1o2AWFu6e9wUX84YEZyujMln0E++8hZccaa8zQBJhr febHkZxqPdQOo/mpg1ci5J70Hs1UBV9cxU3uOA83vxunOM6xwA0B+4krfflj/k7P cPtpztmuepQQ8/S5hB5ajnfM/gFOh1f2uPwWTj2/5NSWMoVfN3f0539bh05XKfRa 4X7XKxN/J4HBRGaNjnL8IWu86AW60H9Q3gdisdtT0k9sK4X3DswmiRMlMt4M4rS8 oX0vrgruTiKZf+bsraYvhuo4JyselXMicTnW7rUOVx8jiNVVk1nymSVF1XDUOrw= =MeJv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 12:00:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B848106566B; Sat, 27 Aug 2011 12:00:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5073D8FC19; Sat, 27 Aug 2011 12:00:51 +0000 (UTC) Received: by wyh15 with SMTP id 15so3774791wyh.13 for ; Sat, 27 Aug 2011 05:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=RDMNnosI9KniBdB7WF2tbR4EhuP2E1SB7goIvMgHsRw=; b=PNLzFfRMAjWLKNzPDwkyP3ROoXp26csdPhZfcnefsmUYUfNMmCTBN5sblVFwcKVnf2 mLCwVx+G4VNdj/PA5qEXQtnocmGD5PrY+XZ+qsIxbqD9mPWEtzEL8NldKXCaCtpv/VUR 8AU5dbg1gTv08H0efkzW/MekPq6B23YdoedzM= MIME-Version: 1.0 Received: by 10.227.72.200 with SMTP id n8mr1083196wbj.19.1314446450094; Sat, 27 Aug 2011 05:00:50 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.227.206.139 with HTTP; Sat, 27 Aug 2011 05:00:50 -0700 (PDT) Date: Sat, 27 Aug 2011 14:00:50 +0200 X-Google-Sender-Auth: vbAIcujJKXBpup-9FAoZdXFwgU4 Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Cc: Robert Watson , Konstantin Belousov Subject: Removal of Giant from the VFS layer for 10.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 12:00:52 -0000 [ Sorry for cross-posting, but I included -arch@ for technical discussion, -current@ for reaching the wider audience and -fs@ for the relevance of the matter.] During the last years a lot of effort by several developers happened in order to reduce Giant influence over the entire kernel. The VFS layer didn't make an exception, as many several tasks have been completed along the years, including fine-grained locking for vnodes lifecycle, fine-grained locking of the VFS structure (mount), fine-grained locking of specific filesystems (UFS, NFS, etc.) and several locking improvements to surrounding subsystem (buffer cache, filedesc objects, VM layer, etc.). While FreeBSD did pretty well so far, a major push is still needed in order to completely remove Giant from our VFS and buffer cache subsystems. At the present time, the biggest problem is that there are still filesystems which are not properly fine-grained locked, relying on Giant for assuring atomicity. It is time to make an decision for them, in order to aim for a Giant-less VFS in our next release. With the aid of kib and rwatson I made a roughly outlined plan about what is left to do in order to have all the filesystems locked (or eventually dropped) before 10.0) and is summarized here: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS As you can note from the page, the plan is thought to be 18 months long, including time for developers to convert all our filesystems and let thirdy-party producers do the same with their proprietary filesystems. Also the introduction (and later on removal) of VFS_GIANT_COMPATIBILITY is thought to stress-out the presence of not-yet MPSAFE filesystems used by consumers and force a proactive action. As you can note from the page, the list of filesystems to be converted is small and well contained, but there are some edge cases that really concerns me, like ntfs and smbfs. I took over leadership of ntfs, but if someone is willing to override myself, please just drop an e-mail and I'll happilly hand over someone else. About smbfs, I really think this is really the key filesystem we should fix in the list and it is time for someone to step up and do the job (including also locking and reworking netsmb). I knew there was a Google SoC going on this topic, but didn't have further updates to the matter in weeks. Ideally, after all the filesystems are locked, what should happen is to remove all Giant reference from the VFS, as kib's patch present in the wiki page. If some filesystem is still left for the 1st Semptember of next year, it is going to be disconnected from the tree along with Giant axing. As the locking of filesystems progresses, we can create subsections for each filesystems including technical notes on the matter. So fare there is none because the effort is still not started. The page is also thought to contain technical notes on how to operate the locking of filesystems, in more general way. I added the msdosfs example as a reference but other cases may have different problems. However, as the state of all the filesystems listed in the black page is a bit unknown, I'd suggest you to first make it work stable and just in the end work on locking. Also, please remind that locking doesn't need to be perfect at the first time, it is enough to bring the filesystem out of the Giant influence intially. Of course, for key filesystems (smbfs in primis) I'd expect to have full fine-grained locking support at some point. During the 18 months timeframe I'll send some reminder and status updates to these lists (monthly or bi-monthly). If there is anything else you want to discuss about this plan, don't hesitate to contact me. There is one last thing I want to stress out: this type of activities rely a lot on the audience to step up and make the job. Please don't expect someone else to fix the filesystem for you, but be proactive as much as you can, offering quality time for development, testing and reviews. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 12:30:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15AD81065673 for ; Sat, 27 Aug 2011 12:30:36 +0000 (UTC) (envelope-from erich@alogreentechnologies.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id B96728FC12 for ; Sat, 27 Aug 2011 12:30:35 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id p7RCBXg5003475; Sat, 27 Aug 2011 06:11:36 -0600 From: Erich Dollansky Organization: ALO Green Technologies Pte Ltd To: freebsd-current@freebsd.org Date: Sat, 27 Aug 2011 19:11:43 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <003d01cc638a$ef75c050$ce6140f0$@com> In-Reply-To: <003d01cc638a$ef75c050$ce6140f0$@com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108271911.43395.erich@alogreentechnologies.com> X-Mailman-Approved-At: Sat, 27 Aug 2011 12:39:39 +0000 Cc: Pegasus Mc Cleaft Subject: Re: Console problem with ALT-F# keys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 12:30:36 -0000 Hi, On Friday 26 August 2011 07:56:04 Pegasus Mc Cleaft wrote: > > I have recently installed this into a new machine and had chance to did you solve your problem? I have had a similar problem yesterday after upgrading my ports via packages. I could not even switch to the consoles anymore. This was solved after I compiled X and the drivers from the ports and installed them. Erich From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 13:00:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD4A106566B for ; Sat, 27 Aug 2011 13:00:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id DEB148FC16 for ; Sat, 27 Aug 2011 13:00:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAPrpWE6DaFvO/2dsb2JhbABChEykVYFAAQEBAQIBAQEBIAQnIAsFFg4KAgINGQIpAQkYDgYIBwQBHASHUQSoF5EVgSyED4ERBJEOghGRIA X-IronPort-AV: E=Sophos;i="4.68,289,1312171200"; d="scan'208";a="132429752" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 27 Aug 2011 09:00:34 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D1229B3F1F; Sat, 27 Aug 2011 09:00:34 -0400 (EDT) Date: Sat, 27 Aug 2011 09:00:34 -0400 (EDT) From: Rick Macklem To: Steve Wills Message-ID: <1032633878.435433.1314450034816.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4E585E8F.2050701@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@FreeBSD.org Subject: Re: NFS mountd version 3 over TCP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 13:00:36 -0000 Steve Wills wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/26/11 22:16, Steve Wills wrote: > > On 08/26/11 21:41, Steve Wills wrote: > >> Hi, > > > >> I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi > >> 4.1.0. > >> When I attempt the mount, it logs this message: > > > >> The NFS server does not support MOUNT version 3 over TCP > > > >> Have I configured something wrong and if so what? Or is this > >> something > >> related to the new NFS code? > > > > I guess a little more info would be helpful... > > > > rc.conf has: > > > > nfs_server_enable="YES" > > rpcbind_enable="YES" > > mountd_enable="YES" > > rpc_statd_enable="YES" > > rpc_lockd_enable="YES" > > > > /etc/exports contains, amongst others: > > > > /boxy/vmware -alldirs -maproot=0:0 -network 10.0.1 -mask > > 255.255.255.0 > > > > rpcinfo shows: > > > > program version netid address service owner > > 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser > > 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser > > 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser > > 100000 4 udp 0.0.0.0.0.111 rpcbind superuser > > 100000 3 udp 0.0.0.0.0.111 rpcbind superuser > > 100000 2 udp 0.0.0.0.0.111 rpcbind superuser > > 100000 4 tcp6 ::.0.111 rpcbind superuser > > 100000 3 tcp6 ::.0.111 rpcbind superuser > > 100000 4 udp6 ::.0.111 rpcbind superuser > > 100000 3 udp6 ::.0.111 rpcbind superuser > > 100000 4 local /var/run/rpcbind.sock rpcbind superuser > > 100000 3 local /var/run/rpcbind.sock rpcbind superuser > > 100000 2 local /var/run/rpcbind.sock rpcbind superuser > > 100005 1 udp6 ::.2.224 mountd superuser > > 100005 3 udp6 ::.2.224 mountd superuser > > 100005 1 tcp6 ::.2.224 mountd superuser > > 100005 3 tcp6 ::.2.224 mountd superuser > > 100005 1 udp 0.0.0.0.2.224 mountd superuser > > 100005 3 udp 0.0.0.0.2.224 mountd superuser > > 100005 1 tcp 0.0.0.0.2.224 mountd superuser > > 100005 3 tcp 0.0.0.0.2.224 mountd superuser This line indicates that mountd over tcp is registered for v3, so I suspect the error message is misleading?? > > As you might guess, this rpcinfo output indicates nfsd wasn't running. > I > am seeing this: > > can't bind udp addr *: Address already in use > Hmm, this should only happen if the nfsd is already running (or was recently running), since nothing else binds to port #2049 normally. (If something else grabbed port#2049 for udp, then that would explain this.) I assume the message was from nfsd? > in syslog. Setting this: > > nfs_server_flags="-t -n 4" > > allowed it to startup, but it then timed out an fsinfo call. Adding -o > to the nfs_server_flags to use the old nfs server allowed vmware to > mount. FWIW, I can't find any reason for the udp message above, > nothing > seems to be using it that I can find. Ideas? tcpdumps are available if > anyone want them. > Could you make sure you have this patch, which was committed by zkirsch as r224637. It was a fix they needed for a customer having difficulties mounting via VMware. (Our discussion about it agreed that the VMware client was broken for this case, but the patch fixed the problem.) If you didn't already have this patch, please test it (ie. apply it and take "-o" off the nfsd flags) and let us know if it fixed your problem? --- head/sys/fs/nfsserver/nfs_nfsdserv.c 2011/07/31 20:06:11 224554 +++ head/sys/fs/nfsserver/nfs_nfsdserv.c 2011/08/03 18:50:19 224637 @@ -620,7 +620,7 @@ vnode_t vp, NFSPROC_T *p, struct nfsexstuff *exp) { u_int32_t *tl; - int error = 0, cnt, len, getret = 1, reqlen, eof = 0; + int error = 0, cnt, getret = 1, reqlen, eof = 0; mbuf_t m2, m3; struct nfsvattr nva; off_t off = 0x0; @@ -714,11 +714,11 @@ eof = 1; } else if (reqlen == 0) cnt = 0; - else if ((off + reqlen) > nva.na_size) + else if ((off + reqlen) >= nva.na_size) { cnt = nva.na_size - off; - else + eof = 1; + } else cnt = reqlen; - len = NFSM_RNDUP(cnt); m3 = NULL; if (cnt > 0) { nd->nd_repstat = nfsvno_read(vp, off, cnt, nd->nd_cred, p, @@ -748,7 +748,7 @@ *tl++ = txdr_unsigned(cnt); } else NFSM_BUILD(tl, u_int32_t *, 2 * NFSX_UNSIGNED); - if (len < reqlen || eof) + if (eof) *tl++ = newnfs_true; else *tl++ = newnfs_false; > Steve > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (FreeBSD) > > iQEcBAEBAgAGBQJOWF6PAAoJEPXPYrMgexuhHPYIAJ6SVxtORDbesvU35ktAS/id > 5iWyTWO3CTHXT42uP4IZBT1o2AWFu6e9wUX84YEZyujMln0E++8hZccaa8zQBJhr > febHkZxqPdQOo/mpg1ci5J70Hs1UBV9cxU3uOA83vxunOM6xwA0B+4krfflj/k7P > cPtpztmuepQQ8/S5hB5ajnfM/gFOh1f2uPwWTj2/5NSWMoVfN3f0539bh05XKfRa > 4X7XKxN/J4HBRGaNjnL8IWu86AW60H9Q3gdisdtT0k9sK4X3DswmiRMlMt4M4rS8 > oX0vrgruTiKZf+bsraYvhuo4JyselXMicTnW7rUOVx8jiNVVk1nymSVF1XDUOrw= > =MeJv > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 13:40:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BD911065670 for ; Sat, 27 Aug 2011 13:40:38 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [204.109.58.86]) by mx1.freebsd.org (Postfix) with ESMTP id 086398FC17 for ; Sat, 27 Aug 2011 13:40:37 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p7RDea5I072207 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 27 Aug 2011 09:40:37 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E58F3D4.6070809@FreeBSD.org> Date: Sat, 27 Aug 2011 09:40:36 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: Rick Macklem References: <1032633878.435433.1314450034816.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1032633878.435433.1314450034816.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mouf.net [204.109.58.86]); Sat, 27 Aug 2011 09:40:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.2 at mouf.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: NFS mountd version 3 over TCP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 13:40:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/11 09:00, Rick Macklem wrote: >> This line indicates that mountd over tcp is registered for v3, >> so I suspect the error message is misleading?? Forgot to reply to this part, and I should have been more clear earlier. When I used the default nfsd flags, it failed to startup, or exited immediately on startup (not sure which). When I removed -u flag, it started up and that message was replaced with the one about fsinfo timeout. I can get the exact error message and tcpdump if you like. I then added -o flag to nfsd (didn't put -u back) and then things seemed to work OK. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWPPUAAoJEPXPYrMgexuhrLIH/jpRbAaKde9qi3xzsiIaZsuI +O31ScAk+weud90cEjf/N9PwW5PfSJYHMO03hliMVGuOphkwYnpN2AStExzScfmm nCFLz5UpzeKjznzirSOSNCGqwAyN3aPrghlyqNNi5eSkM9s0BdJgKBd+H9oSk7JE 7rf83Q2kPdqfvwhvRNpImC5oEXkZpExmitoIhESdnI/asr5OBwHIh8HthgIgMx+o 0t7v+togz0dT2jR7D+U1QbKhH5QP8pamjpP80D4TsO8P9pGt/PUuSBQAwDfQ3pjf Tjnc2t9YMQ+hw3zqYTRrNCNMvaH7PlyAW0LvuW1Nhk8mus6HFxP1St/hgko+Y+8= =Pdq4 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 15:07:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DDD5106564A; Sat, 27 Aug 2011 15:07:19 +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 BDA0A8FC0C; Sat, 27 Aug 2011 15:07:18 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7RF4UMu001658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Aug 2011 18:04:30 +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.4/8.14.4) with ESMTP id p7RF4Utv034565; Sat, 27 Aug 2011 18:04:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7RF4Uqr034564; Sat, 27 Aug 2011 18:04:30 +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: Sat, 27 Aug 2011 18:04:30 +0300 From: Kostik Belousov To: Attilio Rao Message-ID: <20110827150430.GI17489@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LzERIFExplvR0PTW" Content-Disposition: inline In-Reply-To: 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD FS , freebsd-current@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: Removal of Giant from the VFS layer for 10.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 15:07:19 -0000 --LzERIFExplvR0PTW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2011 at 02:00:50PM +0200, Attilio Rao wrote: > [ Sorry for cross-posting, but I included -arch@ for technical > discussion, -current@ for reaching the wider audience and -fs@ for the > relevance of the matter.] >=20 > During the last years a lot of effort by several developers happened > in order to reduce Giant influence over the entire kernel. > The VFS layer didn't make an exception, as many several tasks have > been completed along the years, including fine-grained locking for > vnodes lifecycle, fine-grained locking of the VFS structure (mount), > fine-grained locking of specific filesystems (UFS, NFS, etc.) and > several locking improvements to surrounding subsystem (buffer cache, > filedesc objects, VM layer, etc.). >=20 > While FreeBSD did pretty well so far, a major push is still needed in > order to completely remove Giant from our VFS and buffer cache > subsystems. > At the present time, the biggest problem is that there are still > filesystems which are not properly fine-grained locked, relying on > Giant for assuring atomicity. It is time to make an decision for them, > in order to aim for a Giant-less VFS in our next release. The scope of the project should be made slightly more concrete. If you do not use a non-mpsafe fs, then VFS does not acquire Giant. This is true at least for stable/8 and HEAD kernels, might be also true for stable/7, but I do not remember for sure. The aim of the project is to remove compatibility shims that conditionally acquire Giant on the as-needed basis to allow non-mpsafe filesystems to operate still under the usual locking regime. In other words, the project will not make anything much faster or scalable, but to remove some quite large amount of the crafty code from our VFS, which is, unfortunately, not known for the very clean interfaces. --LzERIFExplvR0PTW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5ZB34ACgkQC3+MBN1Mb4hZtACfQ0FFi0h+ySq6/yqLdaa8TKb1 l7MAnju58Ptqb8WXmYsHvziA3XwRusP/ =yjMg -----END PGP SIGNATURE----- --LzERIFExplvR0PTW-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 15:16:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60DA5106566C for ; Sat, 27 Aug 2011 15:16:32 +0000 (UTC) (envelope-from labeachgeek@gmail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id C9E5C8FC08 for ; Sat, 27 Aug 2011 15:16:31 +0000 (UTC) Received: by eye4 with SMTP id 4so2813592eye.31 for ; Sat, 27 Aug 2011 08:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=exyvqgPmmh3vfPwAG/PwwUC8609nwUdQW/Sl6ptzDRs=; b=X8o/L30Ut6xiPYmOP9Fiiof2000PkO3tNdSbpmhAeA3JTQ9P34iIp6vqZF5ACWf8yM lT97/A5eNyaP/Pcrd4i2Oc+tUjg56teAGuZWlZRzss2kSXlRK5oi6RqaxTUx0KyDYlHn 9UADd2CGsy+zeDW3tWNzSdx2eCgUcIMok+dgg= MIME-Version: 1.0 Received: by 10.213.35.195 with SMTP id q3mr1480658ebd.5.1314458190772; Sat, 27 Aug 2011 08:16:30 -0700 (PDT) Received: by 10.213.105.75 with HTTP; Sat, 27 Aug 2011 08:16:30 -0700 (PDT) In-Reply-To: <4E569A02.30206@FreeBSD.org> References: <4E569A02.30206@FreeBSD.org> Date: Sat, 27 Aug 2011 10:16:30 -0500 Message-ID: From: Beach Geek To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Subject: Re: buildworld failure r223619 to 225128 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 15:16:32 -0000 On 8/25/11, Dimitry Andric wrote: > On 2011-08-25 17:12, Beach Geek wrote: >> make buildworld failed trying to upgrade from r223619 to r225128. >> (Note: Updating other boxes from r224774 to r225119 went flawless) >> >> On failing laptop (Toshibs Sat C655D) > .... >> /usr/include/c++/4.2/bits/stringfwd.h:56: internal compiler error: >> Segmentation fault: 11 >> Please submit full report, > > That is most likely a hardware problem. Please run a full memtest, > and/or any other hardware diagnostics you can find. > > It could also be running out of memory, but that is less likely, and you > usually get another signal then. But who knows what might happen if you > choke a compiler. :) > > >> I do "rm -r /usr/obj/*" and make clean (in /usr/src) before doing >> buildworld on all boxes. >> I also tried compiling new GENERIC kernel then doing buildworld. It >> failed with same message. > > It dies on exactly the same file? > > >> Reverted to old/original kernel and tried "make depend" in /usr/src. > > You can't do that, you must run buildworld. > > >> It failed with... (by hand again) >> >> ===> lib/clang/libllvmarmasmparser (depend) >> tblgen -l >> /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM >> -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/include >> -I /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target >> -gen-asm-matcher -o ARMGenAsm Matcher.inc.h >> /usr/src/lib/clang/libllvmarmasmparser/../../../contrib/llvm/lib/Target/ARM/ARM.td >> >> tblgen: Record 'CCR', field 'MemberList' does not have a list initializer! >> *** Error code 1 >> Stop in /usr/src/lib/clang/libllvmarmasmparser. > > Yes, this is expected. When you do not use the buildworld target, the > tblgen used above will be run from /usr/bin, which is too old. This is > why buildworld first builds an up-to-date tblgen under /usr/obj, and > uses that to generate the needed files. > This laptop also runs MS Win 7/64 and FreeBSD 9 amd. The FBSD amd upgraded ok. The buildworld always fails in same place, with same message (5 tries). I'm running diags on it right now just to make sure the hardware's good. The reason I tried "make depend" was because of a reference to r221543 that said it required "make depend" before buildworld. (a shot in the dark before posting to mail list). I will post if I find any hardware problems. Thanks, Beach Geek PS. Option on updating to a version inbetween, then to latest??? From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 15:16:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3811710656D2; Sat, 27 Aug 2011 15:16:54 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 081408FC19; Sat, 27 Aug 2011 15:16:53 +0000 (UTC) Received: from sa-nc-common-23.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p7RFGkBt098479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Aug 2011 08:16:52 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Marcel Moolenaar In-Reply-To: <4E580B14.7090208@FreeBSD.org> Date: Sat, 27 Aug 2011 08:16:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A828073-1D5F-4850-9379-4AB62CF3DAE3@xcllnt.net> References: <4E580B14.7090208@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1244.3) Cc: FreeBSD-Current , Marcel Moolenaar Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 15:16:54 -0000 On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote: >=20 > It seems that after the introduction of the mountroot scripting = language a user > now has exactly one chance to try to specify a correct root device at = the > mountroot prompt. I am not sure that that is convenient/enough. This is no different from before. > I suspect that the following code is the cause: >=20 > static void > vfs_mountroot_conf0(struct sbuf *sb) > { > char *s, *tok, *mnt, *opt; > int error; >=20 > sbuf_printf(sb, ".onfail panic\n"); > =85 Yes. It is certainly a behavior we can improve upon. It's rather annoying to get a panic on a typo. However, we must remain cognizant of the fact that an immediate hard failure is what's needed at times. Maybe a good approach is to change to ".onfail retry" and extend the root mount prompt with a reboot command, so that the user/operator is does not have to worry about typos *and* don't have to trigger a panic just so that he/she can initiate a reboot. Thoughts? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 19:00:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97CE81065673 for ; Sat, 27 Aug 2011 19:00:18 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from web01.lando.us (web01.lando.us [77.232.247.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0FED68FC13 for ; Sat, 27 Aug 2011 19:00:12 +0000 (UTC) Received: from Jabba (p4FFD1783.dip.t-dialin.net [79.253.23.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: uwe@grohnwaldt.eu) by web01.lando.us (Postfix) with ESMTPSA id D6FBB9081A for ; Sat, 27 Aug 2011 21:00:11 +0200 (CEST) From: "Uwe Grohnwaldt" To: Date: Sat, 27 Aug 2011 21:00:17 +0200 Message-ID: <00ba01cc64eb$8f878fe0$ae96afa0$@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acxk4qFkyhppXR86QFm6u6azBfjQ3A== Content-Language: de Cc: Subject: Areca 1280ML ccb command time out X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 19:00:18 -0000 Hi, after upgrading vom FBSD8.2 to todays current, I have the problem that my two Areca controllers don't find any disks. In dmesg there are a lot of messages like: arcmsr0: scsi id 2 lun 0 cmd=0x12 srb='0xffffff83e298f000' ccb command time out! The whole dmesg can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt I found no similar problems on the list. So anybody have an idea where to start with this problem? Best regards, Uwe From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 19:13:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10717106564A for ; Sat, 27 Aug 2011 19:13:28 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C48E58FC13 for ; Sat, 27 Aug 2011 19:13:27 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QxOJq-00029M-QF>; Sat, 27 Aug 2011 21:13:26 +0200 Received: from e178023117.adsl.alicedsl.de ([85.178.23.117] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QxOJq-0004Fw-Nd>; Sat, 27 Aug 2011 21:13:26 +0200 Message-ID: <4E5941D6.9090106@zedat.fu-berlin.de> Date: Sat, 27 Aug 2011 21:13:26 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110825 Thunderbird/6.0 MIME-Version: 1.0 To: "freebsd-performance@freebsd.org" , freebsd Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.23.117 Cc: Subject: http://www.freebsd.org/marketing/os-comparison.html X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 19:13:28 -0000 This website should be brushed up or taken offline! It seems full of vintage stuff from glory days. http://www.freebsd.org/marketing/os-comparison.html O. From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 19:32:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ADC9106564A for ; Sat, 27 Aug 2011 19:32:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30C828FC12 for ; Sat, 27 Aug 2011 19:32:46 +0000 (UTC) Received: by qyk9 with SMTP id 9so3414603qyk.13 for ; Sat, 27 Aug 2011 12:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3gQEdb/TqiUo156jf2V7LzmH04ZNrH53XMA1ldzQTl4=; b=Oternog7pwNukAPpnodtsrCuzSHQ54z6Dsvf2TTewhMrtK2UK+SZZcx7rTzqtfG/qC QOcugCbTHDwXkok2QY4SRDrRfq8WlDUWAsmrC1D5vKHi6/PsI23SiuNJLgn44GyBfNi0 yrE8rk+LmWuG0GfkuceS/7hz+L0cE/WEfrb8s= MIME-Version: 1.0 Received: by 10.229.66.215 with SMTP id o23mr3589577qci.17.1314473565667; Sat, 27 Aug 2011 12:32:45 -0700 (PDT) Received: by 10.224.19.131 with HTTP; Sat, 27 Aug 2011 12:32:45 -0700 (PDT) In-Reply-To: <4E5941D6.9090106@zedat.fu-berlin.de> References: <4E5941D6.9090106@zedat.fu-berlin.de> Date: Sat, 27 Aug 2011 12:32:45 -0700 Message-ID: From: Garrett Cooper To: "Hartmann, O." Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-performance@freebsd.org" , freebsd Current Subject: Re: http://www.freebsd.org/marketing/os-comparison.html X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 19:32:46 -0000 On Sat, Aug 27, 2011 at 12:13 PM, Hartmann, O. wrote: > This website should be brushed up or taken offline! > It seems full of vintage stuff from glory days. > > http://www.freebsd.org/marketing/os-comparison.html Agreed. Things have changed quite a bit in the last decade. -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 22:07:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76F26106564A; Sat, 27 Aug 2011 22:07:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5B18FC0C; Sat, 27 Aug 2011 22:07:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALhpWU6DaFvO/2dsb2JhbABChEykO4FAAQEFI1YbDgoCAg0ZAlkGsAeQO4EshA+BEQSTH5Eg X-IronPort-AV: E=Sophos;i="4.68,291,1312171200"; d="scan'208";a="132454114" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 27 Aug 2011 18:07:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2449EB3F36; Sat, 27 Aug 2011 18:07:27 -0400 (EDT) Date: Sat, 27 Aug 2011 18:07:27 -0400 (EDT) From: Rick Macklem To: Steve Wills Message-ID: <685516958.440690.1314482847093.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4E58F3D4.6070809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@FreeBSD.org Subject: Re: NFS mountd version 3 over TCP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 22:07:28 -0000 Steve Wills wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/27/11 09:00, Rick Macklem wrote: > >> This line indicates that mountd over tcp is registered for v3, > >> so I suspect the error message is misleading?? > > Forgot to reply to this part, and I should have been more clear > earlier. > When I used the default nfsd flags, it failed to startup, or exited > immediately on startup (not sure which). I have no idea w.r.t. this one. The failure is the bind(2) syscall failing for port #2049 over UDP, but I have no idea why? (Others aren't seeing this, as far as I know.) When I removed -u flag, it > started up and that message was replaced with the one about fsinfo > timeout. > I can get the exact error message and tcpdump if you like. Both the message and a tcpdump (binary capture of traffic between the two hosts) would be useful. A tcpdump command like this done on the FreeBSD server: tcpdump -s 0 -w host You can just email me as an attachment and I'll take a look at it. > I > then added -o flag to nfsd (didn't put -u back) and then things seemed > to work OK. > > Steve > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (FreeBSD) > > iQEcBAEBAgAGBQJOWPPUAAoJEPXPYrMgexuhrLIH/jpRbAaKde9qi3xzsiIaZsuI > +O31ScAk+weud90cEjf/N9PwW5PfSJYHMO03hliMVGuOphkwYnpN2AStExzScfmm > nCFLz5UpzeKjznzirSOSNCGqwAyN3aPrghlyqNNi5eSkM9s0BdJgKBd+H9oSk7JE > 7rf83Q2kPdqfvwhvRNpImC5oEXkZpExmitoIhESdnI/asr5OBwHIh8HthgIgMx+o > 0t7v+togz0dT2jR7D+U1QbKhH5QP8pamjpP80D4TsO8P9pGt/PUuSBQAwDfQ3pjf > Tjnc2t9YMQ+hw3zqYTRrNCNMvaH7PlyAW0LvuW1Nhk8mus6HFxP1St/hgko+Y+8= > =Pdq4 > -----END PGP SIGNATURE-----