From owner-freebsd-current@FreeBSD.ORG Sun Jan 31 01:38:04 2010 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 0AD12106566B; Sun, 31 Jan 2010 01:38:04 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 66E198FC14; Sun, 31 Jan 2010 01:38:03 +0000 (UTC) Received: by bwz5 with SMTP id 5so572016bwz.3 for ; Sat, 30 Jan 2010 17:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Xw/0i4hV99pN2o9N+HRb6HezJesTdMqh15dzuNM1RNQ=; b=EX4ZO+GIBAhk/jTxcpuFlzmjrXQ1zwe3YZmgRnXUucaPhkgaG0lykPIvbgNVK7jikR 43vz7CTFoFy4o0mSLorkSBfjXlKs33A26ZOQvKs9lRDgNLO516wG948V6bWgh7Y/A+4+ 1CzuYNU7aSkFqQSvq0iJtqRmd7xfEhZle93Cw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lxQeOJIgbkRhtjYmubQioJcFqgJ9U9j7R0/CA3pQ+cGf72QJnSr+wzq40rKyqBifyQ TAH5Tj3M+VMfvExDtN7tj2qyAUoOAyx7s0mEBRJM8NiWE23Dca5GoRwyIjT7KhfcMJZR tvy7y30AsCgK00koqvwwmXSRaVkF+s0vVxOEo= MIME-Version: 1.0 Received: by 10.204.23.20 with SMTP id p20mr93955bkb.54.1264901882265; Sat, 30 Jan 2010 17:38:02 -0800 (PST) In-Reply-To: <4B636FCF.3080209@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> <4B62DD46.4060908@FreeBSD.org> <83e5fb981001291525k6d533fdaj1611df806077d94f@mail.gmail.com> <4B636FCF.3080209@FreeBSD.org> Date: Sun, 31 Jan 2010 02:38:02 +0100 Message-ID: <83e5fb981001301738p31c0643es3f5ee69d7f12c46a@mail.gmail.com> From: Diego Depaoli To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements 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, 31 Jan 2010 01:38:04 -0000 On Sat, Jan 30, 2010 at 12:31 AM, Alexander Motin wrote: > > If you have kernel.debug, you may use > addr2line -e kernel.debug 0xc057efcd > to get source line number, where it crashed. But stack back trace would > be better. I cannot dump: No dump device defined or unavailable, so, as usual, handwritten panic: g_read_data(): invalid length 3737169374 cpuid=0 KDB_ enter: panic [thread pid 2 tid 100009] Stopped at kdb_enter_+0x3a_ movl $0,kdb_why >bt Tracing pid 2 tid 100009 td 0xc69f5480 kdb_enter(c088699c,c088699c,c087d5c3,c67e0bc0,0,...) at kdb_enter+0x3a panic(c087d5c3,dec0adde,0,c6d62080,c08d6080,...) at panic+0x136 g_read_data(c6d62080,4b15cc84,c1d2be92,dec0adde,0,...) at g_read_data+0x66 g_label_taste(c08d6080,c6c72700,0,220,c6c72380,...) at g_label_taste+0x203 g_new_provider_event(c6c72700,0,c087d181,d2,109,...) at g_new_provider_event+0x9f g_run_events(c093ea58,0,4c,c087c046,64,...) at g_run_events+0x31e g_event_procbody(0,c67e0d38,c0881bc1,343,c696b550,...) at g_event_procbody+0x8a fork_exit(c053f470,0,c67e0d38) at fork_ex+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc67e0d70, ebp = 0 --- Hope that helps. -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Sun Jan 31 11:55:01 2010 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 1F1961065670 for ; Sun, 31 Jan 2010 11:55:01 +0000 (UTC) (envelope-from bulinskp@iem.pw.edu.pl) Received: from volt.iem.pw.edu.pl (volt.iem.pw.edu.pl [194.29.146.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1748FC21 for ; Sun, 31 Jan 2010 11:55:00 +0000 (UTC) Received: from [192.168.150.8] (aapl125.neoplus.adsl.tpnet.pl [83.5.145.125]) (Authenticated sender: bulinskp) by volt.iem.pw.edu.pl (Postfix) with ESMTPSA id EC05BA6664A; Sun, 31 Jan 2010 12:37:19 +0100 (CET) From: =?utf-8?Q?Piotr_Buli=C5=84ski?= Content-Type: multipart/signed; boundary=Apple-Mail-6-1015314247; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 31 Jan 2010 12:37:19 +0100 To: freebsd-current@freebsd.org Message-Id: <4D59045B-6B03-440C-BCCC-C9C171621475@iem.pw.edu.pl> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: clamav-milter devel-20100125-exp at volt.iem.pw.edu.pl X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with sftp server, static linking, pam and nss_ldap. 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, 31 Jan 2010 11:55:01 -0000 --Apple-Mail-6-1015314247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, recently we moved our users database to LDAP server, but after that sftp = stops=20 working on our students server.=20 We use: - OpenLDAP 2.4.21 - nss_ldap-1.265_3 - pam_ldap-1.8.5 - FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Jan 25 18:52:41 CET = 2010 amd64 When I use sftp, it drops the connection: {volt}-{~}% sftp localhost Connecting to localhost... Connection closed {volt}-{~}%=20 After short investigation, I've found that problem is in=20 /usr/libexec/sftp-server program (which is our default subsystem in = sshd): {volt}-{~}% /usr/libexec/sftp-server=20 No user found for uid 5567 {volt}-{~}%=20 what was quite weird, because sshd works perfectly with users from LDAP = server=20 (so I assume that PAM is configured correctly). After that, I've tried to make a simple test with program below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #include #include #include #include #include int main(int argc, char **argv) { struct passwd *user_pw; user_pw =3D getpwuid(getuid()); if ((user_pw =3D getpwuid(getuid())) =3D=3D NULL) { fprintf(stderr, "No user found for uid %lu\n", (u_long)getuid()); return 1; } else { fprintf(stderr, "It works %s!\nYour uid is: %lu\n", user_pw->pw_name, (u_long)getuid()); } return 0; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D which is almost copy-pasted from = /usr/src/crypto/openssh/sftp-server-main.c I've build it twice. Once with dynamic linking: {volt}-{~}% cc -o test test.c =20 {volt}-{~}% ./test It works bulinskp! Your uid is: 5567 {volt}-{~}%=20 another one with static linking: {volt}-{~}% cc -o test -static test.c {volt}-{~}% ./test =20 No user found for uid 5567 {volt}-{~}%=20 As you can see, it works great with dynamic linking, but if it's build = with=20 static linking it can't get user information from LDAP database. During the upgrade to OpenSSH 5.3p1 = /head/secure/libexec/sftp-server/Makefile file changed a little bit: revision 181111, Fri Aug 1 02:48:36 2008 UTC ---> revision 197679, Thu = Oct 1 17:12:52 2009 UTC LDADD=3D -lssh -lcrypt -lcrypto -lz ---> LDADD=3D -lcrypt = -lcrypto -lz -static -lssh So I've tried to build sftp-server without -static switch, but it result = in failure like below: {volt}-{/usr/src/secure/libexec/sftp-server}% sudo make Warning: Object directory not changed from original = /usr/src/secure/libexec/sftp-server cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -c = /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server.c cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -c = /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-common.c cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -c = /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server-ma= in.c cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -o sftp-server = sftp-server.o sftp-common.o sftp-server-main.o -lssh -lcrypt -lcrypto = -lz /usr/lib/libssh.so: undefined reference to `ssh_add_recv_bytes' /usr/lib/libssh.so: undefined reference to `ssh_roaming_write' /usr/lib/libssh.so: undefined reference to `ssh_roaming_read' *** Error code 1 Stop in /usr/src/secure/libexec/sftp-server. {volt}-{/usr/src/secure/libexec/sftp-server}%=20 Do you have any idea how to make it works? regards --=20 Piotr Buli=C5=84ski Informatyka na Wydziale Elektrycznym Politechnika Warszawska= --Apple-Mail-6-1015314247-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 31 12:58:07 2010 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 9FD0E106566B; Sun, 31 Jan 2010 12:58:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 60C418FC18; Sun, 31 Jan 2010 12:58:07 +0000 (UTC) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id 873341DD646; Sun, 31 Jan 2010 13:58:05 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 1677) id 6D36D73F9D; Sun, 31 Jan 2010 13:58:05 +0100 (CET) Date: Sun, 31 Jan 2010 13:58:05 +0100 From: Jilles Tjoelker To: Piotr =?utf-8?B?QnVsacWEc2tp?= Message-ID: <20100131125805.GA44187@stack.nl> References: <4D59045B-6B03-440C-BCCC-C9C171621475@iem.pw.edu.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D59045B-6B03-440C-BCCC-C9C171621475@iem.pw.edu.pl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, des@freebsd.org Subject: Re: Problem with sftp server, static linking, pam and nss_ldap. 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, 31 Jan 2010 12:58:07 -0000 On Sun, Jan 31, 2010 at 12:37:19PM +0100, Piotr BuliÅ„ski wrote: > As you can see, it works great with dynamic linking, but if it's build with > static linking it can't get user information from LDAP database. Correct, NSS only works from dynamically-linked executables. > During the upgrade to OpenSSH 5.3p1 /head/secure/libexec/sftp-server/Makefile file changed a little bit: > > revision 181111, Fri Aug 1 02:48:36 2008 UTC ---> revision 197679, Thu Oct 1 17:12:52 2009 UTC > LDADD= -lssh -lcrypt -lcrypto -lz ---> LDADD= -lcrypt -lcrypto -lz -static -lssh > So I've tried to build sftp-server without -static switch, but it > result in failure like below: > {volt}-{/usr/src/secure/libexec/sftp-server}% sudo make > Warning: Object directory not changed from original /usr/src/secure/libexec/sftp-server > cc -O2 -pipe -fomit-frame-pointer -march=opteron -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -std=gnu99 -Wno-pointer-sign -c /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server.c > cc -O2 -pipe -fomit-frame-pointer -march=opteron -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -std=gnu99 -Wno-pointer-sign -c /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-common.c > cc -O2 -pipe -fomit-frame-pointer -march=opteron -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -std=gnu99 -Wno-pointer-sign -c /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server-main.c > cc -O2 -pipe -fomit-frame-pointer -march=opteron -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -std=gnu99 -Wno-pointer-sign -o sftp-server sftp-server.o sftp-common.o sftp-server-main.o -lssh -lcrypt -lcrypto -lz > /usr/lib/libssh.so: undefined reference to `ssh_add_recv_bytes' > /usr/lib/libssh.so: undefined reference to `ssh_roaming_write' > /usr/lib/libssh.so: undefined reference to `ssh_roaming_read' > *** Error code 1 > Stop in /usr/src/secure/libexec/sftp-server. > {volt}-{/usr/src/secure/libexec/sftp-server}% > Do you have any idea how to make it works? Apparently something broke so that sftp-server cannot link to libssh dynamically, even though scp and ssh can still use it. By changing the line in secure/libexec/sftp-server/Makefile to LDADD= -lcrypt -lcrypto -lz -Wl,-static -lssh -Wl,-call_shared it links only libssh and its dependencies statically, which may be enough to fix your problem. This still links quite a lot more than libssh statically, I am not happy with it at all. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Jan 31 19:35:32 2010 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 0AAAB1065679 for ; Sun, 31 Jan 2010 19:35:32 +0000 (UTC) (envelope-from bsdlisten@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 93F6A8FC18 for ; Sun, 31 Jan 2010 19:35:31 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so165724fge.13 for ; Sun, 31 Jan 2010 11:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=227bVp7N9XnNN6LOQbPXAv3BMCIvtJUifRuyfkw7vT8=; b=OdO8XtztBf8VjZUqDfg04VU0TXadJRNPriBjxBY+tkssKWsAqvyaVJ+Tm4DUuCDviG tJ9k/CsMW8zI53D/z4o/9kEOyXaS2yyhoLNerGdOJ0MMdreye4KNn9+N5Ec+qwjnomcE RHrAEOvL5uRSWbNrnl9t8cH/Oz795TXlELqQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=xYCXqAo1i1nbR6Re86CGVrlvzFNDNYPnMvJ0UIrP3b5ep/i7gm5c9o6Sm4OPX0yHsB GHqqGJaPhEIwjBzbagPkzY6AnRcvVJh0iQRYq9Y82II5Zmo/RtAPu/srwuiPgnSa2r7t aaclojAA6ZrST9LF0VfHeyy9Tescbi3zZJjkQ= Received: by 10.87.69.26 with SMTP id w26mr6098336fgk.39.1264966530334; Sun, 31 Jan 2010 11:35:30 -0800 (PST) Received: from localhost-desk1.localdomain ([89.47.83.116]) by mx.google.com with ESMTPS id 3sm7987977fge.26.2010.01.31.11.35.28 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Jan 2010 11:35:29 -0800 (PST) Date: Sun, 31 Jan 2010 21:36:30 +0200 From: Aioanei Rares To: freebsd-current@freebsd.org Message-Id: <20100131213630.854ff720.bsdlisten@gmail.com> X-Mailer: Sylpheed 3.0.0beta4 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: kernel fault when doing some I/O 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, 31 Jan 2010 19:35:32 -0000 Hi everyone, I've been getting this several times but only now I could get a screenshot (it's a X-less VirtualBox host) The message I'm getting is the following : lock order reversal : 1st 0xffffff800a4c8698 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xffffff0002b81000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_lock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x889 ufs_makeinode() at ufs_makeinode+0x38a VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x473 kern_openat() at kern_openat+0x179 syscall() at syscall+0x1ae Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x800c1095c, rsp = 0x7fffff1f9b38, rbp = 0x800e0a900 --- I was doing an update of my src tree, if that matters. Hope this helps. :) -- Aioanei Rares From owner-freebsd-current@FreeBSD.ORG Sun Jan 31 21:53:28 2010 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 40A311065670 for ; Sun, 31 Jan 2010 21:53:28 +0000 (UTC) (envelope-from bulinskp@iem.pw.edu.pl) Received: from volt.iem.pw.edu.pl (volt.iem.pw.edu.pl [194.29.146.3]) by mx1.freebsd.org (Postfix) with ESMTP id ABF6A8FC16 for ; Sun, 31 Jan 2010 21:53:27 +0000 (UTC) Received: from [192.168.150.8] (aaph86.neoplus.adsl.tpnet.pl [83.5.141.86]) (Authenticated sender: bulinskp) by volt.iem.pw.edu.pl (Postfix) with ESMTPSA id 4C457A665E3; Sun, 31 Jan 2010 22:53:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-7-1052279468; protocol="application/pkcs7-signature"; micalg=sha1 From: =?utf-8?Q?Piotr_Buli=C5=84ski?= In-Reply-To: <20100131125805.GA44187@stack.nl> Date: Sun, 31 Jan 2010 22:53:24 +0100 Message-Id: <707EBC5E-E5C1-4A23-A829-7283495191AA@iem.pw.edu.pl> References: <4D59045B-6B03-440C-BCCC-C9C171621475@iem.pw.edu.pl> <20100131125805.GA44187@stack.nl> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: clamav-milter devel-20100125-exp at volt.iem.pw.edu.pl X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jilles Tjoelker , des@freebsd.org Subject: Re: Problem with sftp server, static linking, pam and nss_ldap. 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, 31 Jan 2010 21:53:28 -0000 --Apple-Mail-7-1052279468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2010-01-31, at 13:58, Jilles Tjoelker wrote: > On Sun, Jan 31, 2010 at 12:37:19PM +0100, Piotr Buli=C5=84ski wrote: >> As you can see, it works great with dynamic linking, but if it's = build with=20 >> static linking it can't get user information from LDAP database. >=20 > Correct, NSS only works from dynamically-linked executables. I didn't know that. >> During the upgrade to OpenSSH 5.3p1 = /head/secure/libexec/sftp-server/Makefile file changed a little bit: >>=20 >> revision 181111, Fri Aug 1 02:48:36 2008 UTC ---> revision 197679, = Thu Oct 1 17:12:52 2009 UTC >> LDADD=3D -lssh -lcrypt -lcrypto -lz ---> LDADD=3D -lcrypt = -lcrypto -lz -static -lssh >=20 >> So I've tried to build sftp-server without -static switch, but it >> result in failure like below: >=20 >> {volt}-{/usr/src/secure/libexec/sftp-server}% sudo make >> Warning: Object directory not changed from original = /usr/src/secure/libexec/sftp-server >> cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -c = /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server.c >> cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -c = /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-common.c >> cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -c = /usr/src/secure/libexec/sftp-server/../../../crypto/openssh/sftp-server-ma= in.c >> cc -O2 -pipe -fomit-frame-pointer -march=3Dopteron = -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include = ssh_namespace.h -std=3Dgnu99 -Wno-pointer-sign -o sftp-server = sftp-server.o sftp-common.o sftp-server-main.o -lssh -lcrypt -lcrypto = -lz >> /usr/lib/libssh.so: undefined reference to `ssh_add_recv_bytes' >> /usr/lib/libssh.so: undefined reference to `ssh_roaming_write' >> /usr/lib/libssh.so: undefined reference to `ssh_roaming_read' >> *** Error code 1 >=20 >> Stop in /usr/src/secure/libexec/sftp-server. >> {volt}-{/usr/src/secure/libexec/sftp-server}%=20 >=20 >> Do you have any idea how to make it works? >=20 > Apparently something broke so that sftp-server cannot link to libssh > dynamically, even though scp and ssh can still use it. > By changing the line in secure/libexec/sftp-server/Makefile to >=20 > LDADD=3D -lcrypt -lcrypto -lz -Wl,-static -lssh -Wl,-call_shared >=20 > it links only libssh and its dependencies statically, which may be > enough to fix your problem. This still links quite a lot more than > libssh statically, I am not happy with it at all. Thanks a lot! This solved my problem for now. I'll be testing it this week. Will you put this "patch" to the source tree of CURRENT (or maybe it's good only as a temporary solution)? Thanks again! Regards --=20 Piotr Buli=C5=84ski Informatyka na Wydziale Elektrycznym Politechnika Warszawska --Apple-Mail-7-1052279468-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 07:10:06 2010 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 05EA5106568D; Mon, 1 Feb 2010 07:10:06 +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 CEEB68FC1D; Mon, 1 Feb 2010 07:10:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o117A4go040698; Mon, 1 Feb 2010 02:10:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o117A4Ub040689; Mon, 1 Feb 2010 07:10:04 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 1 Feb 2010 07:10:04 GMT Message-Id: <201002010710.o117A4Ub040689@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 sparc64/sun4v 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: Mon, 01 Feb 2010 07:10:06 -0000 TB --- 2010-02-01 05:57:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-01 05:57:15 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-02-01 05:57:15 - cleaning the object tree TB --- 2010-02-01 05:57:28 - cvsupping the source tree TB --- 2010-02-01 05:57:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-02-01 05:57:53 - building world TB --- 2010-02-01 05:57:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-01 05:57:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-01 05:57:53 - TARGET=sun4v TB --- 2010-02-01 05:57:53 - TARGET_ARCH=sparc64 TB --- 2010-02-01 05:57:53 - TZ=UTC TB --- 2010-02-01 05:57:53 - __MAKE_CONF=/dev/null TB --- 2010-02-01 05:57:53 - cd /src TB --- 2010-02-01 05:57:53 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 1 05:57:54 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Feb 1 06:53:27 UTC 2010 TB --- 2010-02-01 06:53:27 - generating LINT kernel config TB --- 2010-02-01 06:53:27 - cd /src/sys/sun4v/conf TB --- 2010-02-01 06:53:27 - /usr/bin/make -B LINT TB --- 2010-02-01 06:53:27 - building LINT kernel TB --- 2010-02-01 06:53:27 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-01 06:53:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-01 06:53:27 - TARGET=sun4v TB --- 2010-02-01 06:53:27 - TARGET_ARCH=sparc64 TB --- 2010-02-01 06:53:27 - TZ=UTC TB --- 2010-02-01 06:53:27 - __MAKE_CONF=/dev/null TB --- 2010-02-01 06:53:27 - cd /src TB --- 2010-02-01 06:53:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 1 06:53:27 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sun4v/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sun4v/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c cc1: warnings being treated as errors /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c: In function 'siba_pci_write_multi_1': /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:710: warning: passing argument 4 of 'bus_space_write_multi_1' discards qualifiers from pointer target type /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c: In function 'siba_pci_write_multi_2': /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:723: warning: passing argument 4 of 'bus_space_write_multi_2' discards qualifiers from pointer target type /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c: In function 'siba_pci_write_multi_4': /src/sys/modules/siba_bwn/../../dev/siba/siba_core.c:736: warning: passing argument 4 of 'bus_space_write_multi_4' discards qualifiers from pointer target type *** Error code 1 Stop in /src/sys/modules/siba_bwn. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-01 07:10:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-01 07:10:04 - ERROR: failed to build lint kernel TB --- 2010-02-01 07:10:04 - 3454.22 user 647.59 system 4368.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 07:52:42 2010 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 A933E106568F; Mon, 1 Feb 2010 07:52:42 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6735F8FC12; Mon, 1 Feb 2010 07:52:42 +0000 (UTC) Received: from screw (f054135102.adsl.alicedsl.de [78.54.135.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id 9A8811084C4B; Mon, 1 Feb 2010 08:52:40 +0100 (CET) Date: Mon, 1 Feb 2010 08:52:39 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@screw.home.yamagi.org To: Alexander Motin In-Reply-To: <4B62F2B0.2030704@FreeBSD.org> Message-ID: References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <4B62F2B0.2030704@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Pack of CAM improvements 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, 01 Feb 2010 07:52:42 -0000 On Fri, 29 Jan 2010, Alexander Motin wrote: >>> What's interesting, is that Asus board with the same chipset doesn't >>> expose MSI support at all: >>> >>> ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >>> rev=0x00 hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'SB700 SATA Controller [AHCI mode]' >>> class = mass storage >>> subclass = SATA >>> bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xfbcffc00, size 1024, enabled >>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>> cap 12[70] = SATA Index-Data Pair >>> >> >> PCI revision register of SMBus device (0:20:0) gives a particular revision of SB7x0. >> SB700 RPR document (section 7.11) says that MSI capability should be disabled if >> the revision is 0x39 or 0x3a, it should be enabled for newer revisions (0x3b, 03c). > > VIA uses ISA bridge to identify chipset, ATI (as you said) - SMBus. > Hell! Why not to do it properly? > >> Those who like to experiment with potentially dangerous things may try playing >> with bit 16 of PCI config register 0x50 of SATA controller device. > > I would prefer it was done by BIOS. Probably ASUS did it, as my board > has 0x3a. Okay, so it's just another case of cheap hardware that's broken by design. Nevertheless thanks for your help. :) Ciao Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 08:45:20 2010 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 AA8D51065679 for ; Mon, 1 Feb 2010 08:45:20 +0000 (UTC) (envelope-from boogie@lazybytes.org) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6948FC21 for ; Mon, 1 Feb 2010 08:45:19 +0000 (UTC) Received: from mail.lazybytes.org (mail.lazybytes.org [195.54.209.3]) by mail.lazybytes.org (Postfix) with ESMTPSA id D756874BE; Mon, 1 Feb 2010 11:42:07 +0300 (MSK) Date: Mon, 1 Feb 2010 11:42:07 +0300 (MSK) From: Sergey Vinogradov X-X-Sender: boogie@odin.rinet.ru To: Rui Paulo In-Reply-To: <37797801-B178-485B-A5E1-CA42CA0619DB@freebsd.org> Message-ID: References: <37797801-B178-485B-A5E1-CA42CA0619DB@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.lazybytes.org); Mon, 01 Feb 2010 11:42:07 +0300 (MSK) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Atheros AR9285 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: Mon, 01 Feb 2010 08:45:20 -0000 On Fri, 29 Jan 2010, Rui Paulo wrote: RP> On 29 Jan 2010, at 11:00, Rui Paulo wrote: RP> RP> > Hi, RP> > I just committed initial support for the Atheros AR9285 wireless chipset found on many netbooks. The driver still has issues but it's stable enough for general use (don't expect good throughput, though). RP> > RP> > I'm looking for testers to make sure I didn't break anything else in the Atheros driver. RP> > If you notice any problems with ath on a recent kernel, please inform me. RP> RP> Patch against stable/8: RP> RP> http://people.freebsd.org/~rpaulo/ar9285_stable_8.diff RP> RP> -- RP> Rui Paulo RP> RP> _______________________________________________ RP> freebsd-current@freebsd.org mailing list RP> http://lists.freebsd.org/mailman/listinfo/freebsd-current RP> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" RP> Hi, First of all, thank you for spending your time on this, it's a really good job. I've ran into some problems with both CURRENT and patched 8-STABLE on the first try (I have ath0 interface running, it seems to associate with AP, but it doesn't seem to transmit any frames), however, my overall system doesn't feel well right now, so I don't think that's a driver's issue. I'll give it a try on a fresh CURRENT installation soon, report will follow. -- wbr, Boo From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 09:23:58 2010 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 DBD04106566B; Mon, 1 Feb 2010 09:23:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8D08FC1A; Mon, 1 Feb 2010 09:23:56 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4DF5C45E97; Mon, 1 Feb 2010 10:23:51 +0100 (CET) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3A69B45CD9; Mon, 1 Feb 2010 10:23:37 +0100 (CET) Date: Mon, 1 Feb 2010 10:23:34 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20100201092334.GB1743@garage.freebsd.pl> References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: <20100130114451.GB1660@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , kib@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. 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, 01 Feb 2010 09:23:59 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote: > Maybe I'll add how I understand what's going on: >=20 > GEOM calls destroy_dev() while holding the topology lock. >=20 > Destroy_dev() wants to destroy device, but can't because there are > threads that still have it open. >=20 > The threads can't close it, because to close it they need the topology > lock. >=20 > The deadlock is quite obvious, IMHO. Guys, changing destroy_dev() to destroy_dev_sched() in geom_dev.c fixes the problem for me (at least it makes race window so small that I can't reproduce it). Is there anyone who isn't happy with such a change? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLZp2WForvXbEpPzQRAn35AJ90hK1k5qJWXM68Y6u2ZFu7WP3E+gCgmqPv 6sEImmRWQ3kLgUElGxoKA04= =o3JH -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 09:37:26 2010 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 9EF67106568B; Mon, 1 Feb 2010 09:37:26 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swipnet.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0CA8FC14; Mon, 1 Feb 2010 09:37:24 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=997wlf2A6M0A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=u5rT9GMeTmaUgEkNOPQA:9 a=24a_TDEfwaxw72SPfbkA:7 a=f3IbZGw5FHbRJNiLlJho4bEFI7kA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 628255019; Mon, 01 Feb 2010 10:37:23 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 1 Feb 2010 10:35:57 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <4B636812.8060403@FreeBSD.org> <20100130114451.GB1660@garage.freebsd.pl> <20100201092334.GB1743@garage.freebsd.pl> In-Reply-To: <20100201092334.GB1743@garage.freebsd.pl> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002011035.57862.hselasky@c2i.net> Cc: kib@freebsd.org, Alexander Motin , FreeBSD-Current , Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. 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, 01 Feb 2010 09:37:26 -0000 On Monday 01 February 2010 10:23:34 Pawel Jakub Dawidek wrote: > On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote: > > Maybe I'll add how I understand what's going on: > > > > GEOM calls destroy_dev() while holding the topology lock. > > > > Destroy_dev() wants to destroy device, but can't because there are > > threads that still have it open. > > > > The threads can't close it, because to close it they need the topology > > lock. > > > > The deadlock is quite obvious, IMHO. > > Guys, changing destroy_dev() to destroy_dev_sched() in geom_dev.c fixes > the problem for me (at least it makes race window so small that I can't > reproduce it). Is there anyone who isn't happy with such a change? > Are you sure there are no races or leftover resources that can be accessed by the callbacks of the device being destroyed? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 10:11:23 2010 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 8AB7F106568F; Mon, 1 Feb 2010 10:11:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 105978FC26; Mon, 1 Feb 2010 10:11:20 +0000 (UTC) Received: by fxm27 with SMTP id 27so6636fxm.3 for ; Mon, 01 Feb 2010 02:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=4C+2dtjr7H34TXYZfwwNTmVG0F2U2MYsuZpisFty3SM=; b=dl+Bqdy8svR7JQS+qjOjJsWyFEijYaG8Ciwvt0LC8BruY2S52ofNQe3gQm2058Cir0 SiZ8Emii+MJiBEktQyPHlViGZHS76oBI57X5GX7vsrh9DDAbBuCDeDusN7HcqgMOoN+V dCOA8xZLMP5Dsg5atplQ1LYGNgxfJHI09Otx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=gCmtiqrEIlMBDg1i/PP5Z/EThk7GTRI1ZQms33WQSrRhpoAQqZMh4gDRra9gLkOs7E NplRVh+dIbRU9jlF+talHEFnd3thurh14Fn6//5/Btqi4x9kgt/Pu21qmCSgU4ev9nza gm5ypXwZAhg5H8xCLOOgii9IYZl46eZ6hJVN8= Received: by 10.102.182.6 with SMTP id e6mr2415630muf.63.1265018476992; Mon, 01 Feb 2010 02:01:16 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id s10sm14582853muh.29.2010.02.01.02.01.15 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 02:01:15 -0800 (PST) Sender: Alexander Motin Message-ID: <4B66A669.2070406@FreeBSD.org> Date: Mon, 01 Feb 2010 12:01:13 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <20100201092334.GB1743@garage.freebsd.pl> In-Reply-To: <20100201092334.GB1743@garage.freebsd.pl> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------020500080902030103010007" Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , kib@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. 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, 01 Feb 2010 10:11:23 -0000 This is a multi-part message in MIME format. --------------020500080902030103010007 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Pawel Jakub Dawidek wrote: > On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote: >> Maybe I'll add how I understand what's going on: >> >> GEOM calls destroy_dev() while holding the topology lock. >> >> Destroy_dev() wants to destroy device, but can't because there are >> threads that still have it open. >> >> The threads can't close it, because to close it they need the topology >> lock. >> >> The deadlock is quite obvious, IMHO. > > Guys, changing destroy_dev() to destroy_dev_sched() in geom_dev.c fixes > the problem for me (at least it makes race window so small that I can't > reproduce it). Is there anyone who isn't happy with such a change? Have you done some locking there? Because my system crashes with such straightforward change, when g_dev_close() called after geom node being destroyed. Attached patch fixes that for me, but I have doubts that it is complete. There is still seems to be a race with new I/O requests and ioctl's, that are not protected by topology lock. At least if devfs code doesn't handle it somehow. -- Alexander Motin --------------020500080902030103010007 Content-Type: text/plain; name="geom_dev.destroy.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="geom_dev.destroy.patch" --- geom_dev.c.prev 2010-01-30 05:22:36.000000000 +0200 +++ geom_dev.c 2010-02-01 11:55:53.000000000 +0200 @@ -184,10 +184,13 @@ g_dev_close(struct cdev *dev, int flags, struct g_consumer *cp; int error, r, w, e, i; + g_topology_lock(); gp = dev->si_drv1; cp = dev->si_drv2; - if (gp == NULL || cp == NULL) + if (gp == NULL || cp == NULL) { + g_topology_unlock(); return(ENXIO); + } g_trace(G_T_ACCESS, "g_dev_close(%s, %d, %d, %p)", gp->name, flags, fmt, td); r = flags & FREAD ? -1 : 0; @@ -197,7 +200,6 @@ g_dev_close(struct cdev *dev, int flags, #else e = 0; #endif - g_topology_lock(); if (dev->si_devsw == NULL) error = ENXIO; /* We were orphaned */ else @@ -435,7 +437,10 @@ g_dev_orphan(struct g_consumer *cp) set_dumper(NULL); /* Destroy the struct cdev *so we get no more requests */ - destroy_dev(dev); + gp->softc = NULL; + dev->si_drv1 = NULL; + dev->si_drv2 = NULL; + destroy_dev_sched(dev); /* Wait for the cows to come home */ while (cp->nstart != cp->nend) --------------020500080902030103010007-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 10:15:20 2010 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 95FBC106566B for ; Mon, 1 Feb 2010 10:15:20 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE888FC0A for ; Mon, 1 Feb 2010 10:15:19 +0000 (UTC) Received: by fxm27 with SMTP id 27so10114fxm.3 for ; Mon, 01 Feb 2010 02:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rTsF+aZIlaus3xBe/zyGQ82OY5/fGYRxaGVNhQO7cSo=; b=VGiu4xfGhp7d/LTilpZXYcgWQBgEdzsrnZ/b8c/U3GgChP8ERKjqGyZlAlH0qSk/he /d3B4dQ92EkyamIHSNzSNRstneObsBAeFzMgrjiGLsTm8qg5+LRuIP430ZKvWm97t328 dnnJDBANV72YXFCcOOlBfecl1CA+KoEPA5NEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V2TrI30qMwmQ0Lji+UrDXUn1IMcuhwQXg2Vqao+5rBDVeFLsfkzFUd/NHxtc5JoFFA OeLUTo2x6BcGMi/4MoLqcx+gfHA6w83iVc68cNffAaGj8LyHP7oIiPZkj/f56OsgMcSG NEMinLa9Vi9IzS4XZ+t0wV8P66UiWQHz/3Lk0= MIME-Version: 1.0 Received: by 10.223.97.219 with SMTP id m27mr990934fan.16.1265019317255; Mon, 01 Feb 2010 02:15:17 -0800 (PST) In-Reply-To: <20100131213630.854ff720.bsdlisten@gmail.com> References: <20100131213630.854ff720.bsdlisten@gmail.com> Date: Mon, 1 Feb 2010 11:15:17 +0100 Message-ID: <4e6cba831002010215h781e757yf5b329ff305fc2be@mail.gmail.com> From: Giovanni Trematerra To: Aioanei Rares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: kernel fault when doing some I/O 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, 01 Feb 2010 10:15:20 -0000 On Sun, Jan 31, 2010 at 8:36 PM, Aioanei Rares wrote: > > Hi everyone, > > I've been getting this several times but only now I could get a screensho= t (it's a X-less VirtualBox host) > The message I'm getting is the following : > > lock order reversal : > =A01st 0xffffff800a4c8698 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c= :2559 > =A02nd 0xffffff0002b81000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_di= rhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _sx_xlock() at _sx_lock+0x55 > ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > ufsdirhash_add() at ufsdirhash_add+0x19 > ufs_direnter() at ufs_direnter+0x889 > ufs_makeinode() at ufs_makeinode+0x38a > VOP_CREATE_APV() at VOP_CREATE_APV+0x8d > vn_open_cred() at vn_open_cred+0x473 > kern_openat() at kern_openat+0x179 > syscall() at syscall+0x1ae > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (5, FreeBSD ELF64, open), rip =3D 0x800c1095c, rsp =3D 0x7fff= ff1f9b38, rbp =3D 0x800e0a900 --- > That isn't a kernel fault but a LOR. you can read more on LOR at http://sources.zabbadoz.net/freebsd/lor.html. You got it because you compile your kernel with WITNESS option. Bye -- Gianni From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 11:08:55 2010 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 30DBF10656E4; Mon, 1 Feb 2010 11:08:55 +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 6720F8FC20; Mon, 1 Feb 2010 11:08:54 +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 o11B8Z5S048484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 13:08:50 +0200 (EET) (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.3/8.14.3) with ESMTP id o11AhSRO031239; Mon, 1 Feb 2010 12:43:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o11AhSXE031205; Mon, 1 Feb 2010 12:43:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Feb 2010 12:43:28 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20100201104328.GD15587@deviant.kiev.zoral.com.ua> References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <20100201092334.GB1743@garage.freebsd.pl> <4B66A669.2070406@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xB0nW4MQa6jZONgY" Content-Disposition: inline In-Reply-To: <4B66A669.2070406@FreeBSD.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=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. 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, 01 Feb 2010 11:08:55 -0000 --xB0nW4MQa6jZONgY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 01, 2010 at 12:01:13PM +0200, Alexander Motin wrote: > Pawel Jakub Dawidek wrote: > > On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote: > >> Maybe I'll add how I understand what's going on: > >> > >> GEOM calls destroy_dev() while holding the topology lock. > >> > >> Destroy_dev() wants to destroy device, but can't because there are > >> threads that still have it open. > >> > >> The threads can't close it, because to close it they need the topology > >> lock. > >> > >> The deadlock is quite obvious, IMHO. > >=20 > > Guys, changing destroy_dev() to destroy_dev_sched() in geom_dev.c fixes > > the problem for me (at least it makes race window so small that I can't > > reproduce it). Is there anyone who isn't happy with such a change? >=20 > Have you done some locking there? Because my system crashes with such > straightforward change, when g_dev_close() called after geom node being > destroyed. Attached patch fixes that for me, but I have doubts that it > is complete. There is still seems to be a race with new I/O requests and > ioctl's, that are not protected by topology lock. At least if devfs code > doesn't handle it somehow. Devfs prevents new threads from entering cdevsw methods after destroy_dev_sched() is called. It is driver responsibility to take care about other code pathes that may access cdev. --xB0nW4MQa6jZONgY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktmsFAACgkQC3+MBN1Mb4hNzQCg2m16aRPIrgVnePtnZj0tCrYU AqYAoJZ0iO6X7ivDvPxIgD5rdeEuLje/ =7DeA -----END PGP SIGNATURE----- --xB0nW4MQa6jZONgY-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 12:03:40 2010 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 47302106566B; Mon, 1 Feb 2010 12:03:40 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id 5E27A8FC0C; Mon, 1 Feb 2010 12:03:38 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id C314D1C15463; Mon, 1 Feb 2010 13:03:37 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.6.166]) by mail.m-online.net (Postfix) with ESMTP id B3BAF90201; Mon, 1 Feb 2010 13:03:37 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.6.166]) (amavisd-new, port 10024) with ESMTP id og8or0fok5Is; Mon, 1 Feb 2010 13:03:35 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-58-177.dynamic.mnet-online.de [93.104.58.177]) by mail.mnet-online.de (Postfix) with ESMTP; Mon, 1 Feb 2010 13:03:35 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id F34062C660; Mon, 1 Feb 2010 13:03:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id E253F2C65F; Mon, 1 Feb 2010 13:03:34 +0100 (CET) Date: Mon, 1 Feb 2010 13:03:34 +0100 (CET) From: Michael Reifenberger To: Alexander Motin In-Reply-To: <4B66A669.2070406@FreeBSD.org> Message-ID: References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <20100201092334.GB1743@garage.freebsd.pl> <4B66A669.2070406@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1741261931-1265025814=:79943" Cc: FreeBSD-Current Subject: Odd ada(4) failures when trying using USB scanner 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, 01 Feb 2010 12:03:40 -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. --0-1741261931-1265025814=:79943 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, I'm using -current as of r202157. When attaching an epson USB scanner and trying to `scanimage -L` I get a freeze for some time and the following console logs: ... ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 ata1: setting up DMA failed ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 ata1: setting up DMA failed ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 ata1: setting up DMA failed ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 ata1: setting up DMA failed ahcich1: Timeout on slot 19 ahcich1: is 04000000 cs 00080000 ss 00080000 rs 00080000 tfd 451 serr 00400000 ahcich2: Timeout on slot 20 ahcich2: is 04000000 cs 00100000 ss 00100000 rs 00100000 tfd 451 serr 00400000 ahcich3: Timeout on slot 18 ahcich3: is 04000000 cs 00040000 ss 00000000 rs 00040000 tfd 451 serr 00400000 ahcich3: Timeout on slot 18 ahcich3: is 00000000 cs 00040000 ss 00000000 rs 00040000 tfd c0 serr 00000001 ugen2.2: at usbus2 (disconnected) ahcich2: Timeout on slot 20 ahcich2: is 00000000 cs 00300000 ss 00000000 rs 00300000 tfd c0 serr 00000001 ahcich0: Timeout on slot 24 ahcich0: is 04000000 cs 01000000 ss 01000000 rs 01000000 tfd 451 serr 00400000 mfi0: 32975 (318240776s/0x0008/info) - Battery charge complete ahcich0: Timeout on slot 24 ahcich0: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd c0 serr 00000001 ... After the timeouts the system is usable again. It seems the new ATA-CAM subsystem doesn't like the CAM or USB scanning for known scanners. Any clues how to fix? Thanks id advance! Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com --0-1741261931-1265025814=:79943 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; name=dmesg.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=dmesg.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMTAgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOS4wLUNVUlJFTlQg IzEgcjIwMjE1N006IFR1ZSBKYW4gMTIgMTg6NDU6NTUgQ0VUIDIwMTANCiAg ICByb290QGZzLnJlaWZlbmJlcmdlci5jb206L3Vzci9vYmovdXNyL3NyYy9z eXMvZnMgYW1kNjQNClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwDQpDUFU6IEFNRCBQaGVub20odG0pIElJIFg0 IDkwNWUgUHJvY2Vzc29yICgyNTAwLjE1LU1IeiBLOC1jbGFzcyBDUFUpDQog IE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4MTAwZjQyICBTdGVw cGluZyA9IDINCiAgRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBT RSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxD TU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4N CiAgRmVhdHVyZXMyPTB4ODAyMDA5PFNTRTMsTU9OLENYMTYsUE9QQ05UPg0K ICBBTUQgRmVhdHVyZXM9MHhlZTUwMDgwMDxTWVNDQUxMLE5YLE1NWCssRkZY U1IsUGFnZTFHQixSRFRTQ1AsTE0sM0ROb3chKywzRE5vdyE+DQogIEFNRCBG ZWF0dXJlczI9MHgzN2ZmPExBSEYsQ01QLFNWTSxFeHRBUElDLENSOCxBQk0s U1NFNEEsTUFTLFByZWZldGNoLE9TVlcsSUJTLFNLSU5JVCxXRFQ+DQogIFRT QzogUC1zdGF0ZSBpbnZhcmlhbnQNCnJlYWwgbWVtb3J5ICA9IDQyOTQ5Njcy OTYgKDQwOTYgTUIpDQphdmFpbCBtZW1vcnkgPSAzODQ1NzU4OTc2ICgzNjY3 IE1CKQ0KQUNQSSBBUElDIFRhYmxlOiA8MDkyMzA5IEFQSUMxNDI5Pg0KRnJl ZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBD UFVzDQpGcmVlQlNEL1NNUDogMSBwYWNrYWdlKHMpIHggNCBjb3JlKHMpDQog Y3B1MCAoQlNQKTogQVBJQyBJRDogIDANCiBjcHUxIChBUCk6IEFQSUMgSUQ6 ICAxDQogY3B1MiAoQVApOiBBUElDIElEOiAgMg0KIGNwdTMgKEFQKTogQVBJ QyBJRDogIDMNCkFDUEkgV2FybmluZzogT3B0aW9uYWwgZmllbGQgUG0yQ29u dHJvbEJsb2NrIGhhcyB6ZXJvIGFkZHJlc3Mgb3IgbGVuZ3RoOiAgICAgICAg MCAgICAgICAwLzEgKDIwMDkxMjE0L3RiZmFkdC02NTUpDQppb2FwaWMwIDxW ZXJzaW9uIDIuMT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkDQprYmQxIGF0 IGtiZG11eDANCmFjcGkwOiA8MDkyMzA5IFJTRFQxNDI5PiBvbiBtb3RoZXJi b2FyZA0KYWNwaTA6IFtJVEhSRUFEXQ0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAo Zml4ZWQpDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVlMDAwMDAsIDEwMDAg KDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIGZmYjgwMDAwLCA4 MDAwMCAoMykgZmFpbGVkDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVjMTAw MDAsIDIwICgzKSBmYWlsZWQNCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBh MDAwMCAoMykgZmFpbGVkDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAw LCBjZmYwMDAwMCAoMykgZmFpbGVkDQpBQ1BJIEhQRVQgdGFibGUgd2Fybmlu ZzogU2VxdWVuY2UgaXMgbm9uLXplcm8gKDIpDQpUaW1lY291bnRlciAiQUNQ SS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDANCmFj cGlfdGltZXIwOiA8MzItYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0 IDB4ODA4LTB4ODBiIG9uIGFjcGkwDQphY3BpX2hwZXQwOiA8SGlnaCBQcmVj aXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNm ZiBvbiBhY3BpMA0KVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMx ODE4MCBIeiBxdWFsaXR5IDkwMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMQ0KdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+ IHBvcnQgMHhkMDAwLTB4ZDBmZiBtZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZm LDB4ZmU5ZjAwMDAtMHhmZTlmZmZmZiwweGZlODAwMDAwLTB4ZmU4ZmZmZmYg aXJxIDE4IGF0IGRldmljZSA1LjAgb24gcGNpMQ0KcGNpMTogPG11bHRpbWVk aWEsIEhEQT4gYXQgZGV2aWNlIDUuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQ0K cGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTkgYXQgZGV2aWNl IDMuMCBvbiBwY2kwDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMg0K cGNpYjM6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2ky DQpwY2kzOiA8UENJIGJ1cz4gb24gcGNpYjMNCm1maTA6IDxEZWxsIFBFUkMg NS9pPiBtZW0gMHhmZGVmMDAwMC0weGZkZWZmZmZmLDB4ZmVhZTAwMDAtMHhm ZWFmZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDE0LjAgb24gcGNpMw0KbWZpMDog TWVnYXJhaWQgU0FTIGRyaXZlciBWZXIgMy4wMCANCm1maTA6IDMyOTQxICgz MTgyNDAxNjlzLzB4MDAyMC9pbmZvKSAtIFNodXRkb3duIGNvbW1hbmQgcmVj ZWl2ZWQgZnJvbSBob3N0DQptZmkwOiAzMjk0MiAoYm9vdCArIDBzLzB4MDAy MC9pbmZvKSAtIEZpcm13YXJlIGluaXRpYWxpemF0aW9uIHN0YXJ0ZWQgKFBD SSBJRCAwMDE1LzEwMjgvMWYwMy8xMDI4KQ0KbWZpMDogMzI5NDMgKGJvb3Qg KyAwcy8weDAwMjAvaW5mbykgLSBGaXJtd2FyZSB2ZXJzaW9uIDEuMTIuMTUw LTA0MzgNCm1maTA6IDMyOTQ0IChib290ICsgMXMvMHgwMDA4L2luZm8pIC0g QmF0dGVyeSBQcmVzZW50DQptZmkwOiAzMjk0NSAoYm9vdCArIDFzLzB4MDAy MC9pbmZvKSAtIFBhY2thZ2UgdmVyc2lvbiA3LjAuMS0wMDUxDQptZmkwOiAz Mjk0NiAoYm9vdCArIDFzLzB4MDAyMC9pbmZvKSAtIEJvYXJkIFJldmlzaW9u IEDAXF5fXF5C9EFcXlxcXkINCm1maTA6IDMyOTQ3IChib290ICsgN3MvMHgw MDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDAwKGUweGZmL3MwKQ0KbWZpMDog MzI5NDggKGJvb3QgKyA3cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQg MDAoZTB4ZmYvczApIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBw b3J0TWFwPTAwLCBzYXNBZGRyPTEyMjEwMDAwMDAwMDAwMDAsMDAwMDAwMDAw MDAwMDAwMA0KbWZpMDogMzI5NDkgKGJvb3QgKyA3cy8weDAwMDIvV0FSTikg LSBQRCAwMChlMHhmZi9zMCkgaXMgbm90IGEgY2VydGlmaWVkIGRyaXZlDQpt ZmkwOiAzMjk1MCAoYm9vdCArIDdzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVk OiBQRCAwMShlMHhmZi9zMSkNCm1maTA6IDMyOTUxIChib290ICsgN3MvMHgw MDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDAxKGUweGZmL3MxKSBJbmZvOiBl bmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMSwgc2FzQWRkcj0x MjIxMDAwMDAxMDAwMDAwLDAwMDAwMDAwMDAwMDAwMDANCm1maTA6IDMyOTUy IChib290ICsgN3MvMHgwMDAyL1dBUk4pIC0gUEQgMDEoZTB4ZmYvczEpIGlz IG5vdCBhIGNlcnRpZmllZCBkcml2ZQ0KbWZpMDogMzI5NTMgKGJvb3QgKyA3 cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDIoZTB4ZmYvczIpDQpt ZmkwOiAzMjk1NCAoYm9vdCArIDdzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVk OiBQRCAwMihlMHhmZi9zMikgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBl PTAsIHBvcnRNYXA9MDIsIHNhc0FkZHI9MTIyMTAwMDAwMjAwMDAwMCwwMDAw MDAwMDAwMDAwMDAwDQptZmkwOiAzMjk1NSAoYm9vdCArIDdzLzB4MDAwMi9X QVJOKSAtIFBEIDAyKGUweGZmL3MyKSBpcyBub3QgYSBjZXJ0aWZpZWQgZHJp dmUNCm1maTA6IDMyOTU2IChib290ICsgN3MvMHgwMDAyL2luZm8pIC0gSW5z ZXJ0ZWQ6IFBEIDAzKGUweGZmL3MzKQ0KbWZpMDogMzI5NTcgKGJvb3QgKyA3 cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDMoZTB4ZmYvczMpIElu Zm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAzLCBzYXNB ZGRyPTEyMjEwMDAwMDMwMDAwMDAsMDAwMDAwMDAwMDAwMDAwMA0KbWZpMDog MzI5NTggKGJvb3QgKyA3cy8weDAwMDIvV0FSTikgLSBQRCAwMyhlMHhmZi9z MykgaXMgbm90IGEgY2VydGlmaWVkIGRyaXZlDQptZmkwOiAzMjk1OSAoYm9v dCArIDdzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwNChlMHhmZi9z NCkNCm1maTA6IDMyOTYwIChib290ICsgN3MvMHgwMDAyL2luZm8pIC0gSW5z ZXJ0ZWQ6IFBEIDA0KGUweGZmL3M0KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2Nz aVR5cGU9MCwgcG9ydE1hcD0wNCwgc2FzQWRkcj0xMjIxMDAwMDA0MDAwMDAw LDAwMDAwMDAwMDAwMDAwMDANCm1maTA6IDMyOTYxIChib290ICsgN3MvMHgw MDAyL1dBUk4pIC0gUEQgMDQoZTB4ZmYvczQpIGlzIG5vdCBhIGNlcnRpZmll ZCBkcml2ZQ0KbWZpMDogMzI5NjIgKGJvb3QgKyA3cy8weDAwMDIvaW5mbykg LSBJbnNlcnRlZDogUEQgMDUoZTB4ZmYvczUpDQptZmkwOiAzMjk2MyAoYm9v dCArIDdzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwNShlMHhmZi9z NSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDUs IHNhc0FkZHI9MTIyMTAwMDAwNTAwMDAwMCwwMDAwMDAwMDAwMDAwMDAwDQpt ZmkwOiAzMjk2NCAoYm9vdCArIDdzLzB4MDAwMi9XQVJOKSAtIFBEIDA1KGUw eGZmL3M1KSBpcyBub3QgYSBjZXJ0aWZpZWQgZHJpdmUNCm1maTA6IDMyOTY1 IChib290ICsgN3MvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA2KGUw eGZmL3M2KQ0KbWZpMDogMzI5NjYgKGJvb3QgKyA3cy8weDAwMDIvaW5mbykg LSBJbnNlcnRlZDogUEQgMDYoZTB4ZmYvczYpIEluZm86IGVuY2xQZD1mZmZm LCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA2LCBzYXNBZGRyPTEyMjEwMDAwMDYw MDAwMDAsMDAwMDAwMDAwMDAwMDAwMA0KbWZpMDogMzI5NjcgKGJvb3QgKyA3 cy8weDAwMDIvV0FSTikgLSBQRCAwNihlMHhmZi9zNikgaXMgbm90IGEgY2Vy dGlmaWVkIGRyaXZlDQptZmkwOiAzMjk2OCAoYm9vdCArIDdzLzB4MDAwMi9p bmZvKSAtIEluc2VydGVkOiBQRCAwNyhlMHhmZi9zNykNCm1maTA6IDMyOTY5 IChib290ICsgN3MvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA3KGUw eGZmL3M3KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1h cD0wNywgc2FzQWRkcj0xMjIxMDAwMDA3MDAwMDAwLDAwMDAwMDAwMDAwMDAw MDANCm1maTA6IDMyOTcwIChib290ICsgN3MvMHgwMDAyL1dBUk4pIC0gUEQg MDcoZTB4ZmYvczcpIGlzIG5vdCBhIGNlcnRpZmllZCBkcml2ZQ0KbWZpMDog MzI5NzEgKDMxODI0MDE5OHMvMHgwMDIwL2luZm8pIC0gVGltZSBlc3RhYmxp c2hlZCBhcyAwMS8zMS8xMCAgODowMzoxODsgKDggc2Vjb25kcyBzaW5jZSBw b3dlciBvbikNCm1maTA6IDMyOTcyICgzMTgyNDAyNTZzLzB4MDAwOC9pbmZv KSAtIEJhdHRlcnkgdGVtcGVyYXR1cmUgaXMgbm9ybWFsDQptZmkwOiBbSVRI UkVBRF0NCnBjaWI0OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjIg b24gcGNpMg0KcGNpNDogPFBDSSBidXM+IG9uIHBjaWI0DQpwY2liNTogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgNC4wIG9uIHBj aTANCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1DQpyZTA6IDxSZWFs VGVrIDgxNjgvODE2OEIvODE2OEMvODE2OENQLzgxNjhELzgxNjhEUC84MTEx Qi84MTExQy84MTExQ1AvODExMURQIFBDSWUgR2lnYWJpdCBFdGhlcm5ldD4g cG9ydCAweGU4MDAtMHhlOGZmIG1lbSAweGZlYmZmMDAwLTB4ZmViZmZmZmYs MHhmZGZmMDAwMC0weGZkZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9u IHBjaTUNCnJlMDogVXNpbmcgMSBNU0kgbWVzc2FnZXMNCnJlMDogQ2hpcCBy ZXYuIDB4M2MwMDAwMDANCnJlMDogTUFDIHJldi4gMHgwMDQwMDAwMA0KbWlp YnVzMDogPE1JSSBidXM+IG9uIHJlMA0KcmdlcGh5MDogPFJUTDgxNjlTLzgx MTBTLzgyMTFCIG1lZGlhIGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMA0K cmdlcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEw MGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bw0K cmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDoxODphZToxOTo0NA0KcmUw OiBbRklMVEVSXQ0KYWhjaTA6IDxBVEkgSVhQNzAwIEFIQ0kgU0FUQSBjb250 cm9sbGVyPiBwb3J0IDB4YzAwMC0weGMwMDcsMHhiMDAwLTB4YjAwMywweGEw MDAtMHhhMDA3LDB4OTAwMC0weDkwMDMsMHg4MDAwLTB4ODAwZiBtZW0gMHhm ZTdmZmMwMC0weGZlN2ZmZmZmIGlycSAyMiBhdCBkZXZpY2UgMTcuMCBvbiBw Y2kwDQphaGNpMDogW0lUSFJFQURdDQphaGNpMDogQUhDSSB2MS4xMCB3aXRo IDQgM0dicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBzdXBwb3J0ZWQNCmFo Y2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMA0K YWhjaWNoMDogW0lUSFJFQURdDQphaGNpY2gxOiA8QUhDSSBjaGFubmVsPiBh dCBjaGFubmVsIDEgb24gYWhjaTANCmFoY2ljaDE6IFtJVEhSRUFEXQ0KYWhj aWNoMjogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIGFoY2kwDQph aGNpY2gyOiBbSVRIUkVBRF0NCmFoY2ljaDM6IDxBSENJIGNoYW5uZWw+IGF0 IGNoYW5uZWwgMyBvbiBhaGNpMA0KYWhjaWNoMzogW0lUSFJFQURdDQpvaGNp MDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZTdm ZTAwMC0weGZlN2ZlZmZmIGlycSAxNiBhdCBkZXZpY2UgMTguMCBvbiBwY2kw DQpvaGNpMDogW0lUSFJFQURdDQp1c2J1czA6IDxPSENJIChnZW5lcmljKSBV U0IgY29udHJvbGxlcj4gb24gb2hjaTANCm9oY2kxOiA8T0hDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZlN2ZkMDAwLTB4ZmU3ZmRmZmYg aXJxIDE2IGF0IGRldmljZSAxOC4xIG9uIHBjaTANCm9oY2kxOiBbSVRIUkVB RF0NCnVzYnVzMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBv biBvaGNpMQ0KZWhjaTA6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRy b2xsZXI+IG1lbSAweGZlN2ZmODAwLTB4ZmU3ZmY4ZmYgaXJxIDE3IGF0IGRl dmljZSAxOC4yIG9uIHBjaTANCmVoY2kwOiBbSVRIUkVBRF0NCmVoY2kwOiBB TUQgU0I2MDAvNzAwIHF1aXJrIGFwcGxpZWQNCnVzYnVzMjogRUhDSSB2ZXJz aW9uIDEuMA0KdXNidXMyOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250 cm9sbGVyPiBvbiBlaGNpMA0Kb2hjaTI6IDxPSENJIChnZW5lcmljKSBVU0Ig Y29udHJvbGxlcj4gbWVtIDB4ZmU3ZmMwMDAtMHhmZTdmY2ZmZiBpcnEgMTgg YXQgZGV2aWNlIDE5LjAgb24gcGNpMA0Kb2hjaTI6IFtJVEhSRUFEXQ0KdXNi dXMzOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2ky DQpvaGNpMzogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0g MHhmZTdmYjAwMC0weGZlN2ZiZmZmIGlycSAxOCBhdCBkZXZpY2UgMTkuMSBv biBwY2kwDQpvaGNpMzogW0lUSFJFQURdDQp1c2J1czQ6IDxPSENJIChnZW5l cmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTMNCmVoY2kxOiA8RUhDSSAo Z2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZTdmZjQwMC0w eGZlN2ZmNGZmIGlycSAxOSBhdCBkZXZpY2UgMTkuMiBvbiBwY2kwDQplaGNp MTogW0lUSFJFQURdDQplaGNpMTogQU1EIFNCNjAwLzcwMCBxdWlyayBhcHBs aWVkDQp1c2J1czU6IEVIQ0kgdmVyc2lvbiAxLjANCnVzYnVzNTogPEVIQ0kg KGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTENCnBjaTA6 IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDIwLjAgKG5vIGRyaXZl ciBhdHRhY2hlZCkNCmF0YXBjaTA6IDxBVEkgSVhQNzAwLzgwMCBVRE1BMTMz IGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgx NzcsMHgzNzYsMHhmZjAwLTB4ZmYwZiBhdCBkZXZpY2UgMjAuMSBvbiBwY2kw DQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMA0KYXRhMDogW0lU SFJFQURdDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMA0KYXRh MTogW0lUSFJFQURdDQpwY2kwOiA8bXVsdGltZWRpYSwgSERBPiBhdCBkZXZp Y2UgMjAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KaXNhYjA6IDxQQ0ktSVNB IGJyaWRnZT4gYXQgZGV2aWNlIDIwLjMgb24gcGNpMA0KaXNhMDogPElTQSBi dXM+IG9uIGlzYWIwDQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0 IGRldmljZSAyMC40IG9uIHBjaTANCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI2DQpvaGNpNDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVy PiBtZW0gMHhmZTdmYTAwMC0weGZlN2ZhZmZmIGlycSAxOCBhdCBkZXZpY2Ug MjAuNSBvbiBwY2kwDQpvaGNpNDogW0lUSFJFQURdDQp1c2J1czY6IDxPSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTQNCmFjcGlfYnV0 dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTANCmF0cnRjMDogPEFUIHJl YWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEgOCBvbiBhY3BpMA0K dWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2Zm IGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTANCnVhcnQwOiBbRklMVEVSXQ0K ZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBwb3J0IDB4 M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwDQpmZGMwOiBb RklMVEVSXQ0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQy KT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFU IEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQprYmQwIGF0IGF0a2JkMA0K YXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0KYXRrYmQwOiBbSVRIUkVBRF0NCnBz bTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMA0KcHNtMDogW0dJ QU5ULUxPQ0tFRF0NCnBzbTA6IFtJVEhSRUFEXQ0KcHNtMDogbW9kZWwgSW50 ZWxsaU1vdXNlLCBkZXZpY2UgSUQgMw0KY3B1MDogPEFDUEkgQ1BVPiBvbiBh Y3BpMA0KYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBv biBjcHUwDQpod3BzdGF0ZTA6IDxDb29sYG4nUXVpZXQgMi4wPiBvbiBjcHUw DQpjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpjcHUyOiA8QUNQSSBDUFU+ IG9uIGFjcGkwDQpjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQpzYzA6IDxT eXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0KdmdhMDog PEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAw eGEwMDAwLTB4YmZmZmYgb24gaXNhMA0KcHBjMDogY2Fubm90IHJlc2VydmUg SS9PIHBvcnQgcmFuZ2UNCnVhcnQxOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4g YXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwDQp1YXJ0MTogW0ZJ TFRFUl0NClpGUyBmaWxlc3lzdGVtIHZlcnNpb24gMw0KWkZTIHN0b3JhZ2Ug cG9vbCB2ZXJzaW9uIDE0DQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAw MCBtc2VjDQprZXJuLmlwYy5zaG1tYXhwZ3MgaXMgbm93IGNhbGxlZCBrZXJu LmlwYy5zaG1hbGwhDQpXYWl0aW5nIDIgc2Vjb25kcyBmb3IgU0NTSSBkZXZp Y2VzIHRvIHNldHRsZW1maTA6IDMyOTczICgzMTgyNDAyNTZzLzB4MDAwOC9p bmZvKSAtIEN1cnJlbnQgY2FwYWNpdHkgb2YgdGhlIGJhdHRlcnkgaXMgYWJv dmUgdGhyZXNob2xkDQoNCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNC IHYxLjANCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVz YnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQp1c2J1czM6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wDQp1c2J1czQ6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wDQp1c2J1czU6IDQ4ME1icHMgSGlnaCBTcGVlZCBV U0IgdjIuMA0KdXNidXM2OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMA0K dWdlbjAuMTogPEFUST4gYXQgdXNidXMwDQp1aHViMDogPEFUSSBPSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwDQp1Z2VuMS4xOiA8QVRJPiBhdCB1c2J1czENCnVodWIxOiA8QVRJ IE9IQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAxPiBvbiB1c2J1czENCnVnZW4yLjE6IDxBVEk+IGF0IHVzYnVzMg0KdWh1 YjI6IDxBVEkgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYnVzMg0KdWdlbjMuMTogPEFUST4gYXQgdXNi dXMzDQp1aHViMzogPEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzDQp1Z2VuNC4xOiA8QVRJ PiBhdCB1c2J1czQNCnVodWI0OiA8QVRJIE9IQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQNCnVnZW41 LjE6IDxBVEk+IGF0IHVzYnVzNQ0KdWh1YjU6IDxBVEkgRUhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVz NQ0KdWdlbjYuMTogPEFUST4gYXQgdXNidXM2DQp1aHViNjogPEFUSSBPSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXM2DQp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQNCnVodWIwOiAzIHBvcnRzIHdpdGggMyByZW1vdmFibGUs IHNlbGYgcG93ZXJlZA0KdWh1YjE6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkDQp1aHViMzogMyBwb3J0cyB3aXRoIDMgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQNCnVodWI0OiAzIHBvcnRzIHdpdGggMyByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KbWZpZDA6IDxNRkkgTG9naWNhbCBEaXNr PiBvbiBtZmkwDQptZmlkMDogOTUzMzQ0TUIgKDE5NTI0NDg1MTIgc2VjdG9y cykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1hbA0KbWZpZDE6IDxNRkkgTG9n aWNhbCBEaXNrPiBvbiBtZmkwDQptZmlkMTogOTUzMzQ0TUIgKDE5NTI0NDg1 MTIgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1hbA0KbWZpZDI6 IDxNRkkgTG9naWNhbCBEaXNrPiBvbiBtZmkwDQptZmlkMjogOTUzMzQ0TUIg KDE5NTI0NDg1MTIgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1h bA0KbWZpZDM6IDxNRkkgTG9naWNhbCBEaXNrPiBvbiBtZmkwDQptZmlkMzog OTUzMzQ0TUIgKDE5NTI0NDg1MTIgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycg aXMgb3B0aW1hbA0KbWZpZDQ6IDxNRkkgTG9naWNhbCBEaXNrPiBvbiBtZmkw DQptZmlkNDogOTUzMzQ0TUIgKDE5NTI0NDg1MTIgc2VjdG9ycykgUkFJRCB2 b2x1bWUgJycgaXMgb3B0aW1hbA0KbWZpZDU6IDxNRkkgTG9naWNhbCBEaXNr PiBvbiBtZmkwDQptZmlkNTogOTUzMzQ0TUIgKDE5NTI0NDg1MTIgc2VjdG9y cykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1hbA0KbWZpZDY6IDxNRkkgTG9n aWNhbCBEaXNrPiBvbiBtZmkwDQptZmlkNjogOTUzMzQ0TUIgKDE5NTI0NDg1 MTIgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1hbA0KbWZpZDc6 IDxNRkkgTG9naWNhbCBEaXNrPiBvbiBtZmkwDQptZmlkNzogOTUzMzQ0TUIg KDE5NTI0NDg1MTIgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1h bA0KdWh1YjI6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkDQp1aHViNTogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQNCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAg bHVuIDANCmFkYTA6IDxTQU1TVU5HIEhEMTAzVUogMUFBMDExMDQ+IEFUQS03 IFNBVEEgMi54IGRldmljZQ0KYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJz IChTQVRBIDIueCwgVURNQTYsIFBJTyBzaXplIDgxOTJieXRlcykNCmFkYTA6 IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KYWRhMDogOTUzODY5TUIgKDE5 NTM1MjUxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykN CmFkYTEgYXQgYWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAN CmFkYTE6IDxTVDMxMDAwMzQwQVMgU0QxQT4gQVRBLTggU0FUQSAyLnggZGV2 aWNlDQphZGExOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBV RE1BNiwgUElPIHNpemUgODE5MmJ5dGVzKQ0KYWRhMTogQ29tbWFuZCBRdWV1 ZWluZyBlbmFibGVkDQphZGExOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIg Ynl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQ0KYWRhMiBhdCBhaGNp Y2gyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBsdW4gMA0KYWRhMjogPFNBTVNV TkcgSEQxMDNVSiAxQUEwMTEwND4gQVRBLTcgU0FUQSAyLnggZGV2aWNlDQph ZGEyOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwg UElPIHNpemUgODE5MmJ5dGVzKQ0KYWRhMjogQ29tbWFuZCBRdWV1ZWluZyBl bmFibGVkDQphZGEyOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBz ZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQ0KYWRhMyBhdCBhaGNpY2gzIGJ1 cyAwIHNjYnVzMyB0YXJnZXQgMCBsdW4gMA0KYWRhMzogPFNBTVNVTkcgSEQx MDNVSiAxQUEwMTEwND4gQVRBLTcgU0FUQSAyLnggZGV2aWNlDQphZGEzOiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIHNp emUgODE5MmJ5dGVzKQ0KYWRhMzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVk DQphZGEzOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3Jz OiAxNkggNjNTL1QgMTYzODNDKQ0KYWRhNCBhdCBhdGExIGJ1cyAwIHNjYnVz NSB0YXJnZXQgMCBsdW4gMA0KYWRhNDogPFNUMzEwMDAzNDBBUyBTRDFBPiBB VEEtOCBTQVRBIDIueCBkZXZpY2UNCmFkYTQ6IDE1MC4wMDBNQi9zIHRyYW5z ZmVycyAoU0FUQSAwLngsIFVETUE2LCBQSU8gc2l6ZSA4MTkyYnl0ZXMpDQph ZGE0OiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAx NkggNjNTL1QgMTYzODNDKQ0KYWRhNSBhdCBhdGExIGJ1cyAwIHNjYnVzNSB0 YXJnZXQgMSBsdW4gMA0KYWRhNTogPFNBTVNVTkcgSEQxMDNVSiAxQUEwMTEw ND4gQVRBLTcgU0FUQSAyLnggZGV2aWNlDQphZGE1OiAxNTAuMDAwTUIvcyB0 cmFuc2ZlcnMgKFNBVEEgMC54LCBVRE1BNiwgUElPIHNpemUgODE5MmJ5dGVz KQ0KYWRhNTogOTUzODY5TUIgKDE5NTM1MjUxNjggNTEyIGJ5dGUgc2VjdG9y czogMTZIIDYzUy9UIDE2MzgzQykNClNNUDogQVAgQ1BVICMyIExhdW5jaGVk IQ0KU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhDQpTTVA6IEFQIENQVSAjMSBM YXVuY2hlZCENCnVnZW4wLjI6IDxmaWRpPiBhdCB1c2J1czANCnVmdGRpMDog PHVzYiBzZXJpYWwgY29udmVydGVyPiBvbiB1c2J1czANClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzMg0KdWdlbjIuMjogPEVQU09OPiBhdCB1c2J1 czINClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOngvUk9PVC9mYnNk OQ0KdWdlbjAuMzogPGZ0ZGk+IGF0IHVzYnVzMA0KdWZ0ZGkxOiA8dXNiIHNl cmlhbCBjb252ZXJ0ZXI+IG9uIHVzYnVzMA0KbWZpMDogMzI5NzQgKDMxODI0 MDMyMXMvMHgwMDA4L2luZm8pIC0gQmF0dGVyeSBzdGFydGVkIGNoYXJnaW5n DQp3YXJuaW5nOiBLTEQgJy9ib290L21vZHVsZXMvdmJveGRydi5rbycgaXMg bmV3ZXIgdGhhbiB0aGUgbGlua2VyLmhpbnRzIGZpbGUNCnZib3hkcnY6IGZB c3luYz0wIG9mZk1pbj0weGJmNSBvZmZNYXg9MHgxNmRhDQp3YXJuaW5nOiBL TEQgJy9ib290L21vZHVsZXMvdmJveG5ldGFkcC5rbycgaXMgbmV3ZXIgdGhh biB0aGUgbGlua2VyLmhpbnRzIGZpbGUNCnZib3huZXQwOiBFdGhlcm5ldCBh ZGRyZXNzOiAwYTowMDoyNzowMDowMDowMA0KcmUwOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVANCmF0YTE6IEZBSUxVUkUgLSBvZGQtc2l6ZWQgRE1BIHRy YW5zZmVyIGF0dGVtcHQgNSAlIDINCmF0YTE6IHNldHRpbmcgdXAgRE1BIGZh aWxlZA0KYXRhMTogRkFJTFVSRSAtIG9kZC1zaXplZCBETUEgdHJhbnNmZXIg YXR0ZW1wdCA1ICUgMg0KYXRhMTogc2V0dGluZyB1cCBETUEgZmFpbGVkDQph dGExOiBGQUlMVVJFIC0gb2RkLXNpemVkIERNQSB0cmFuc2ZlciBhdHRlbXB0 IDUgJSAyDQphdGExOiBzZXR0aW5nIHVwIERNQSBmYWlsZWQNCmF0YTE6IEZB SUxVUkUgLSBvZGQtc2l6ZWQgRE1BIHRyYW5zZmVyIGF0dGVtcHQgNSAlIDIN CmF0YTE6IHNldHRpbmcgdXAgRE1BIGZhaWxlZA0KYWhjaWNoMTogVGltZW91 dCBvbiBzbG90IDE5DQphaGNpY2gxOiBpcyAwNDAwMDAwMCBjcyAwMDA4MDAw MCBzcyAwMDA4MDAwMCBycyAwMDA4MDAwMCB0ZmQgNDUxIHNlcnIgMDA0MDAw MDANCmFoY2ljaDI6IFRpbWVvdXQgb24gc2xvdCAyMA0KYWhjaWNoMjogaXMg MDQwMDAwMDAgY3MgMDAxMDAwMDAgc3MgMDAxMDAwMDAgcnMgMDAxMDAwMDAg dGZkIDQ1MSBzZXJyIDAwNDAwMDAwDQphaGNpY2gzOiBUaW1lb3V0IG9uIHNs b3QgMTgNCmFoY2ljaDM6IGlzIDA0MDAwMDAwIGNzIDAwMDQwMDAwIHNzIDAw MDAwMDAwIHJzIDAwMDQwMDAwIHRmZCA0NTEgc2VyciAwMDQwMDAwMA0KYWhj aWNoMzogVGltZW91dCBvbiBzbG90IDE4DQphaGNpY2gzOiBpcyAwMDAwMDAw MCBjcyAwMDA0MDAwMCBzcyAwMDAwMDAwMCBycyAwMDA0MDAwMCB0ZmQgYzAg c2VyciAwMDAwMDAwMQ0KdWdlbjIuMjogPEVQU09OPiBhdCB1c2J1czIgKGRp c2Nvbm5lY3RlZCkNCmFoY2ljaDI6IFRpbWVvdXQgb24gc2xvdCAyMA0KYWhj aWNoMjogaXMgMDAwMDAwMDAgY3MgMDAzMDAwMDAgc3MgMDAwMDAwMDAgcnMg MDAzMDAwMDAgdGZkIGMwIHNlcnIgMDAwMDAwMDENCmFoY2ljaDA6IFRpbWVv dXQgb24gc2xvdCAyNA0KYWhjaWNoMDogaXMgMDQwMDAwMDAgY3MgMDEwMDAw MDAgc3MgMDEwMDAwMDAgcnMgMDEwMDAwMDAgdGZkIDQ1MSBzZXJyIDAwNDAw MDAwDQptZmkwOiAzMjk3NSAoMzE4MjQwNzc2cy8weDAwMDgvaW5mbykgLSBC YXR0ZXJ5IGNoYXJnZSBjb21wbGV0ZQ0KYWhjaWNoMDogVGltZW91dCBvbiBz bG90IDI0DQphaGNpY2gwOiBpcyAwMDAwMDAwMCBjcyAwMTAwMDAwMCBzcyAw MDAwMDAwMCBycyAwMTAwMDAwMCB0ZmQgYzAgc2VyciAwMDAwMDAwMQ0KdWdl bjIuMjogPEVQU09OPiBhdCB1c2J1czINCmF0YTE6IEZBSUxVUkUgLSBvZGQt c2l6ZWQgRE1BIHRyYW5zZmVyIGF0dGVtcHQgNSAlIDINCmF0YTE6IHNldHRp bmcgdXAgRE1BIGZhaWxlZA0KYXRhMTogRkFJTFVSRSAtIG9kZC1zaXplZCBE TUEgdHJhbnNmZXIgYXR0ZW1wdCA1ICUgMg0KYXRhMTogc2V0dGluZyB1cCBE TUEgZmFpbGVkDQphaGNpY2gwOiBUaW1lb3V0IG9uIHNsb3QgMTQNCmFoY2lj aDA6IGlzIDA0MDAwMDAwIGNzIDAwMDA0MDAwIHNzIDAwMDAwMDAwIHJzIDAw MDA0MDAwIHRmZCA0NTEgc2VyciAwMDQwMDAwMA0KYWhjaWNoMzogVGltZW91 dCBvbiBzbG90IDEyDQphaGNpY2gzOiBpcyAwNDAwMDAwMCBjcyAwMDAwMTAw MCBzcyAwMDAwMTAwMCBycyAwMDAwMTAwMCB0ZmQgNDUxIHNlcnIgMDA0MDAw MDANCmFoY2ljaDM6IFRpbWVvdXQgb24gc2xvdCAxMg0KYWhjaWNoMzogaXMg MDAwMDAwMDAgY3MgMDAwMDEwMDAgc3MgMDAwMDAwMDAgcnMgMDAwMDEwMDAg dGZkIGMwIHNlcnIgMDAwMDAwMDENCmFoY2ljaDI6IFRpbWVvdXQgb24gc2xv dCAzDQphaGNpY2gyOiBpcyAwNDAwMDAwMCBjcyAwMDAwMDAwOCBzcyAwMDAw MDAwOCBycyAwMDAwMDAwOCB0ZmQgNDUxIHNlcnIgMDA0MDAwMDANCmFoY2lj aDI6IFRpbWVvdXQgb24gc2xvdCAzDQphaGNpY2gyOiBpcyAwMDAwMDAwMCBj cyAwMDAwMDAwOCBzcyAwMDAwMDAwMCBycyAwMDAwMDAwOCB0ZmQgYzAgc2Vy ciAwMDAwMDAwMQ0KYWhjaWNoMTogVGltZW91dCBvbiBzbG90IDINCmFoY2lj aDE6IGlzIDA0MDAwMDAwIGNzIDAwMDAwMDA0IHNzIDAwMDAwMDA0IHJzIDAw MDAwMDA0IHRmZCA0NTEgc2VyciAwMDQwMDAwMA0KYWhjaWNoMDogVGltZW91 dCBvbiBzbG90IDE0DQphaGNpY2gwOiBpcyAwMDAwMDAwMCBjcyAwMDAwNDAw MCBzcyAwMDAwNDAwMCBycyAwMDAwNDAwMCB0ZmQgYzAgc2VyciAwMDAwMDAw MQ0KdWdlbjIuMjogPEVQU09OPiBhdCB1c2J1czIgKGRpc2Nvbm5lY3RlZCkN CnBpZCA3ODUzMSAoeGZjZTQtc2V0dGluZ3MtaGVscCksIHVpZCAwOiBleGl0 ZWQgb24gc2lnbmFsIDExIChjb3JlIGR1bXBlZCkNCg== --0-1741261931-1265025814=:79943-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 12:09:55 2010 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 7661B1065670; Mon, 1 Feb 2010 12:09:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.tele2.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id D185B8FC16; Mon, 1 Feb 2010 12:09:54 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=XTckEXG7zQcA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Ot3eOd6uw-Efqo6JB_YA:9 a=1BSRghzyXqqj5wSZSe7wY3OAKCgA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1166892244; Mon, 01 Feb 2010 13:09:52 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 1 Feb 2010 13:08:22 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <4B636812.8060403@FreeBSD.org> <4B66A669.2070406@FreeBSD.org> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201002011308.22069.hselasky@c2i.net> Cc: Alexander Motin Subject: Re: Odd ada(4) failures when trying using USB scanner 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, 01 Feb 2010 12:09:55 -0000 On Monday 01 February 2010 13:03:34 Michael Reifenberger wrote: > Hi, > I'm using -current as of r202157. > Hi, What is the output from vmstat -i ? Sounds like a generic interrupt problem. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 12:12:14 2010 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 889BE1065695 for ; Mon, 1 Feb 2010 12:12:14 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id 49E5F8FC1D for ; Mon, 1 Feb 2010 12:12:14 +0000 (UTC) Received: by pzk14 with SMTP id 14so1215834pzk.3 for ; Mon, 01 Feb 2010 04:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=bEGN3zpW7FJwx5eiYnctdlacXb3xZWzEgNoxSVwac9o=; b=sIld6OhN1tqFULVHsIz20Niqrv3teeQSmWYzSZ3gQOLryryZ33l4D5jSt8gkdMLj4n +yxGigehyjmDRaZmhIczUV0lomuXK2Wh8jVtLZsVWxNJ1u2kLSsE5Atao31G6dx9eG1C mMYG1p5AWfGlGTDbD5Ut17D5QrONO1JzLWwWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YiQzqalq7RNcAvImLRB2SCr1KwGpCYhD+0IrfbfROy2qq6zRBN0VKeQ9S2shtA+8NF dUdDs8PuqBsdAYE8c43rOMBf/ajZgzibJ8MYVAbqTH1MLbFFNN6Xb/CP4YQr8lPnKce/ qR27lCjj/G03uB/1mnnoTZHpSLKbIDB7J1C+Y= MIME-Version: 1.0 Received: by 10.140.55.16 with SMTP id d16mr3063962rva.287.1265026333027; Mon, 01 Feb 2010 04:12:13 -0800 (PST) Date: Mon, 1 Feb 2010 10:12:13 -0200 Message-ID: <1e31c7981002010412r2bc00d9bof3693fe5c0bfce@mail.gmail.com> From: Vinicius Abrahao To: gremlin@portal-to-web.de, freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Port build error on -current 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, 01 Feb 2010 12:12:14 -0000 Hi folks, I'm getting this error when I try to recompile this port (security/pam_mkhomedir): ------------------------------- => SHA256 Checksum OK for pam_mkhomedir-0.1.tar.gz. ===> Patching for pam_mkhomedir-0.1 ===> Configuring for pam_mkhomedir-0.1 ===> Building for pam_mkhomedir-0.1 "/usr/share/mk/bsd.compat.mk", line 35: warning: NOINSTALLLIB is deprecated in favour of NO_INSTALLLIB "/usr/share/mk/bsd.compat.mk", line 35: warning: NOPROFILE is deprecated in favour of NO_PROFILE Warning: Object directory not changed from original /usr/ports/security/pam_mkhomedir/work/pam_mkhomedir-0.1 cc -march=native -mtune=native -O2 -march=nocona -std=gnu99 -fstack-protector -c pam_mkhomedir.c In file included from pam_mkhomedir.c:61: /usr/include/utmp.h:2:2: error: #error " has been replaced by " *** Error code 1 Stop in /usr/ports/security/pam_mkhomedir/work/pam_mkhomedir-0.1. *** Error code 1 Stop in /usr/ports/security/pam_mkhomedir. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20100201-84816-5snl0x-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=pam_mkhomedir-0.1 UPGRADE_PORT_VER=0.1 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! security/pam_mkhomedir (pam_mkhomedir-0.1) (unknown build error) ------------------------------- The simple substitution on pam_mkhomedir.c solve the problem. ------------------------------- *** pam_mkhomedir.c.orig Mon Feb 1 10:06:32 2010 --- pam_mkhomedir.c Mon Feb 1 10:06:48 2010 *************** *** 60,62 **** #include ! #include #include --- 60,62 ---- #include ! #include #include This problem does NOT occurs on 8-stable. Thanks for your attention, Vinicius Schmidt From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 12:18:38 2010 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 ABD00106566C for ; Mon, 1 Feb 2010 12:18:38 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 33A048FC1C for ; Mon, 1 Feb 2010 12:18:37 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so25030fgg.13 for ; Mon, 01 Feb 2010 04:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6xr8AovTV10ho5vRzdB5x95dOd4t7mvb2ybenzCr24E=; b=g+SgQtzEh/U2BPutML0iSwJT1Ed8N5IeTnXNtmKiZcRYpCugv5s3UyD18OYInJZWcb FGQ/M22s0HlVh1IX7MaNebLOCG1K2obXwrAQOPPS+AeSUpW/AIArixm6UBiG6zp3/h2N GDHXMJSRYRNpKpkIHxP09AucB/rCSbEeOdPsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=pbgMC0EOpXTfvdfwLBprddHQKJUIwMrDgihWbc+8M7vKU9yqcffcPVWYimdfmQToza mJ8Kr1blW6RjRkvxlbFHOoUqe3Hwdlp0J3/rVZk99GA8ZwlmfE8yYxBzhu1Dr2Mh3bMM voRd5nklTyrUSwhoy4Xn8voo+0U76fHfXVhvE= Received: by 10.103.76.37 with SMTP id d37mr2339126mul.105.1265026710426; Mon, 01 Feb 2010 04:18:30 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y37sm18977268mug.8.2010.02.01.04.18.29 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 04:18:29 -0800 (PST) Sender: Alexander Motin Message-ID: <4B66C689.2000906@FreeBSD.org> Date: Mon, 01 Feb 2010 14:18:17 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Michael Reifenberger References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <20100201092334.GB1743@garage.freebsd.pl> <4B66A669.2070406@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Odd ada(4) failures when trying using USB scanner 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, 01 Feb 2010 12:18:38 -0000 Michael Reifenberger wrote: > I'm using -current as of r202157. > > When attaching an epson USB scanner and trying to `scanimage -L` > I get a freeze for some time and the following console logs: > ... > ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 > ata1: setting up DMA failed I would say that scanner application tries to probe all CAM devices, looking for scanner. While doing it, it uses SCSI/ATAPI commands with odd-sized transfer sizes. It causes errors from ata(4) and triggers bug in IXP700 AHCI controller. Odd-sized requests are generally not supported by ATA/SATA. Second problem is in work now. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 12:54:14 2010 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 DA7081065679 for ; Mon, 1 Feb 2010 12:54:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9692A8FC24 for ; Mon, 1 Feb 2010 12:54:14 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 835E91FFC22; Mon, 1 Feb 2010 12:54:13 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 60229844A0; Mon, 1 Feb 2010 13:54:13 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jilles Tjoelker References: <4D59045B-6B03-440C-BCCC-C9C171621475@iem.pw.edu.pl> <20100131125805.GA44187@stack.nl> Date: Mon, 01 Feb 2010 13:54:13 +0100 In-Reply-To: <20100131125805.GA44187@stack.nl> (Jilles Tjoelker's message of "Sun, 31 Jan 2010 13:58:05 +0100") Message-ID: <861vh56rre.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Piotr =?utf-8?Q?Buli=C5=84ski?= , freebsd-current@freebsd.org Subject: Re: Problem with sftp server, static linking, pam and nss_ldap. 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, 01 Feb 2010 12:54:14 -0000 Jilles Tjoelker writes: > Apparently something broke so that sftp-server cannot link to libssh > dynamically, even though scp and ssh can still use it. Uh, that was an experiment that was committed by mistake. I was about to say "just remove -static", but that uncovers other issues. I'll look into it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 12:58:03 2010 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 41D2B1065679 for ; Mon, 1 Feb 2010 12:58:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id F3C668FC13 for ; Mon, 1 Feb 2010 12:58:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0673C1FFC28; Mon, 1 Feb 2010 12:58:02 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D61BF84498; Mon, 1 Feb 2010 13:58:01 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jilles Tjoelker References: <4D59045B-6B03-440C-BCCC-C9C171621475@iem.pw.edu.pl> <20100131125805.GA44187@stack.nl> <861vh56rre.fsf@ds4.des.no> Date: Mon, 01 Feb 2010 13:58:01 +0100 In-Reply-To: <861vh56rre.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 01 Feb 2010 13:54:13 +0100") Message-ID: <86wryx5d0m.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Piotr =?utf-8?Q?Buli=C5=84ski?= , freebsd-current@freebsd.org Subject: Re: Problem with sftp server, static linking, pam and nss_ldap. 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, 01 Feb 2010 12:58:03 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Jilles Tjoelker writes: > > Apparently something broke so that sftp-server cannot link to libssh > > dynamically, even though scp and ssh can still use it. > Uh, that was an experiment that was committed by mistake. I was about > to say "just remove -static", but that uncovers other issues. I'll look > into it. Index: Makefile =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 --- Makefile (revision 203341) +++ Makefile (working copy) @@ -5,8 +5,11 @@ MAN=3D sftp-server.8 CFLAGS+=3D-I${SSHDIR} -include ssh_namespace.h =20 +# required when linking with a dynamic libssh=20 +SRCS+=3D roaming_dummy.c + DPADD=3D ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} -LDADD=3D -lcrypt -lcrypto -lz -static -lssh +LDADD=3D -lcrypt -lcrypto -lz -lssh =20 .include =20 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 14:37:29 2010 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 D972E106566C; Mon, 1 Feb 2010 14:37:29 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 60AC08FC1A; Mon, 1 Feb 2010 14:37:29 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id D688B1C00236; Mon, 1 Feb 2010 15:37:27 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.6.166]) by mail.m-online.net (Postfix) with ESMTP id BEF11901B7; Mon, 1 Feb 2010 15:37:27 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.6.166]) (amavisd-new, port 10024) with ESMTP id kefryC6n4Y8w; Mon, 1 Feb 2010 15:37:26 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-58-177.dynamic.mnet-online.de [93.104.58.177]) by mail.mnet-online.de (Postfix) with ESMTP; Mon, 1 Feb 2010 15:37:26 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id E9E752C6F3; Mon, 1 Feb 2010 15:37:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id DBC382C6F0; Mon, 1 Feb 2010 15:37:25 +0100 (CET) Date: Mon, 1 Feb 2010 15:37:25 +0100 (CET) From: Michael Reifenberger To: Hans Petter Selasky In-Reply-To: <201002011308.22069.hselasky@c2i.net> Message-ID: References: <4B636812.8060403@FreeBSD.org> <4B66A669.2070406@FreeBSD.org> <201002011308.22069.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Odd ada(4) failures when trying using USB scanner 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, 01 Feb 2010 14:37:29 -0000 On Mon, 1 Feb 2010, Hans Petter Selasky wrote: > Date: Mon, 1 Feb 2010 13:08:22 +0100 > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: Michael Reifenberger , > Alexander Motin > Subject: Re: Odd ada(4) failures when trying using USB scanner > > On Monday 01 February 2010 13:03:34 Michael Reifenberger wrote: >> Hi, >> I'm using -current as of r202157. >> > > Hi, > > What is the output from vmstat -i ? > > Sounds like a generic interrupt problem. (fs)(root) vmstat -i interrupt total rate irq1: atkbd0 1868 0 irq4: uart0 1 0 irq15: ata1 2182948 19 irq16: ohci0 ohci1 13572280 123 irq17: mfi0 ehci0 7222359 65 irq18: ohci2 ohci3+ 3 0 irq22: ahci0 4327063 39 cpu0: timer 219657790 1999 irq256: re0 6471229 58 cpu2: timer 219647849 1999 cpu3: timer 219647836 1999 cpu1: timer 219647827 1999 Total 912379053 8305 Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 14:40:48 2010 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 9BEDF106566C; Mon, 1 Feb 2010 14:40:48 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id 220BC8FC0C; Mon, 1 Feb 2010 14:40:47 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 2341C1C0027D; Mon, 1 Feb 2010 15:40:47 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.6.166]) by mail.m-online.net (Postfix) with ESMTP id 17EBC901B7; Mon, 1 Feb 2010 15:40:47 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.6.166]) (amavisd-new, port 10024) with ESMTP id NNlKSjhfN3fI; Mon, 1 Feb 2010 15:40:44 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-58-177.dynamic.mnet-online.de [93.104.58.177]) by mail.mnet-online.de (Postfix) with ESMTP; Mon, 1 Feb 2010 15:40:44 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 297452C6FB; Mon, 1 Feb 2010 15:40:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 1F4902C6F8; Mon, 1 Feb 2010 15:40:44 +0100 (CET) Date: Mon, 1 Feb 2010 15:40:43 +0100 (CET) From: Michael Reifenberger To: Alexander Motin In-Reply-To: <4B66C689.2000906@FreeBSD.org> Message-ID: References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <20100201092334.GB1743@garage.freebsd.pl> <4B66A669.2070406@FreeBSD.org> <4B66C689.2000906@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current Subject: Re: Odd ada(4) failures when trying using USB scanner 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, 01 Feb 2010 14:40:48 -0000 On Mon, 1 Feb 2010, Alexander Motin wrote: > Date: Mon, 01 Feb 2010 14:18:17 +0200 > From: Alexander Motin > To: Michael Reifenberger > Cc: FreeBSD-Current > Subject: Re: Odd ada(4) failures when trying using USB scanner > > Michael Reifenberger wrote: >> I'm using -current as of r202157. >> >> When attaching an epson USB scanner and trying to `scanimage -L` >> I get a freeze for some time and the following console logs: >> ... >> ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 >> ata1: setting up DMA failed > > I would say that scanner application tries to probe all CAM devices, > looking for scanner. While doing it, it uses SCSI/ATAPI commands with > odd-sized transfer sizes. It causes errors from ata(4) and triggers bug > in IXP700 AHCI controller. Odd-sized requests are generally not > supported by ATA/SATA. Second problem is in work now. > Could odd-sized commands be prohibited/ignored by the driver then? Thanks for your work on ATA-CAM anyway! Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 16:46:34 2010 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 376421065672 for ; Mon, 1 Feb 2010 16:46:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by mx1.freebsd.org (Postfix) with ESMTP id B07C58FC0C for ; Mon, 1 Feb 2010 16:46:33 +0000 (UTC) Received: by gv-out-0910.google.com with SMTP id n29so184428gve.39 for ; Mon, 01 Feb 2010 08:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=h059malq4VJlPNPs48lPJ7GiwydFRwV+/i202krT0wU=; b=PYDQ8mQB866OuPxylFAaqpIVMdYZBlzzbpivDvAufHonX+llkK0BWbyDkYO2Otladk kM4tWlcoidnZZ899xOCKqsJ6brp3D72YLDnei713TaMoE3R4N5HS5DuTRmQFmoGCRtRA o+Z5IExvTAmFMrU88DIAzf76eq9O24DT3pKXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=HXh6nO7Q9BA0cBTJgY55pyk0F4bJQ4BHOV+pOmQjMd4rGrm9GDHBicGlJJ0QoXfb51 goEb8g9ndVCh8k6GPDh8ZSjfnTu8Iqtj2zBgClzmXL0raquu6vp7+Z0uONGjc2vXBJpk 7ZTMy2cp8XqG6GjQBxmjnvVuGOcks7DB8otnI= Received: by 10.103.85.4 with SMTP id n4mr2777820mul.128.1265042792351; Mon, 01 Feb 2010 08:46:32 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w5sm13647mue.52.2010.02.01.08.46.27 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 08:46:28 -0800 (PST) Sender: Alexander Motin Message-ID: <4B670557.1060506@FreeBSD.org> Date: Mon, 01 Feb 2010 18:46:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Diego Depaoli References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> <4B62DD46.4060908@FreeBSD.org> <83e5fb981001291525k6d533fdaj1611df806077d94f@mail.gmail.com> <4B636FCF.3080209@FreeBSD.org> <83e5fb981001301738p31c0643es3f5ee69d7f12c46a@mail.gmail.com> In-Reply-To: <83e5fb981001301738p31c0643es3f5ee69d7f12c46a@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements 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, 01 Feb 2010 16:46:34 -0000 Diego Depaoli wrote: > On Sat, Jan 30, 2010 at 12:31 AM, Alexander Motin wrote: >> If you have kernel.debug, you may use >> addr2line -e kernel.debug 0xc057efcd >> to get source line number, where it crashed. But stack back trace would >> be better. > I cannot dump: No dump device defined or unavailable, so, as usual, handwritten > > panic: g_read_data(): invalid length 3737169374 What was before that message? Any errors? Have you tried boot verbose? > cpuid=0 > KDB_ enter: panic > [thread pid 2 tid 100009] > Stopped at kdb_enter_+0x3a_ movl $0,kdb_why >> bt > Tracing pid 2 tid 100009 td 0xc69f5480 > kdb_enter(c088699c,c088699c,c087d5c3,c67e0bc0,0,...) at kdb_enter+0x3a > panic(c087d5c3,dec0adde,0,c6d62080,c08d6080,...) at panic+0x136 > g_read_data(c6d62080,4b15cc84,c1d2be92,dec0adde,0,...) at g_read_data+0x66 > g_label_taste(c08d6080,c6c72700,0,220,c6c72380,...) at g_label_taste+0x203 > g_new_provider_event(c6c72700,0,c087d181,d2,109,...) at > g_new_provider_event+0x9f > g_run_events(c093ea58,0,4c,c087c046,64,...) at g_run_events+0x31e > g_event_procbody(0,c67e0d38,c0881bc1,343,c696b550,...) at g_event_procbody+0x8a > fork_exit(c053f470,0,c67e0d38) at fork_ex+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc67e0d70, ebp = 0 --- -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 17:44:50 2010 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 A224410656C6 for ; Mon, 1 Feb 2010 17:44:50 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3326C8FC16 for ; Mon, 1 Feb 2010 17:44:49 +0000 (UTC) Received: by fxm27 with SMTP id 27so471694fxm.3 for ; Mon, 01 Feb 2010 09:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=AuFBtGZ5QQCTS6XDz89r2+xdU00tp2wc1OrSMzQ4cbI=; b=ZI+NPbRUxcxzMScOpXDytuvdb1nNFEQFSp4W4xDjab5h908RKeQJdVTlozFKVqtHr8 O32tTatxbc/aYQSxnOQGPPKAFtfRvRLbt5zJrl1Gy08V/XlUurwh3Fwhi8+8ObN9OiJ4 pIP5oJ14Bz+xuZrhy6f7XVHcpDOCBVnE/Be0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=umP4I2OlK5H5n9UgCa9d2IEn+LGr3Dd5hc8uLlh8WO2XRxw/bidGLjEsyuy20DhAsn zMmNwHTb2lGXM2s0uGTxM7h1GeVbxCuYU0XF1n8LU7RMDzoceVRe++Dx18G7HJLLIosP hKgKh085S9ljfRihk8vLKZAJX9smPcid6TVvQ= Received: by 10.87.21.36 with SMTP id y36mr354274fgi.17.1265046288961; Mon, 01 Feb 2010 09:44:48 -0800 (PST) Received: from greatsheep.chaos.base (e181044223.adsl.alicedsl.de [85.181.44.223]) by mx.google.com with ESMTPS id l19sm9210986fgb.25.2010.02.01.09.44.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 09:44:48 -0800 (PST) Date: Mon, 1 Feb 2010 18:44:46 +0100 From: Marc UBM Bocklet To: current@freebsd.org Message-Id: <20100201184446.2325c04e.ubm.freebsd@gmail.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.4; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Feb 2010 19:09:52 +0000 Cc: Subject: vidcontrol / resolution problems with latest current 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, 01 Feb 2010 17:44:50 -0000 Hiho! :-) Recently, I updated to the latest version of 9-current and found out that I cannot set my console resolution to 800x600 anymore. If I try, it just goes blank or shows a few coloured, garbled lines in the upper third of my monitor. Starting X11 blindly works, as does switching to X11. I'm suspecting the recent tty/xterm changes, but I am not sure. uname -a: FreeBSD xxx.yyy 9.0-CURRENT FreeBSD 9.0-CURRENT #17: Sat Jan 23 14:58:47 CET 2010 sheep@ubm.mine.nu:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 Relevant part of my rc.conf that I used to set console to 800x600: allscreens_flags="-g 100x37 VESA_800x600" Relevant kernel option that I use: # VESA support options VESA # raster display support for 800x600 resolution options SC_PIXEL_MODE Can anyone point me to a solution / is more info required? Bye, Marc From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 21:17:46 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B94FA106566B; Mon, 1 Feb 2010 21:17:45 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 1 Feb 2010 16:17:30 -0500 User-Agent: KMail/1.6.2 References: <20100201184446.2325c04e.ubm.freebsd@gmail.com> In-Reply-To: <20100201184446.2325c04e.ubm.freebsd@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_rT0ZLsydPD114mT" Message-Id: <201002011617.31527.jkim@FreeBSD.org> Cc: Marc UBM Bocklet Subject: Re: vidcontrol / resolution problems with latest current 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, 01 Feb 2010 21:17:46 -0000 --Boundary-00=_rT0ZLsydPD114mT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 01 February 2010 12:44 pm, Marc UBM Bocklet wrote: > Hiho! :-) > > Recently, I updated to the latest version of 9-current and found > out that I cannot set my console resolution to 800x600 anymore. If > I try, it just goes blank or shows a few coloured, garbled lines in > the upper third of my monitor. Starting X11 blindly works, as does > switching to X11. > > I'm suspecting the recent tty/xterm changes, but I am not sure. > > > uname -a: > > FreeBSD xxx.yyy 9.0-CURRENT FreeBSD 9.0-CURRENT #17: Sat > Jan 23 14:58:47 CET 2010 > sheep@ubm.mine.nu:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 > > > Relevant part of my rc.conf that I used to set console to 800x600: > > allscreens_flags="-g 100x37 VESA_800x600" > > > Relevant kernel option that I use: > > # VESA support > > options VESA > > # raster display support for 800x600 resolution > > options SC_PIXEL_MODE > > > Can anyone point me to a solution / is more info required? Hmm... The attached patch should restore the previous behavior. Jung-uk Kim --Boundary-00=_rT0ZLsydPD114mT Content-Type: text/plain; charset="iso-8859-1"; name="vesa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vesa.diff" --- sys/dev/fb/vesa.c +++ sys/dev/fb/vesa.c @@ -1322,7 +1322,7 @@ vesa_set_mode(video_adapter_t *adp, int mode) vesa_adp->va_window_gran = info.vi_window_gran; } vesa_adp->va_window_orig = 0; - vesa_adp->va_line_width = vesa_get_line_width(&info); + vesa_adp->va_line_width = vesa_bios_get_line_length(); vesa_adp->va_disp_start.x = 0; vesa_adp->va_disp_start.y = 0; #if VESA_DEBUG > 0 --Boundary-00=_rT0ZLsydPD114mT-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 22:04:23 2010 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 5FE2F1065695; Mon, 1 Feb 2010 22:04:23 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id B998A8FC0C; Mon, 1 Feb 2010 22:04:22 +0000 (UTC) Received: by fxm27 with SMTP id 27so740812fxm.3 for ; Mon, 01 Feb 2010 14:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AkF86sOM7aaR/c6Je89HQ7KOTLF0j9uwnBnVf6LVDPg=; b=s0TYbOrfi6kHfYk7BovuCG9MV0+sK2NLD7Ul39tcLqpw6dtIzXB6j0k1oPxpjjemlF ZHT2CLvjXHG0SMjbsbtxF73fj9FVp7n8pSx4+yFNnQMxRkVyezj5oZYHOpiydGG70odX R6KxAkJb9BXIpN1jPuZP2YSKNxH6b3RF/CmKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l3tBQjfisuAZS20KyPssRuHBaqKFx+P9MGTFuvEQZIS3pLwBrfq2sY9mq/I+If+Yfr 1pqQgD3EC35OG6NSGJkw5HJSKaV2P2xrjnAntqLv3YFMgq1/swBRYcr1Pc7HEaiAFDqt HU4Fv7uOmnNDdZacQ3ZM0V12VKBk37bZ46Bh8= MIME-Version: 1.0 Received: by 10.223.3.27 with SMTP id 27mr296054fal.8.1265061861686; Mon, 01 Feb 2010 14:04:21 -0800 (PST) In-Reply-To: <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> Date: Mon, 1 Feb 2010 23:04:21 +0100 Message-ID: <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> From: Giovanni Trematerra To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. 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, 01 Feb 2010 22:04:23 -0000 On Fri, Jan 29, 2010 at 9:12 PM, Brandon Gooch wrote: > On Fri, Jan 29, 2010 at 3:44 PM, Giovanni Trematerra > wrote: >> On Thu, Jan 28, 2010 at 10:55 PM, Randall Stewart wrote: >>> I was running SCHED_ULE on an 8.0 and everything works >>> fine. >>> >>> On my 2 core head of yesterday I tried both SCHED_ULE AND >>> 4BSD.. and got the same results ;-0 >>> >>> I will try my 4 core when I get home ;-) >>> >>> R >>> On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: >>> >>>> On Thu, 28 Jan 2010 10:30:37 -0800 >>>> Randall Stewart wrote: >>>> >>>>> All: >>>>> >>>>> I just found a very strange thing with yesterdays head. >>>>> >>>>> The program >>>>> >>>>> http://www.freebsd.org/~rrs/my_thr.c >>>>> >>>>> I compile it: >>>>> >>>>> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >>>>> >> >> Hi Randal, >> I tried your code on an 8-core machine with a fresh head (i386) >> I have no problems with both 4BSD and ULE scheduler. >> I even upping the value of macro NUM_THREAD to 24 but I didn't notice >> nothing strange. >> >> Have you got a chance to reproduce it on your machines? >> >> -- >> Gianni >> _______________________________________________ >> 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" >> > > I ran it on my dual-core, 8-STABLE/ULE laptop. The very first time I > ran it, I experienced the temporary "seizure". It took several more > runs before I could get it to happen again. > Hi Brandon, which kind of processor your laptop has? AMD or Intel? -- Gianni From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 22:24:16 2010 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 315A6106568F; Mon, 1 Feb 2010 22:24:16 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id EFBE78FC16; Mon, 1 Feb 2010 22:24:15 +0000 (UTC) Received: by pzk40 with SMTP id 40so1565560pzk.7 for ; Mon, 01 Feb 2010 14:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WZRYnuD3TYhZtwdrgF9hPMG7M/sttA924GFZSGwt8QQ=; b=hjveeOrrj8pLZ/dpy5S9NHrNMgrAuIuG/qr1GNbvugUHWU4ek85eMZa4NHJNoYHABO do3cROSEUgBcmTotUBe1b1YXrKzRlPa5UaHEY0BkrqlXbFTYkX8BZPDSQvaFlwCTBznQ VohY2YIgVTFjiBAiN13fGoaEzoh54Cs7+LZaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CKdzLpEFO7yPDDuXbKkZ+Q3gpmbYtIGFmBJNJDUnvijHo+KaLjCtZ9ytLkReKKA78h Z1h/Fc8RoqBHoJBdC228XNXI+mUPM/85C1+miZrXhNEAe8hE3iXMslbpawhIScN8/oWH iFaIjkKrdPSY6i+AtuB579CJ9+F1Hzjz31xN4= MIME-Version: 1.0 Received: by 10.142.152.15 with SMTP id z15mr3434753wfd.98.1265063055489; Mon, 01 Feb 2010 14:24:15 -0800 (PST) In-Reply-To: <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> Date: Mon, 1 Feb 2010 16:24:15 -0600 Message-ID: <179b97fb1002011424p4a799ff6t8f6b39e6f4b66828@mail.gmail.com> From: Brandon Gooch To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. 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, 01 Feb 2010 22:24:16 -0000 On Mon, Feb 1, 2010 at 4:04 PM, Giovanni Trematerra wrote: > On Fri, Jan 29, 2010 at 9:12 PM, Brandon Gooch > wrote: >> On Fri, Jan 29, 2010 at 3:44 PM, Giovanni Trematerra >> wrote: >>> On Thu, Jan 28, 2010 at 10:55 PM, Randall Stewart wrote: >>>> I was running SCHED_ULE on an 8.0 and everything works >>>> fine. >>>> >>>> On my 2 core head of yesterday I tried both SCHED_ULE AND >>>> 4BSD.. and got the same results ;-0 >>>> >>>> I will try my 4 core when I get home ;-) >>>> >>>> R >>>> On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: >>>> >>>>> On Thu, 28 Jan 2010 10:30:37 -0800 >>>>> Randall Stewart wrote: >>>>> >>>>>> All: >>>>>> >>>>>> I just found a very strange thing with yesterdays head. >>>>>> >>>>>> The program >>>>>> >>>>>> http://www.freebsd.org/~rrs/my_thr.c >>>>>> >>>>>> I compile it: >>>>>> >>>>>> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >>>>>> >>> >>> Hi Randal, >>> I tried your code on an 8-core machine with a fresh head (i386) >>> I have no problems with both 4BSD and ULE scheduler. >>> I even upping the value of macro NUM_THREAD to 24 but I didn't notice >>> nothing strange. >>> >>> Have you got a chance to reproduce it on your machines? >>> >>> -- >>> Gianni >>> _______________________________________________ >>> 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" >>> >> >> I ran it on my dual-core, 8-STABLE/ULE laptop. The very first time I >> ran it, I experienced the temporary "seizure". It took several more >> runs before I could get it to happen again. >> > > Hi Brandon, > which kind of processor your laptop has? AMD or Intel? > -- > Gianni > CPU: Intel(R) Core(TM)2 Duo CPU L7100 @ 1.20GHz (1197.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant -Brandon From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 23:30:54 2010 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 3C95D1065672 for ; Mon, 1 Feb 2010 23:30:54 +0000 (UTC) (envelope-from vincepoy@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id EC8F58FC0C for ; Mon, 1 Feb 2010 23:30:53 +0000 (UTC) Received: by ywh42 with SMTP id 42so4824370ywh.28 for ; Mon, 01 Feb 2010 15:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cAVFqFkk5uD/BKs8KSQA4QbDsow2C3eYf3adHEqR4Ag=; b=mjmG2A77dDBHIq+FVw7KixL3X1k8q7ZjqDhHUZZusMQWl4HaVtwTav71QqjlD8PCZz cvL8VOD+OFRz7gHCMJu2nLTWUKOxj17KDaiDiqzo4BytXGkGtbMUy5QbpKYrlDlPtAd6 bwfZRfLddrZvpv1Xn6bSEcEtg32AbtAN3OmaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LwQhmNxxXjbn2Ln3jJ2HJX11I2KakW5k4S6wGvfzBf3OgzuExzIPUfE+mHGMLSfhX2 3eQTjAX3G2CoMgakziBeYJP82ipKToONFlcLi4Is0KB7kwSmn4t147gH2bRkQqW8QETy n+I3fBVZ7XnNX/DjgLD3FAAg+jQLyjNnHcMVk= MIME-Version: 1.0 Received: by 10.150.127.16 with SMTP id z16mr3314200ybc.152.1265065206705; Mon, 01 Feb 2010 15:00:06 -0800 (PST) Date: Mon, 1 Feb 2010 15:00:06 -0800 Message-ID: <429af92e1002011500q59b9ae09g908154ae63881ff5@mail.gmail.com> From: Vincent Poy To: Ed Schouten , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: HEADS UP: gone. All welcome . 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, 01 Feb 2010 23:30:54 -0000 I just updated to a January 31, 2010 -CURRENT from a -CURRENT prior to the above change and have a few questions and issues: 1) What's the correct way to use wtmpcvt(1) as the usage is wtmpcvt oldfile newfile out of the utmp, wtmp, lastlog, the utmp is not important as that's basically the current logins. wtmp is not important either as that's just the recent monthly logins. What is the correct procedure to convert lastlog as that is basically the database that showed when the last time a user logged on to the system so that when using lastlogin or finger, it will showed when the person last logged in? I've tried wtmpcvt /var/log/lastlog /var/log/utx.lastlogin after backing up /var/log/utx.lastlogin but when I ran lastlogin, it was all blank. 2) I noticed that for last for ftp sessions, it will not show it as a ftp session like how the previous utmp did even though w now shows the session when it's still connected, not sure if this is really a bad thing unless ftp isn't the only way to not use a tty. It seems finger now will report the last login session which previously was only for tty sessions. root@bigbang [2:19pm][/var/log] >> w 2:20PM up 8:59, 2 users, load averages: 0.08, 0.04, 0.00 USER TTY FROM LOGIN@ IDLE WHAT vince pts/0 solar.dnalogic.net 5:23AM - screen vince - solar 2:20PM - - root@bigbang [2:20pm][/var/log] >> last vince solar Mon Feb 1 14:20 still logged in vince localhost Mon Feb 1 13:33 - 13:33 (00:00) root pts/11 localhost Mon Feb 1 06:51 - 06:51 (00:00) vince pts/0 solar.dnalogic.net Mon Feb 1 05:23 still logged in vince pts/1 solar.dnalogic.net Mon Feb 1 05:08 - 05:19 (00:11) wtmp begins Mon Feb 1 05:07:02 PST 2010 root@bigbang [2:20pm][/var/log] >> last vince solar Mon Feb 1 14:20 - 14:20 (00:00) vince localhost Mon Feb 1 13:33 - 13:33 (00:00) root pts/11 localhost Mon Feb 1 06:51 - 06:51 (00:00) vince pts/0 solar.dnalogic.net Mon Feb 1 05:23 still logged in vince pts/1 solar.dnalogic.net Mon Feb 1 05:08 - 05:19 (00:11) 3) I noticed that it seems the system in the w, who, finger, last, lastlogin output is not recognizing additional sessions of the same user on a new tty if they are already logged in such as this example. I am already logged in as vince on ptys/0 so I login again as vince on ptys/1: 28681 1 Is 0:00.04 login [pam] (login) 28682 1 S 0:00.10 -tcsh (tcsh) 28755 1 R+ 0:00.00 ps -ax who, w will only show the session on pts/0 but not the pts/1 vince@bigbang [2:43pm][~] >> who vince pts/0 Feb 1 05:23 (solar.dnalogic.net) vince@bigbang [2:43pm][~] >> who vince pts/0 Feb 1 05:23 (solar.dnalogic.net) vince@bigbang [2:43pm][~] >> w 2:43PM up 9:23, 1 user, load averages: 0.01, 0.05, 0.02 USER TTY FROM LOGIN@ IDLE WHAT vince pts/0 solar.dnalogic.net 5:23AM - screen last shows only the pts/0 session but not pts/1 while it does show two blank tty sessions which were ftp. vince@bigbang [2:43pm][~] >> last vince solar Mon Feb 1 14:20 - 14:20 (00:00) vince localhost Mon Feb 1 13:33 - 13:33 (00:00) root pts/11 localhost Mon Feb 1 06:51 - 06:51 (00:00) vince pts/0 solar.dnalogic.net Mon Feb 1 05:23 still logged in vince pts/1 solar.dnalogic.net Mon Feb 1 05:08 - 05:19 (00:11) wtmp begins Mon Feb 1 05:07:02 PST 2010 lastlogin shows only the last ftp session but not acknowledging that the current ptys/1 session as the ptys/0 session is still active. vince@bigbang [2:44pm][~] >> lastlogin vince solar Mon Feb 1 14:20:03 2010 finger shows only the pts/0 session but not the current pts/0 session and the last login is basically the ftp session as the pts/1 session is not acknowledged here either since pts/0 is still logged in. vince@bigbang [2:44pm][~] >> finger vince |more Login: vince Name: Vincent Poy Directory: /home/vince Shell: /bin/tcsh On since Mon Feb 1 05:23 (PST) on pts/0 (messages off) from solar.dnalogic.net Last login Mon Feb 1 14:20 (PST) on from solar New mail received Mon Feb 1 14:44 2010 (PST) Unread since Mon Feb 1 14:43 2010 (PST) 4) the misc/screen port appears to be broken: It will stop in files screen.c and tty.c with the error: sys/stropts.h: No such file or directory which can be fixed by commenting out sys/stropts.h. in those two files but the build will fail here: cc -c -I. -I. -O2 -pipe -DCOLORS256 -fno-strict-aliasing utmp.c utmp.c:95: error: static declaration of 'getutxent' follows non-static declaration /usr/include/utmpx.h:76: error: previous declaration of 'getutxent' was here utmp.c:96: error: static declaration of 'endutxent' follows non-static declaration /usr/include/utmpx.h:75: error: previous declaration of 'endutxent' was here utmp.c:98: error: static declaration of 'setutxent' follows non-static declaration /usr/include/utmpx.h:80: error: previous declaration of 'setutxent' was here utmp.c:107: error: 'UTMPX_FILE' undeclared here (not in a function) utmp.c: In function 'makeuser': utmp.c:740: error: 'struct utmpx' has no member named 'ut_name' utmp.c:740: error: 'struct utmpx' has no member named 'ut_name' utmp.c:740: warning: passing argument 3 of 'strncpy' makes integer from pointer without a cast utmp.c:742: error: 'struct utmpx' has no member named 'ut_xtime' *** Error code 1 Stop in /usr/ports/sysutils/screen/work/screen-4.0.3. *** Error code 1 Stop in /usr/ports/sysutils/screen. *** Error code 1 Stop in /usr/ports/sysutils/screen. root@bigbang [2:55pm][/usr/ports/sysutils/screen] >> Cheers, Vince Vincent Poy, Ph.D. - Astrophysics From owner-freebsd-current@FreeBSD.ORG Mon Feb 1 23:32:19 2010 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 F0DE11065692 for ; Mon, 1 Feb 2010 23:32:18 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 360ED8FC0A for ; Mon, 1 Feb 2010 23:32:18 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 670FC1CDDB; Tue, 2 Feb 2010 00:32:16 +0100 (CET) Date: Tue, 2 Feb 2010 00:32:16 +0100 From: Ed Schouten To: Vincent Poy Message-ID: <20100201233216.GL77705@hoeg.nl> References: <429af92e1002011500q59b9ae09g908154ae63881ff5@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QIE8wBgbk5Wqyq1O" Content-Disposition: inline In-Reply-To: <429af92e1002011500q59b9ae09g908154ae63881ff5@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . 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, 01 Feb 2010 23:32:19 -0000 --QIE8wBgbk5Wqyq1O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Vincent, * Vincent Poy wrote: > I just updated to a January 31, 2010 -CURRENT from a -CURRENT prior to the > above change and have a few questions and issues: >=20 > 1) What's the correct way to use wtmpcvt(1) as the usage is wtmpcvt oldfi= le > newfile > out of the utmp, wtmp, lastlog, the utmp is not important as that's > basically the current logins. wtmp is not important either as that's just > the recent monthly logins. What is the correct procedure to convert last= log > as that is basically the database that showed when the last time a user > logged on to the system so that when using lastlogin or finger, it will > showed when the person last logged in? >=20 > I've tried wtmpcvt /var/log/lastlog /var/log/utx.lastlogin after backing = up > /var/log/utx.lastlogin but when I ran lastlogin, it was all blank. Right now there is no way to convert lastlog files. The point is that unlike you mentioned, the wtmp is actually the only important log file. All information could in theory be derived from it. You could convert wtmp files and use last -f to scroll through history to figure out when someone logged in. =46rom an administrative point of view, you just want to be able to inspect log files in case it turns out a couple of months earlier something bad happened with your system (getting hacked, etc). lastlog is a nice feature, but it should just be considered being a bonus. Using wtmpcvt(1) on non-wtmp files will indeed generate unreadable data files. > 2) I noticed that for last for ftp sessions, it will not show it as a ftp > session like how the previous utmp did even though w now shows the session > when it's still connected, not sure if this is really a bad thing unless = ftp > isn't the only way to not use a tty. It seems finger now will report the > last login session which previously was only for tty sessions. >=20 > I have been thinking about possibly extending the utmpx interface to include an application name string for login entries, like "sshd" or "ftpd". > 3) I noticed that it seems the system in the w, who, finger, last, > lastlogin output is not recognizing additional sessions of the same user = on > a new tty if they are already logged in such as this example. I am alrea= dy > logged in as vince on ptys/0 so I login again as vince on ptys/1: > This is very odd. Could you try debugging this a bit more? In order to ease debugging, I extended the getent command. You should be able to use the following commands: - getent utmpx active Get list of active sessions (`utmp') - getent utmpx log Get list of log entries (`wtmp') - getent utmpx lastlogin Get list of last login entries (`lastlog') When you log in, it should add a "user process" entry to the active sessions database, append the same entry to the log and overwrite the lastlogin entry for the corresponding user. An advantage of these commands is that they just perform a raw dump of the data on screen, instead of having many forms of unwanted processing on top. > lastlogin shows only the last ftp session but not acknowledging that the > current ptys/1 session as the ptys/0 session is still active. > vince@bigbang [2:44pm][~] >> lastlogin > vince solar Mon Feb 1 14:20:03 2010 No, but that's not what lastlogin is supposed to do. lastlogin will only print information about the last login, which means it will only list the FTP login. > >=20 > 4) the misc/screen port appears to be broken: > Are you sure your ports tree is up-to-date? --=20 Ed Schouten WWW: http://80386.nl/ --QIE8wBgbk5Wqyq1O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktnZIAACgkQ52SDGA2eCwVCzwCdF8Ne+XW8VjpIceuiLKssd89m FF8AmwaHEY4f4PoNmIyIWWf7ub+J/Wn5 =5vlF -----END PGP SIGNATURE----- --QIE8wBgbk5Wqyq1O-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 11:16:58 2010 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 A6D8F106566C for ; Tue, 2 Feb 2010 11:16:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6558FC1A for ; Tue, 2 Feb 2010 11:16:56 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so159181fgb.13 for ; Tue, 02 Feb 2010 03:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=jpDLDidJ9uu4VeZ/d3RhmAEmmJ2oqDEaJz4ediWucFU=; b=Po0wfL7fykaybwf8lZ79geg34cSFS7jmDyY4iQRT9iDyVnQjScnZg6Nm4aVjpvVAwM 7N98crlIvhfjFCnXvS2cmuCvVSjmhmxq2viESP/2hyyEFMBEWPdPzGIEdp6+Mx31jbD6 Wb4ePBTqMIMao27mdkuFa7lfa+bE3Xyrzbsos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=vhodlzNTfxujkmFgDJgrgoTmjmSHYz6EuNbPgmqODNFMPs61pPCX5JO71mU+hkb9hY +jG+MMzBQ3qMc4u4s/ks4F14rTJytXuS3S1MeSwgYEQ4mL/yB1f7AWOTkY4MLtUFXCwm 5DExaMge3c33nu+tZ4VBerVoeuKdKYJtVNrEY= Received: by 10.87.15.22 with SMTP id s22mr9800101fgi.56.1265109416028; Tue, 02 Feb 2010 03:16:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm2430154fxm.11.2010.02.02.03.16.53 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 03:16:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4B680997.80909@FreeBSD.org> Date: Tue, 02 Feb 2010 13:16:39 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> <4B633FED.3030103@FreeBSD.org> <4B6358F3.7080908@icyb.net.ua> In-Reply-To: <4B6358F3.7080908@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Juergen Lock , Yamagi Burmeister Subject: Re: Pack of CAM improvements 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, 02 Feb 2010 11:16:58 -0000 Andriy Gapon wrote: > on 29/01/2010 22:07 Alexander Motin said the following: >> Juergen Lock wrote: >>> Ok while we are talking about ahci(4) on IXP700... Can anyone reproduce >>> the `test unit ready' bug on one of those? Since I saw no reply to >>> my post, >>> http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620 >>> maybe the bug is controller-specific? How to reproduce: just try >>> camcontrol tur adaX >>> or >>> cdrecord -scanbus >>> or (at least I think this is the same issue) start xfburn without hal >>> running, then watch for the bus to hang at the next disk access. >>> (Also leaving the disk led on solid here.) With the previous patch, >>> http://people.freebsd.org/~mav/cam-ata.20100119.patch >>> (haven't tested the latest one yet) at least it now seems to recover >>> after some timeout, leaving this in dmesg: (sorry I didn't notice >>> when I first tried, guess I didn't wait long enough...) >> It is controller specific. Intel and NVidia controllers just return >> error immediately, as they should, and continue operation. ATI IXP700 - >> doesn't: > > I have this simple patch in my local tree: > > I remember that this patch is not perfect, but it works for my simple desktop > setup. No bad side-effects from it either. I've committed more complete version of this patch to the 9-CURRENT, as part of r203376. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 11:37:10 2010 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 A1A03106566C; Tue, 2 Feb 2010 11:37:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 190928FC1D; Tue, 2 Feb 2010 11:36:28 +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 NAA13909; Tue, 02 Feb 2010 13:36:22 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B680E35.40909@icyb.net.ua> Date: Tue, 02 Feb 2010 13:36:21 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> <4B633FED.3030103@FreeBSD.org> <4B6358F3.7080908@icyb.net.ua> <4B680997.80909@FreeBSD.org> In-Reply-To: <4B680997.80909@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Juergen Lock , Yamagi Burmeister Subject: Re: Pack of CAM improvements 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, 02 Feb 2010 11:37:10 -0000 on 02/02/2010 13:16 Alexander Motin said the following: > I've committed more complete version of this patch to the 9-CURRENT, as > part of r203376. Thanks a lot! Will test it soon. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 16:55:13 2010 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 5175B106566B for ; Tue, 2 Feb 2010 16:55:13 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id E1A258FC12 for ; Tue, 2 Feb 2010 16:55:12 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NcM1v-0007rs-BL; Tue, 02 Feb 2010 17:55:11 +0100 Received: from p57ae27b3.dip0.t-ipconnect.de ([87.174.39.179]:29735 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NcM1u-00006E-R1; Tue, 02 Feb 2010 17:55:11 +0100 Date: Tue, 2 Feb 2010 17:55:05 +0100 From: Gary Jennejohn To: Ed Schouten Message-ID: <20100202175505.5d0d5d3e@ernst.jennejohn.org> In-Reply-To: <20100201233216.GL77705@hoeg.nl> References: <429af92e1002011500q59b9ae09g908154ae63881ff5@mail.gmail.com> <20100201233216.GL77705@hoeg.nl> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Vincent Poy , freebsd-current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 16:55:13 -0000 On Tue, 2 Feb 2010 00:32:16 +0100 Ed Schouten wrote: > * Vincent Poy wrote: > > 3) I noticed that it seems the system in the w, who, finger, last, > > lastlogin output is not recognizing additional sessions of the same user on > > a new tty if they are already logged in such as this example. I am already > > logged in as vince on ptys/0 so I login again as vince on ptys/1: > > > > This is very odd. Could you try debugging this a bit more? In order to > ease debugging, I extended the getent command. You should be able to use > the following commands: > > - getent utmpx active > Get list of active sessions (`utmp') > - getent utmpx log > Get list of log entries (`wtmp') > - getent utmpx lastlogin > Get list of last login entries (`lastlog') > > When you log in, it should add a "user process" entry to the active > sessions database, append the same entry to the log and overwrite the > lastlogin entry for the corresponding user. > > An advantage of these commands is that they just perform a raw dump of > the data on screen, instead of having many forms of unwanted processing > on top. > What terminal emulator are you using? I'm using mrxvt-devel and I _do_ see every mrxvt which I have running with w, who, finger and last. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 18:33:46 2010 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 0FB061065676 for ; Tue, 2 Feb 2010 18:33:46 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 909BF8FC1D for ; Tue, 2 Feb 2010 18:33:45 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so345034fgg.13 for ; Tue, 02 Feb 2010 10:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=A91SY8ZVlIaKgd3MMBFh1oLdldCCug10uVnI47VK1Uk=; b=h/hbDtL4viRbcfUbCdoSAYldeHjlbs4IIXb8OHfJa+lw4CaqEZCgV9t7MbqpOS9DaU +8vuVHjn95rldBSWiEcKS3iNiwHAx24/Y5MXG/Si9RMW5NW9hGMhRWTrNQoh5Z7uGMJA 2g2VrKbn14jxKmWt+CjEmbIr/iGE4likfXR5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=HBEsaLHYLc8iYl4TsjVqEa9t3CTV0OyunZxzIGcrpc5gQaUSp0nb4ee5BRJJW9slrc hjRODfq7t+aTu6Bvl6ze0jopnb4fzuajjv63T7UotmuYEHmmGVGhun4VYM5BEQNpnefl sPGZnEK5wsH7Cbk7GP0VZhb9HvOfMkIie0F3g= Received: by 10.87.68.19 with SMTP id v19mr2236906fgk.2.1265135624224; Tue, 02 Feb 2010 10:33:44 -0800 (PST) Received: from ubm.mine.nu (e181052080.adsl.alicedsl.de [85.181.52.80]) by mx.google.com with ESMTPS id e11sm12168743fga.3.2010.02.02.10.33.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 10:33:43 -0800 (PST) Date: Tue, 2 Feb 2010 19:34:13 +0100 From: Marc UBM Bocklet To: Jung-uk Kim Message-Id: <20100202193413.a497dd9d.ubm.freebsd@gmail.com> In-Reply-To: <201002011617.31527.jkim@FreeBSD.org> References: <20100201184446.2325c04e.ubm.freebsd@gmail.com> <201002011617.31527.jkim@FreeBSD.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.4; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Feb 2010 19:26:46 +0000 Cc: Marc UBM Bocklet , freebsd-current@freebsd.org Subject: Re: vidcontrol / resolution problems with latest current 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, 02 Feb 2010 18:33:46 -0000 On Mon, 1 Feb 2010 16:17:30 -0500 Jung-uk Kim wrote: > On Monday 01 February 2010 12:44 pm, Marc UBM Bocklet wrote: > > Hiho! :-) > > > > Recently, I updated to the latest version of 9-current and found > > out that I cannot set my console resolution to 800x600 anymore. If > > I try, it just goes blank or shows a few coloured, garbled lines in > > the upper third of my monitor. Starting X11 blindly works, as does > > switching to X11. > > > > I'm suspecting the recent tty/xterm changes, but I am not sure. > > > > > > uname -a: > > > > FreeBSD xxx.yyy 9.0-CURRENT FreeBSD 9.0-CURRENT #17: Sat > > Jan 23 14:58:47 CET 2010 > > sheep@ubm.mine.nu:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 > > > > > > Relevant part of my rc.conf that I used to set console to 800x600: > > > > allscreens_flags="-g 100x37 VESA_800x600" > > > > > > Relevant kernel option that I use: > > > > # VESA support > > > > options VESA > > > > # raster display support for 800x600 resolution > > > > options SC_PIXEL_MODE > > > > > > Can anyone point me to a solution / is more info required? > > Hmm... The attached patch should restore the previous behavior. No change, unfortunately. Anything I can provide to help? Bye Marc From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 20:07:41 2010 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 21724106566B for ; Tue, 2 Feb 2010 20:07:41 +0000 (UTC) (envelope-from justin.teller@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id BE3B58FC1D for ; Tue, 2 Feb 2010 20:07:40 +0000 (UTC) Received: by qyk6 with SMTP id 6so372163qyk.3 for ; Tue, 02 Feb 2010 12:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=rBUqU/TDwWYTOaN05pSAZrqpoccVvrCEWUdiR8EPXXE=; b=sDkO55FhhGJLGRBqWJaipc3Y9ln2VQR3oRbdr9VAqacggjoAEOIxhWY+8C2S00pVfu OEqHUL7Kel1OVpdghTPBJTsUKhP0wB+KJkssHF9m3FF1vco4zGDx0nmhhRfvAMDqEtxA PUfEq7PQHqSxUanNHRSGKswrpHXoLvWTEmXz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=JGPozDOpPGkyVEo2GYm8JvXrXqeCBBSvAHRX+JR3puikSOnmLR7gQK1OumdT5e+M1b iamla3118h42GP23c0f35LxMuhhACgr0A2frDpkoqpToUa+SCoq1BGzXf6yuOY3tzoLt CstMWsiqXrtyOLSB2FvfqE8piXV5ZpneqE/QU= MIME-Version: 1.0 Received: by 10.224.72.228 with SMTP id n36mr3072731qaj.138.1265141258980; Tue, 02 Feb 2010 12:07:38 -0800 (PST) Date: Tue, 2 Feb 2010 12:07:38 -0800 Message-ID: From: Justin Teller To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: David Xu Subject: Bug in kern_umtx.c -- read-write locks 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, 02 Feb 2010 20:07:41 -0000 I was working on a highly threaded app (125+ threads) that was using the pthread rw locks, and we were stalling at strange times. After a lot of debugging in our app, we found that a call to pthread_rwlock_wrlock() would sometimes never return -- it seemed like a wakeup was lost. After we convinced ourselves the bug wasn't in the app's locking code, I started digging into the kernel. I found that there is an issue where a wakeup can be "lost" when a thread goes to sleep calling pthread_rwlock_wrlock. The issue is in the file kern_umtx.c in the function do_rw_wrlock(): the code busies the lock before sleeping, but when it tries to set the waiters bit, it's looking at at old value (from the "try-lock" just before the busy). This allows a race where a thread can go to sleep w/o setting the waiters bit. Then the last thread to unlock won't wakeup the sleeping thread. The patch below (based off of 8.0 release) fixes my problem for the write lock and should fix the complimentary issue in do_rw_rdlock. --- kern_umtx.c 2010-02-01 13:03:24.000000000 -0800 +++ /kernel_src_8.0/usr/src/sys/kern/kern_umtx.c 2010-02-01 09:52:18.000000000 -0800 @@ -2461,10 +2461,15 @@ /* grab monitor lock */ umtxq_lock(&uq->uq_key); umtxq_busy(&uq->uq_key); umtxq_unlock(&uq->uq_key); + /* re-read the state, in case it changed between the try-lock above + * and the check below + */ + state = fuword32(__DEVOLATILE(int32_t *, &rwlock->rw_state)); + /* set read contention bit */ while ((state & wrflags) && !(state & URWLOCK_READ_WAITERS)) { oldstate = casuword32(&rwlock->rw_state, state, state | URWLOCK_READ_WAITERS); if (oldstate == state) goto sleep; @@ -2592,10 +2597,15 @@ /* grab monitor lock */ umtxq_lock(&uq->uq_key); umtxq_busy(&uq->uq_key); umtxq_unlock(&uq->uq_key); + + /* re-read the state, in case it changed between the try-lock above + * and the check below + */ + state = fuword32(__DEVOLATILE(int32_t *, &rwlock->rw_state)); while (((state & URWLOCK_WRITE_OWNER) || URWLOCK_READER_COUNT(state) != 0) && (state & URWLOCK_WRITE_WAITERS) == 0) { oldstate = casuword32(&rwlock->rw_state, state, state | URWLOCK_WRITE_WAITERS); if (oldstate == state) Looking thru the open PRs, it looks like it might be the cause of #135673, but I'm not completely sure. Also, I'm pretty new to contributing to the FreeBSD community -- what's the common practice of responding to a PR? Thanks -Justin From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 21:43:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 126D5106566B; Tue, 2 Feb 2010 21:43:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Marc UBM Bocklet Date: Tue, 2 Feb 2010 16:43:07 -0500 User-Agent: KMail/1.6.2 References: <20100201184446.2325c04e.ubm.freebsd@gmail.com> <201002011617.31527.jkim@FreeBSD.org> <20100202193413.a497dd9d.ubm.freebsd@gmail.com> In-Reply-To: <20100202193413.a497dd9d.ubm.freebsd@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_txJaL5Fl3j+6bE/" Message-Id: <201002021643.09859.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: vidcontrol / resolution problems with latest current 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, 02 Feb 2010 21:43:17 -0000 --Boundary-00=_txJaL5Fl3j+6bE/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 02 February 2010 01:34 pm, Marc UBM Bocklet wrote: > On Mon, 1 Feb 2010 16:17:30 -0500 > > Jung-uk Kim wrote: > > On Monday 01 February 2010 12:44 pm, Marc UBM Bocklet wrote: > > > Hiho! :-) > > > > > > Recently, I updated to the latest version of 9-current and > > > found out that I cannot set my console resolution to 800x600 > > > anymore. If I try, it just goes blank or shows a few coloured, > > > garbled lines in the upper third of my monitor. Starting X11 > > > blindly works, as does switching to X11. > > > > > > I'm suspecting the recent tty/xterm changes, but I am not sure. > > > > > > > > > uname -a: > > > > > > FreeBSD xxx.yyy 9.0-CURRENT FreeBSD 9.0-CURRENT #17: Sat > > > Jan 23 14:58:47 CET 2010 > > > sheep@ubm.mine.nu:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 > > > > > > > > > Relevant part of my rc.conf that I used to set console to > > > 800x600: > > > > > > allscreens_flags="-g 100x37 VESA_800x600" > > > > > > > > > Relevant kernel option that I use: > > > > > > # VESA support > > > > > > options VESA > > > > > > # raster display support for 800x600 resolution > > > > > > options SC_PIXEL_MODE > > > > > > > > > Can anyone point me to a solution / is more info required? > > > > Hmm... The attached patch should restore the previous behavior. > > No change, unfortunately. Anything I can provide to help? How about the attached patch, then? Jung-uk Kim --Boundary-00=_txJaL5Fl3j+6bE/ Content-Type: text/plain; charset="iso-8859-1"; name="vesa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vesa.diff" --- sys/dev/fb/vesa.c +++ sys/dev/fb/vesa.c @@ -186,7 +186,9 @@ static int vesa_bios_load_palette2(int start, int #define STATE_ALL (STATE_HW | STATE_DATA | STATE_DAC | STATE_REG) static ssize_t vesa_bios_state_buf_size(void); static int vesa_bios_save_restore(int code, void *p, size_t size); +#if 0 static int vesa_bios_get_line_length(void); +#endif static int vesa_bios_set_line_length(int pixel, int *bytes, int *lines); #if 0 static int vesa_bios_get_start(int *x, int *y); @@ -195,7 +197,6 @@ static int vesa_bios_set_start(int x, int y); static int vesa_map_gen_mode_num(int type, int color, int mode); static int vesa_translate_flags(u_int16_t vflags); static int vesa_translate_mmodel(u_int8_t vmodel); -static int vesa_get_line_width(video_info_t *info); static int vesa_bios_init(void); static void vesa_clear_modes(video_info_t *info, int color); static vm_offset_t vesa_map_buffer(u_int paddr, size_t size); @@ -567,6 +568,7 @@ vesa_bios_save_restore(int code, void *p, size_t s return (regs.R_AX != 0x004f); } +#if 0 static int vesa_bios_get_line_length(void) { @@ -583,6 +585,7 @@ vesa_bios_get_line_length(void) return (regs.R_BX); } +#endif static int vesa_bios_set_line_length(int pixel, int *bytes, int *lines) @@ -716,37 +719,6 @@ vesa_translate_mmodel(u_int8_t vmodel) return (V_INFO_MM_OTHER); } -static int -vesa_get_line_width(video_info_t *info) -{ - int len; - int width; - - width = info->vi_width; - - if (info->vi_flags & V_INFO_GRAPHICS) - switch (info->vi_depth / info->vi_planes) { - case 1: - return (width / 8); - case 2: - return (width / 4); - case 4: - return (width / 2); - case 8: - return (width); - case 15: - case 16: - return (width * 2); - case 24: - case 32: - return (width * 4); - } - - len = vesa_bios_get_line_length(); - - return (len > 0 ? len : width); -} - #define VESA_MAXSTR 256 #define VESA_STRCPY(dst, src) do { \ @@ -933,10 +905,14 @@ vesa_bios_init(void) /* XXX window B */ vesa_vmode[modes].vi_window_size = vmode.v_wsize*1024; vesa_vmode[modes].vi_window_gran = vmode.v_wgran*1024; - if (vmode.v_modeattr & V_MODELFB) + if (vmode.v_modeattr & V_MODELFB) { vesa_vmode[modes].vi_buffer = vmode.v_lfb; - else + vesa_vmode[modes].vi_line_width = vers >= 0x0300 ? + vmode.v_linbpscanline : vmode.v_bpscanline; + } else { vesa_vmode[modes].vi_buffer = 0; + vesa_vmode[modes].vi_line_width = vmode.v_bpscanline; + } /* XXX */ vesa_vmode[modes].vi_buffer_size = vesa_adp_info->v_memsize*64*1024; @@ -987,8 +963,8 @@ vesa_bios_init(void) = vesa_translate_flags(vmode.v_modeattr) | V_INFO_VESA; /* Does it have enough memory to support this mode? */ - bsize = vesa_get_line_width(&vesa_vmode[modes]); - bsize *= vesa_vmode[modes].vi_height; + bsize = (size_t)vesa_vmode[modes].vi_line_width * + vesa_vmode[modes].vi_height; if (bsize > vesa_vmode[modes].vi_buffer_size) { #if VESA_DEBUG > 1 printf( @@ -1322,7 +1298,7 @@ vesa_set_mode(video_adapter_t *adp, int mode) vesa_adp->va_window_gran = info.vi_window_gran; } vesa_adp->va_window_orig = 0; - vesa_adp->va_line_width = vesa_get_line_width(&info); + vesa_adp->va_line_width = info.vi_line_width; vesa_adp->va_disp_start.x = 0; vesa_adp->va_disp_start.y = 0; #if VESA_DEBUG > 0 --- sys/sys/fbio.h +++ sys/sys/fbio.h @@ -295,8 +295,10 @@ struct video_info { /* for MM_DIRECT only */ int vi_pixel_fields[4]; /* RGB and reserved fields */ int vi_pixel_fsizes[4]; + /* XXX for VESA only */ + int vi_line_width; /* reserved */ - u_char vi_reserved[64]; + u_char vi_reserved[60]; vm_offset_t vi_registers; /* physical address */ vm_offset_t vi_registers_size; }; --Boundary-00=_txJaL5Fl3j+6bE/-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 22:00:03 2010 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 BF0FC1065679; Tue, 2 Feb 2010 22:00:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id A30F38FC12; Tue, 2 Feb 2010 22:00:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ariccio-t43.jnpr.net ([66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KX8007ROIFR5Q00@asmtp029.mac.com>; Tue, 02 Feb 2010 14:00:03 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002020181 From: Marcel Moolenaar Date: Tue, 02 Feb 2010 13:59:51 -0800 Message-id: To: "current@freebsd.org mailing list" X-Mailer: Apple Mail (2.1077) Cc: Alexander Motin Subject: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 22:00:03 -0000 All, On recent -CURRENT the console gets spammed with the following: xpt_release_devq(0): requested 1 > present 0 Can we put this under bootverbose? Do we need to print this at all? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 22:05:22 2010 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 388151065672 for ; Tue, 2 Feb 2010 22:05:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id B5FEE8FC08 for ; Tue, 2 Feb 2010 22:05:21 +0000 (UTC) Received: by bwz3 with SMTP id 3so610523bwz.13 for ; Tue, 02 Feb 2010 14:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6Hx8iLgwrC5Rqueoj8IdOH1OZL/en8hxfOeefro5qPg=; b=bIeeaBJvbVcEFVArQcQ1RNQBpBwW/izBGbit/o5xfsINb8XhChkZ5uELqcaJJRwqm8 +tCquhJt5mjc/kSuit24OyUPBTcFYCBwMnOQE0E0h0PW3Blmul97b+DXpde7DmQhnCDr 3NgsuLkq3ZLQOYWSa65b8c8soreA3+uZ0oue0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=lEkfLCUDvouNqcAY6yngwW026oCIhaSyoNaH9Vch+BrW1KP9EXNImYZoYiWdEmz6zo XZXdMbfx3LLjZ7on2mNHVxTrMONZZwFHBN9ahQPseZuXRPMuFx/jQAQqVDcMLoOrDAC6 qcNHRzz0VBoHd8XcZF43e0EHJy14znbXTVOq0= Received: by 10.102.182.6 with SMTP id e6mr4137869muf.63.1265148320054; Tue, 02 Feb 2010 14:05:20 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 23sm2119465mun.38.2010.02.02.14.05.18 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 14:05:18 -0800 (PST) Sender: Alexander Motin Message-ID: <4B68A18E.1030500@FreeBSD.org> Date: Wed, 03 Feb 2010 00:05:02 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marcel Moolenaar References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 22:05:22 -0000 Hi. Marcel Moolenaar wrote: > On recent -CURRENT the console gets spammed with the following: > > xpt_release_devq(0): requested 1 > present 0 > > Can we put this under bootverbose? It was already put under INVARIANTS. > Do we need to print this at all? It was hidden before, but we need to fix this, if we want error handling to work correctly. Can you somehow localize situations when those messages appear? What controller and devices do you use? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 22:21:59 2010 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 56F68106566B; Tue, 2 Feb 2010 22:21:59 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 41E978FC1B; Tue, 2 Feb 2010 22:21:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ariccio-t43.jnpr.net ([66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KX800MAUJG5SP80@asmtp027.mac.com>; Tue, 02 Feb 2010 14:21:42 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002020182 From: Marcel Moolenaar In-reply-to: <4B68A18E.1030500@FreeBSD.org> Date: Tue, 02 Feb 2010 14:21:41 -0800 Message-id: <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> References: <4B68A18E.1030500@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 22:21:59 -0000 On Feb 2, 2010, at 2:05 PM, Alexander Motin wrote: > Hi. > > Marcel Moolenaar wrote: >> On recent -CURRENT the console gets spammed with the following: >> >> xpt_release_devq(0): requested 1 > present 0 >> >> Can we put this under bootverbose? > > It was already put under INVARIANTS. Which is what developers run by default :-) >> Do we need to print this at all? > > It was hidden before, but we need to fix this, if we want error handling > to work correctly. > > Can you somehow localize situations when those messages appear? What > controller and devices do you use? SCSI controller is: mpt0: mem 0xa0470000-0xa0473fff,0xa0460000-0xa046ffff irq 27 at device 1.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.13.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (10 Max) Harddisk is: da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) This disk has tagged queuing enabled but the disk only has 122 openings. When busy the number of openings can reduce to 121. Due to bugs in the CAM layer the number of openings never gets adjusted when MPT inform CAM about it a Queue Full Event. I suspect this is related to it, but may be wrong... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 22:33:09 2010 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 2D08B106566C for ; Tue, 2 Feb 2010 22:33:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id AE2F88FC15 for ; Tue, 2 Feb 2010 22:33:08 +0000 (UTC) Received: by fxm26 with SMTP id 26so609671fxm.13 for ; Tue, 02 Feb 2010 14:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ULI8ieozh5orqnk4mOmjuS9GFx0ep/4KodMyxesahI8=; b=KIGRE4eY1G78cRY+Oxor7z4yvIA99A+MpSVfaB/22vOqUxmxDhgncyBXbEm8lKQohU oM7yjWpJfofTWwtW8OuhVI9hB/lmaI3T6FkfMsc8+h5iiJf49I5jTgP5QiivA5migX32 ucJQs4xat0uIxnKCD+xJ/6xTeQfdPl8dPsxJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UxaiYRQvGdRD5UN8LfzCaYpOxjNdR/KkYaPwsvrXsHeO4DIjMqNs4c/NvUJGUW1r/T P2rpsJdYaScWe6ItP9ggfNOJZ5PYHk44k/VYhTTChsYlcu1mX9u6nxmJk9sop7EyFkwQ tJN/0SP2Ajw8gFrlmd/oHtYYaT6Ga6dNAcc0I= Received: by 10.102.207.4 with SMTP id e4mr3666098mug.126.1265149987761; Tue, 02 Feb 2010 14:33:07 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y6sm1101070mug.1.2010.02.02.14.33.06 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 14:33:07 -0800 (PST) Sender: Alexander Motin Message-ID: <4B68A812.40103@FreeBSD.org> Date: Wed, 03 Feb 2010 00:32:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> In-Reply-To: <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 22:33:09 -0000 Marcel Moolenaar wrote: > On Feb 2, 2010, at 2:05 PM, Alexander Motin wrote: >> Marcel Moolenaar wrote: >>> On recent -CURRENT the console gets spammed with the following: >>> >>> xpt_release_devq(0): requested 1 > present 0 >>> >>> Can we put this under bootverbose? >> It was already put under INVARIANTS. > > Which is what developers run by default :-) And on strange coincidence, it is developers who are fixing bugs. :) >>> Do we need to print this at all? >> It was hidden before, but we need to fix this, if we want error handling >> to work correctly. >> >> Can you somehow localize situations when those messages appear? What >> controller and devices do you use? > > SCSI controller is: > mpt0: mem 0xa0470000-0xa0473fff,0xa0460000-0xa046ffff irq 27 at device 1.0 on pci1 > mpt0: [ITHREAD] > mpt0: MPI Version=1.5.13.0 > mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) > mpt0: 0 Active Volumes (2 Max) > mpt0: 0 Hidden Drive Members (10 Max) > > Harddisk is: > da0: Fixed Direct Access SCSI-5 device > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) > > This disk has tagged queuing enabled but the disk only has 122 > openings. When busy the number of openings can reduce to 121. > Due to bugs in the CAM layer the number of openings never gets > adjusted when MPT inform CAM about it a Queue Full Event. > > I suspect this is related to it, but may be wrong... Whether it is related or not, both issues definitely should be fixed. Could you give me an access to debug that system, or it is in use? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 22:57:04 2010 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 981501065672; Tue, 2 Feb 2010 22:57:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 81A538FC12; Tue, 2 Feb 2010 22:57:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ariccio-t43.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KX8005FZL2FMS60@asmtp026.mac.com>; Tue, 02 Feb 2010 14:56:42 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=4 spamscore=4 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002020187 From: Marcel Moolenaar In-reply-to: <4B68A812.40103@FreeBSD.org> Date: Tue, 02 Feb 2010 14:56:39 -0800 Message-id: <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 22:57:04 -0000 On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: > > Whether it is related or not, both issues definitely should be fixed. > Could you give me an access to debug that system, or it is in use? Unfortunately, I can't give you access to this machine. Can you elaborate what the code is correcting? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 23:12:24 2010 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 2D45E1065670 for ; Tue, 2 Feb 2010 23:12:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id AE5718FC12 for ; Tue, 2 Feb 2010 23:12:23 +0000 (UTC) Received: by fxm26 with SMTP id 26so642050fxm.13 for ; Tue, 02 Feb 2010 15:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=mW2UMQO0ppCXNiUk9xPCaM3qGjSl5yymBNwy6JeruFQ=; b=mqTHXVDPp1eT0XFoC6g//CQj+ddKr89ckLw7Y7oF6lQ6/N+5AnS3oXgCSUbkRQxyw9 Y8lOv3rWBBZd5JTJmUSoKTOl+MLOUXPyI7hWc9felyvnqwSqx0rEpMWD2yWTt5cBPYwO m1Y7KUds2QjuxAxzXEkqhctjtH9idsc0Xz7Nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=YyyQh0RbzRD3zaOTuQxu17s3UNJka7BzrHWCnjZptuimkPT9JknTcl3aOc7XFI+lR7 dzPrlHou4yLVwlisGWU/vZ1+AcV+hCqufchDWvQWnB0ZXv/QvqaiivPKAilF/Nf22pZW 6M9LZ7Ml/jM0BdqehTco9mw2FzF0LR2ZzzhgQ= Received: by 10.102.200.17 with SMTP id x17mr3890982muf.125.1265152342749; Tue, 02 Feb 2010 15:12:22 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id i7sm10200599mue.46.2010.02.02.15.12.20 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 15:12:21 -0800 (PST) Sender: Alexander Motin Message-ID: <4B68B145.2030807@FreeBSD.org> Date: Wed, 03 Feb 2010 01:12:05 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> In-Reply-To: <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 23:12:24 -0000 Marcel Moolenaar wrote: > On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: >> Whether it is related or not, both issues definitely should be fixed. >> Could you give me an access to debug that system, or it is in use? > > Unfortunately, I can't give you access to this machine. > Can you elaborate what the code is correcting? When some error happens, SIM freezes affected device until situation is revealed and returns error status. After CAM received all error statuses, it does some error recovery procedure, optionally sending some additional high-priority commands. After error completely handled, being device released. Message that you see means that device was released more times then it was frozen. As result, it may accidentally release device before then error really handled. It is not as bad as opposite case, which may lead to device deadlock, but still far from perfect. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 23:39:43 2010 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 252F8106568D for ; Tue, 2 Feb 2010 23:39:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id A3AEA8FC22 for ; Tue, 2 Feb 2010 23:39:42 +0000 (UTC) Received: by fxm26 with SMTP id 26so660194fxm.13 for ; Tue, 02 Feb 2010 15:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+OdhfS05hnHydzOaYI1UjwH+ToFFRJXeGMW/QQBsTeA=; b=KTSHr9cTCH3D+Kl+b/YY/9Z/c5Fu/id/YBDfbhFSwlLV1zGthcWnzGd5LFv9gDL1G9 EBElBiqk7FHurZup3XLNaIpbJc2sE92q7zC5+TDUuoarv2vHFy+hBN3KoRePGnHoL40k bSgXHqiwDmeuOdPiVZbVKBiOmJa8+P24zpvi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Om08Rc8Oi+LWr2FMKHcfOY540Am4uIMZz5csoov0L8my3Y2BT43r865k1BEIfKeiZj seIl7Rg/WOC1SWsryNKjuubWwyQl6EtkBqlf/35uOwlz9njN5JtE4oC2NZHu1LAA/SOa YYEK6HBXsXFPWfWdzpQZZXaXTvtzj5ZSVQLUw= Received: by 10.102.204.2 with SMTP id b2mr4233454mug.80.1265153981516; Tue, 02 Feb 2010 15:39:41 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y6sm1368837mug.31.2010.02.02.15.39.40 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 15:39:40 -0800 (PST) Sender: Alexander Motin Message-ID: <4B68B7AC.8050908@FreeBSD.org> Date: Wed, 03 Feb 2010 01:39:24 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> In-Reply-To: <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Tue, 02 Feb 2010 23:39:43 -0000 Marcel Moolenaar wrote: > On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: >> Whether it is related or not, both issues definitely should be fixed. >> Could you give me an access to debug that system, or it is in use? > > Unfortunately, I can't give you access to this machine. What's about full verbose dmesg up to the first few errors? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Feb 2 23:55:58 2010 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 910AD106566C for ; Tue, 2 Feb 2010 23:55:58 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 325318FC1D for ; Tue, 2 Feb 2010 23:55:57 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id BE1F714DA4E6; Wed, 3 Feb 2010 00:55:55 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FVOa1ERbwS6c; Wed, 3 Feb 2010 00:55:46 +0100 (CET) Received: from [192.168.1.121] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 3039314DA4AB; Wed, 3 Feb 2010 00:55:46 +0100 (CET) Message-ID: <4B68CA1F.5060105@FreeBSD.org> Date: Wed, 03 Feb 2010 01:58:07 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 2.0.0.23 (X11/20100119) MIME-Version: 1.0 To: Jilles Tjoelker References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> <4B5C27B9.1080805@FreeBSD.org> <20100124113718.GC3877@deviant.kiev.zoral.com.ua> <4B5CD916.1060003@FreeBSD.org> <20100126222338.GA40281@stack.nl> <4B633F2D.6010804@FreeBSD.org> <20100129215038.GA95021@stack.nl> In-Reply-To: <20100129215038.GA95021@stack.nl> Content-Type: multipart/mixed; boundary="------------010405030806090204040601" Cc: Xin LI , current@freebsd.org Subject: Re: NLS/strerror efficiency 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, 02 Feb 2010 23:55:58 -0000 This is a multi-part message in MIME format. --------------010405030806090204040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Jilles Tjoelker wrote: > On Fri, Jan 29, 2010 at 09:03:57PM +0100, Gábor Kövesdán wrote: > >>>> +static pthread_rwlock_t rwlock; >>>> > > >>> Use PTHREAD_RWLOCK_INITIALIZER here to avoid problems with initializing >>> the lock. >>> > > >> I talked to delphij@ about this. Shouldn't pthread_rwlock_rdlock() and >> pthread_rwlock_wrlock() automatically initialize the lock if it is NULL? >> We even removed the pthread_rwlock_init() call and it just works. >> > > If you look in you will notice that > PTHREAD_RWLOCK_INITIALIZER is simply NULL. Also, pthread_rwlock_t is > just a pointer. However, this may well change later on to allow rwlocks > in shared memory, making pthread_rwlock_t a struct and > PTHREAD_RWLOCK_INITIALIZER something more complicated. It already works > that way in various other implementations, and sem_t has already been > changed similarly in 9-CURRENT. > > >>> Hmm, so an error for one language makes it give up for all other >>> languages too? It is possible that a catalog is only available in a few >>> languages. >>> > > >> Fixed. >> > > >>>> + UNLOCK(NLERR); >>>> + NLRETERR(np->caterrno); >>>> + } else if (strcmp(np->lang, lang) == 0) { >>>> > > >>> Some code below can apparently set np->lang = NULL, how does that work? >>> > > >> NULL means locale-independent open, i.e. catopen() is given an absolute >> path. We could add more if's to separate those cases more but that would >> result in more code, while this just works. If name is set to an >> absolute path, lang will be NULL and strcmp(NULL, NULL) will return 0, >> so it will match. >> > > strcmp(3) and the POSIX spec do not specifically allow passing NULL to > strcmp(), so it is not valid to do so. It seems that gcc treats a > literal strcmp(NULL, NULL) specially, replacing it with 0, but any real > strcmp call involving NULL segfaults. > > This probably needs to become something more complicated like > (np->lang == NULL || lang == NULL ? np->lang == lang : > strcmp(np->lang, lang) == 0) > > >> @@ -374,8 +376,8 @@ >> } >> >> if (_fstat(fd, &st) != 0) { >> + _close(fd); >> SAVEFAIL(name, errno); >> - _close(fd); >> return (NLERR); >> } >> > > Be careful that cleanup actions like these might overwrite errno. > munmap() and _close() are system calls and they should not fail in this > case (read-only file), so it should be safe. It is cleaner to save errno > immediately after the failing call, though. > > >> @@ -390,8 +392,8 @@ >> >> if (ntohl((u_int32_t)((struct _nls_cat_hdr *)data)->__magic) != >> _NLS_MAGIC) { >> + munmap(data, (size_t)st.st_size); >> SAVEFAIL(name, errno); >> - munmap(data, (size_t)st.st_size); >> NLRETERR(EINVAL); >> } >> > > The errno value seems garbage. SAVEFAIL with EINVAL, or perhaps use > EFTYPE (in both places). > > The cast to size_t reminds me to ask what happens in the pathological > case of a catalog file bigger than a size_t can describe, which may > happen on 32-bit systems. I think this should fail rather than mapping > the initial size%(1<<32) part. > Hi Jilles, thanks for pointing out these special cases. I've found some more myself, as well and I've made a patch. For this one I've tested all of the major cases I could think of and it seems to work for those ones. Patch is attached. Gabor --------------010405030806090204040601 Content-Type: text/x-patch; name="msgcat.c.diff" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="msgcat.c.diff" Index: nls/msgcat.c =================================================================== --- nls/msgcat.c (revisión: 203407) +++ nls/msgcat.c (copia de trabajo) @@ -77,19 +77,22 @@ #define NLERR ((nl_catd) -1) #define NLRETERR(errc) { errno = errc; return (NLERR); } -#define SAVEFAIL(n, e) { WLOCK(NLERR); \ - np = malloc(sizeof(struct catentry)); \ - if (np != NULL) { \ - np->name = strdup(n); \ - np->caterrno = e; \ - SLIST_INSERT_HEAD(&cache, np, list); \ - } \ - UNLOCK; \ - } +#define SAVEFAIL(n, l, e) { WLOCK(NLERR); \ + np = malloc(sizeof(struct catentry)); \ + if (np != NULL) { \ + np->name = strdup(n); \ + np->path = NULL; \ + np->lang = (l == NULL) ? NULL : strdup(l); \ + np->caterrno = e; \ + SLIST_INSERT_HEAD(&cache, np, list); \ + } \ + UNLOCK; \ + errno = e; \ + } static nl_catd load_msgcat(const char *, const char *, const char *); -static pthread_rwlock_t rwlock; +static pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER; struct catentry { SLIST_ENTRY(catentry) list; @@ -114,10 +117,12 @@ int saverr, spcleft; char path[PATH_MAX]; + /* sanity checking */ if (name == NULL || *name == '\0') NLRETERR(EINVAL); if (strchr(name, '/') != NULL) + /* have a pathname */ lang = NULL; else { if (type == NL_CAT_LOCALE) @@ -135,12 +140,13 @@ /* Try to get it from the cache first */ RLOCK(NLERR); SLIST_FOREACH(np, &cache, list) { - if (strcmp(np->name, name) == 0) { + if ((strcmp(np->name, name) == 0) && ((lang == NULL || np->lang == NULL) ? (np->lang == lang) : + (strcmp(np->lang, lang) == 0))) { if (np->caterrno != 0) { /* Found cached failing entry */ UNLOCK; NLRETERR(np->caterrno); - } else if (strcmp(np->lang, lang) == 0) { + } else { /* Found cached successful entry */ np->refcount++; UNLOCK; @@ -154,6 +160,7 @@ if (strchr(name, '/') != NULL) return (load_msgcat(name, name, lang)); + /* sanity checking */ if ((plang = cptr1 = strdup(lang)) == NULL) return (NLERR); if ((cptr = strchr(cptr1, '@')) != NULL) @@ -218,6 +225,7 @@ too_long: free(plang); free(base); + SAVEFAIL(name, lang, ENAMETOOLONG); NLRETERR(ENAMETOOLONG); } pathP += strlen(tmpptr); @@ -241,6 +249,7 @@ } free(plang); free(base); + SAVEFAIL(name, lang, ENOENT); NLRETERR(ENOENT); } @@ -317,6 +326,7 @@ { struct catentry *np; + /* sanity checking */ if (catd == NULL || catd == NLERR) { errno = EBADF; return (-1); @@ -325,13 +335,15 @@ /* Remove from cache if not referenced any more */ WLOCK(-1); SLIST_FOREACH(np, &cache, list) { - if ((np->catd->__size == catd->__size) && - memcmp((const void *)np->catd, (const void *)catd, np->catd->__size) == 0) { + if (catd == np->catd) { np->refcount--; if (np->refcount == 0) { munmap(catd->__data, (size_t)catd->__size); free(catd); SLIST_REMOVE(&cache, np, catentry, list); + free(np->name); + free(np->path); + free(np->lang); free(np); } break; @@ -360,7 +372,7 @@ it might still be found by absolute path. */ RLOCK(NLERR); SLIST_FOREACH(np, &cache, list) { - if (strcmp(np->path, path) == 0) { + if ((np->path != NULL) && (strcmp(np->path, path) == 0)) { np->refcount++; UNLOCK; return (np->catd); @@ -369,36 +381,45 @@ UNLOCK; if ((fd = _open(path, O_RDONLY)) == -1) { - SAVEFAIL(name, errno); - return (NLERR); + SAVEFAIL(name, lang, errno); + NLRETERR(errno); } if (_fstat(fd, &st) != 0) { - SAVEFAIL(name, errno); _close(fd); - return (NLERR); + SAVEFAIL(name, lang, EFTYPE); + NLRETERR(EFTYPE); } - data = mmap(0, (size_t)st.st_size, PROT_READ, MAP_FILE|MAP_SHARED, fd, - (off_t)0); - _close(fd); + /* If the file size cannot be held in size_t we cannot mmap() + it to the memory. Probably, this will not be a problem given + that catalog files are usually small.*/ + if (st.st_size > SIZE_T_MAX) { + _close(fd); + SAVEFAIL(name, lang, EFBIG); + NLRETERR(EFBIG); + } - if (data == MAP_FAILED) { - SAVEFAIL(name, errno); - return (NLERR); + if ((data = mmap(0, (size_t)st.st_size, PROT_READ, + MAP_FILE|MAP_SHARED, fd, (off_t)0)) == MAP_FAILED) { + int saved_errno = errno; + _close(fd); + SAVEFAIL(name, lang, saved_errno); + NLRETERR(saved_errno); } + _close(fd); if (ntohl((u_int32_t)((struct _nls_cat_hdr *)data)->__magic) != _NLS_MAGIC) { - SAVEFAIL(name, errno); munmap(data, (size_t)st.st_size); - NLRETERR(EINVAL); + SAVEFAIL(name, lang, EFTYPE); + NLRETERR(EFTYPE); } if ((catd = malloc(sizeof (*catd))) == NULL) { - SAVEFAIL(name, errno); munmap(data, (size_t)st.st_size); - return (NLERR); + SAVEFAIL(name, lang, ENOMEM); + NLRETERR(ENOMEM); } catd->__data = data; --------------010405030806090204040601-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 00:24:26 2010 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 978701065670; Wed, 3 Feb 2010 00:24:26 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2EB8FC0A; Wed, 3 Feb 2010 00:24:26 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KX800IXQP45XU90@asmtp025.mac.com>; Tue, 02 Feb 2010 16:24:07 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002020201 From: Marcel Moolenaar In-reply-to: <4B68B7AC.8050908@FreeBSD.org> Date: Tue, 02 Feb 2010 16:24:04 -0800 Message-id: <98CCEDE2-1C57-4CAA-B5F4-6A42B3822AC2@mac.com> References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Wed, 03 Feb 2010 00:24:26 -0000 On Feb 2, 2010, at 3:39 PM, Alexander Motin wrote: > Marcel Moolenaar wrote: >> On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: >>> Whether it is related or not, both issues definitely should be fixed. >>> Could you give me an access to debug that system, or it is in use? >> >> Unfortunately, I can't give you access to this machine. > > What's about full verbose dmesg up to the first few errors? OK boot -v Entering /boot/kernel/kernel at 0xe000000004068000... PAL Proc at 0xe00000003f800010 SAL Proc at 0xe00000003ff9b780, GP at 0xe00000003fe00000 SAL: AP wake-up vector: 0xff Platform clock frequency 266108676 Hz Processor ratio 1600/267, Bus ratio 1/1, ITC ratio 6/4 ptc.e base=0x0, count1=1, count2=1, stride1=0x0, stride2=0x0 Processor supports 24 Region ID bits VHPT: address=0xe000000000200000, size=0x100000 GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #65 r203328M: Tue Feb 2 16:06:29 PST 2010 marcel@hob.lan.xcllnt.net:/usr/obj/nfs/freebsd/base/head/sys/HOB ia64 WARNING: WITNESS option enabled, expect reduced performance. UNWIND: table added: base=e000000004000000, start=e0000000047ad408, end=e0000000047de9c8 Preloaded elf kernel "/boot/kernel/kernel" at 0xe000000004d44f80. Preloaded elf module "/boot/kernel/zfs.ko" at 0xe000000004d45060. Preloaded elf module "/boot/kernel/opensolaris.ko" at 0xe000000004d45130. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xe000000004d45208. UNWIND: table added: base=e000000004d30000, start=e000000004d32530, end=e000000004d326c8 UNWIND: table added: base=e000000004b26000, start=e000000004ce4130, end=e000000004ced910 CPU: Montecito (1595 Mhz Itanium 2) Origin = "GenuineIntel" Revision = 7 Features = 0x5 real memory = 8552701952 (8156 MB) Physical memory chunk(s): 0x00480000 - 0x03ffffff, 62390272 bytes (7616 pages) 0x04d48000 - 0x3e67ffff, 965967872 bytes (117916 pages) 0x3fc00000 - 0x3fd75fff, 1531904 bytes (187 pages) 0x100000000 - 0x1f8865fff, 4169555968 bytes (508979 pages) 0x10040000000 - 0x100ff0e3fff, 3205382144 bytes (391282 pages) 0x100ff200000 - 0x100ff227fff, 163840 bytes (20 pages) 0x100ff802000 - 0x100ff923fff, 1187840 bytes (145 pages) 0x100ffc00000 - 0x100ffebdfff, 2875392 bytes (351 pages) avail memory = 8368832512 (7981 MB) FPSWA Revision = 0x10012, Entry = 0xe00000003e6ce050 Table 'FACP' at 0xe00000003fdf6c28 Table 'SPCR' at 0xe00000003fdf6d60 Table 'DBGP' at 0xe00000003fdf6db0 Table 'APIC' at 0xe00000003fdf71d0 Local APIC address=0xfee00000 Local APIC override entry Local APIC address=0xfee00000 Local SAPIC entry ProcessorId=0x0, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0x1, Id=0x1, Eid=0x0 I/O SAPIC entry Id=0x0, InterruptBase=0x10, Address=0xfed20800 I/O SAPIC entry Id=0x2, InterruptBase=0x1b, Address=0xfed24800 I/O SAPIC entry Id=0x3, InterruptBase=0x26, Address=0xfed26800 I/O SAPIC entry Id=0x6, InterruptBase=0x31, Address=0xfed2c800 I/O SAPIC entry Id=0x7, InterruptBase=0x3c, Address=0xfed2e800 Table 'SPMI' at 0xe00000003fdf6de8 Table 'CPEP' at 0xe00000003fdf70a0 Table 'SSDT' at 0xe00000003fdf4738 Table 'SSDT' at 0xe00000003fdf4bf8 Table 'SSDT' at 0xe00000003fdf5058 Table 'SSDT' at 0xe00000003fdf58c8 Table 'SSDT' at 0xe00000003fdf6138 Table 'SSDT' at 0xe00000003fdf69a8 Table 'SSDT' at 0xe00000003fdf6ae8 MCA: allocated 65536 bytes for state info. SMP: waking up cpu1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: ACPI Id=0, SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: ACPI Id=1, SAPIC Id=1, SAPIC Eid=0 ULE: setup cpu 0 ULE: setup cpu 1 null: io: random: mem: nfslock: pseudo-device ACPI: RSDP 0x3fde6000 00028 (v2 HP) ACPI: XSDT 0x3fde602c 0008C (v1 HP rx2660 00000000 HP 00000000) ACPI: FACP 0x3fdf6c28 000F4 (v3 HP rx2660 00000000 HP 00000000) ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (20100121/tbfadt-625) ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (20100121/tbfadt-625) ACPI: DSDT 0x3fde61c8 0E566 (v1 HP rx2660 00000007 INTL 20050309) ACPI: FACS 0x3fdf6d20 00040 ACPI: SPCR 0x3fdf6d60 00050 (v1 HP 00000000 HP 00000000) ACPI: DBGP 0x3fdf6db0 00034 (v1 HP rx2660 00000000 HP 00000000) ACPI: APIC 0x3fdf71d0 000A0 (v1 HP rx2660 00000000 HP 00000000) ACPI: SPMI 0x3fdf6de8 00050 (v4 HP rx2660 00000000 HP 00000000) ACPI: CPEP 0x3fdf70a0 00034 (v1 HP rx2660 00000000 HP 00000000) ACPI: SSDT 0x3fdf4738 004B3 (v1 HP rx2660 00000006 INTL 20050309) ACPI: SSDT 0x3fdf4bf8 00456 (v1 HP rx2660 00000006 INTL 20050309) ACPI: SSDT 0x3fdf5058 00866 (v1 HP rx2660 00000006 INTL 20050309) ACPI: SSDT 0x3fdf58c8 00866 (v1 HP rx2660 00000006 INTL 20050309) ACPI: SSDT 0x3fdf6138 00866 (v1 HP rx2660 00000006 INTL 20050309) ACPI: SSDT 0x3fdf69a8 00138 (v1 HP rx2660 00000006 INTL 20050309) ACPI: SSDT 0x3fdf6ae8 0013C (v1 HP rx2660 00000006 INTL 20050309) nexus0: registered as a time-of-day clock (resolution 1000us) acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) ACPI timer: 0/7 1/1 1/1 0/4609 1/1 0/57 0/7 0/57 0/7 1/1 -> 4 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5d8004-0xff5d8007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x103c, dev=0x1303, revid=0x00 domain=0, bus=0, slot=1, func=0 class=ff-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0144, statreg=0x0290, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x00 (0 ns), maxlat=0x01 (250 ns) intpin=a, irq=0 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x103c, dev=0x1302, revid=0x00 domain=0, bus=0, slot=1, func=1 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0290, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x00 (0 ns), maxlat=0x01 (250 ns) intpin=a, irq=0 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[14]: type Memory, range 64, base 0x88034000, size 12, enabled map[1c]: type Prefetchable Memory, range 64, base 0x80080000000, size 17, enabled pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x103c, dev=0x1048, revid=0x00 domain=0, bus=0, slot=1, func=2 class=07-00-02, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0290, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x00 (0 ns), maxlat=0x01 (250 ns) intpin=a, irq=0 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[14]: type Memory, range 64, base 0x88033000, size 12, enabled pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x1033, dev=0x0035, revid=0x43 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=a, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x88032000, size 12, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 17 found-> vendor=0x1033, dev=0x0035, revid=0x43 domain=0, bus=0, slot=2, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=b, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x88031000, size 12, enabled pcib0: matched entry for 0.2.INTB pcib0: slot 2 INTB hardwired to IRQ 18 found-> vendor=0x1033, dev=0x00e0, revid=0x04 domain=0, bus=0, slot=2, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns) intpin=c, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x88030000, size 8, enabled pcib0: matched entry for 0.2.INTC pcib0: slot 2 INTC hardwired to IRQ 19 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=0, slot=3, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0187, statreg=0x0290, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0x80000000, size 27, enabled map[14]: type I/O Port, range 32, base 0x1000, size 8, enabled map[18]: type Memory, range 32, base 0x88020000, size 16, enabled pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: child uart0 reqpci0: child uart0 requested type 4 for rid 0x14, but the BAR suart0: mem 0x88033000-0x88033fff irq 16 at device 1.2 on pci0 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) ohci0: mem 0x88032000-0x88032fff irq 17 at device 2.0 on pci0 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x88031000-0x88031fff irq 18 at device 2.1 on pci0 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x88030000-0x880300ff irq 19 at device 2.2 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 vgapci0: port 0x1000-0x10ff mem 0x80000000-0x87ffffff,0x88020000-0x8802ffff at device 3.0 on pci0 pcib1: on acpi0 pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1000, dev=0x0054, revid=0x01 domain=0, bus=1, slot=1, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0230, cachelnsz=32 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x0a (2500 ns) intpin=a, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0x1000, size 8, enabled map[14]: type Memory, range 64, base 0xa0470000, size 14, enabled map[1c]: type Memory, range 64, base 0xa0460000, size 16, enabled pcib1: matched entry for 1.1.INTA pcib1: slot 1 INTA hardwired to IRQ 27 found-> vendor=0x14e4, dev=0x1648, revid=0x10 domain=0, bus=1, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x02b0, cachelnsz=32 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=29 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xa0450000, size 16, enabled pcib1: matched entry for 1.2.INTA pcib1: slot 2 INTA hardwired to IRQ 29 found-> vendor=0x14e4, dev=0x1648, revid=0x10 domain=0, bus=1, slot=2, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x02b0, cachelnsz=32 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=b, irq=30 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xa0440000, size 16, enabled pcib1: matched entry for 1.2.INTB pcib1: slot 2 INTB hardwired to IRQ 30 mpt0: mem 0xa0470000-0xa0473fff,0xa0460000-0xa046ffff irq 27 at device 1.0 on pci1 mpt0: Lazy allocation of 0x100 bytes rid 0x10 type 4 at 0x1100 mpt0: [MPSAFE] mpt0: [ITHREAD] mpt0: MPI Version=1.5.16.0 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK required). mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (10 Max) mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). pci0:1:2:0: bad VPD cksum, remain 249 bge0: mem 0xa0450000-0xa045ffff irq 29 at device 2.0 on pci1 bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0019, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:17:a4:ab:91:2d bge0: [MPSAFE] bge0: [ITHREAD] pci0:1:2:1: bad VPD cksum, remain 249 bge1: mem 0xa0440000-0xa044ffff irq 30 at device 2.1 on pci1 bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: OUI 0x000818, model 0x0019, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: bpf attached bge1: Ethernet address: 00:17:a4:ab:91:2c bge1: [MPSAFE] bge1: [ITHREAD] pcib2: on acpi0 pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: on acpi0 pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: on acpi0 pci4: on pcib4 pci4: domain=0, physical bus=4 uart1: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 24 on acpi0 uart1: [FILTER] uart1: fast interrupt uart1: debug port (9600,n,8,1) cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 Reducing kern.maxvnodes 262788 -> 100000 procfs registered ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 10.000 msec lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 uhub1: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered (probe63:mpt0:1:0:0): Error 22, Unretryable error (probe64:mpt0:1:1:0): Error 22, Unretryable error (probe65:mpt0:1:2:0): Error 22, Unretryable error (probe66:mpt0:1:3:0): Error 22, Unretryable error (probe67:mpt0:1:4:0): Error 22, Unretryable error (probe68:mpt0:1:5:0): Error 22, Unretryable error (probe69:mpt0:1:6:0): Error 22, Unretryable error (probe70:mpt0:1:7:0): Error 22, Unretryable error (probe71:mpt0:1:8:0): Error 22, Unretryable error (probe72:mpt0:1:9:0): Error 22, Unretryable error pass0 at mpt0 bus 0 scbus0 target 7 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: Serial Number 3NM057BF00009718AGZX pass0: 300.000MB/s transfers pass0: Command Queueing enabled WARNING: WITNESS option enabled, expect reduced performance. GEOM: new disk da0 da0 at mpt0 bus 0 scbus0 target 7 lun 0 da0: Fixed Direct Access SCSI-5 device da0: Serial Number 3NM057BF00009718AGZX da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C) Root mount waiting for: usbus2 uhub2: 5 ports with 5 removable, self powered Root mount waiting for: usbus2 Root mount waiting for: usbus2 usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus2 usb_alloc_device: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus2 usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus2 usb_alloc_device: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus2 usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus2 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus2 usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen2.2: <(null)> at usbus2 (disconnected) uhub_reattach_port: could not allocate new device Trying to mount root from ufs:da0p3 ct_to_ts([2010-02-03 00:16:32]) = 1265156192.000000000 start_init: trying /sbin/init usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Setting hostuuidusbd_req_r: 3d1cc772-d2ea-e_enumerate: getting device descriptor at addr 2 failed, USB_ERR_IOERROR 11dc-89dc-0017a4ugen0.2: <(null)> at usbus0 (disconnected) ab912d. Setting hostid: 0x0737ecb8. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/da0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0p3: clean, 12544699 free (55339 frags, 1561170 blocks, 0.3% fragmentation) Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. . Setting hostname: hob.lan.xcllnt.net. bge0: link state changed to DOWN Starting Network: lo0 bge0 bge1. lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 nd6 options=21 bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:17:a4:ab:91:2d media: Ethernet autoselect (none) status: no carrier bge1: flags=8802 metric 0 mtu 1500 options=9b ether 00:17:a4:ab:91:2c bge1: link state changed to DOWN media: Ethernet autoselect (none) status: no carrier Starting devd. Starting Network: bge1. bge1: flags=8802 metric 0 mtu 1500 options=9b ether 00:17:a4:ab:91:2c media: Ethernet autoselect (none) status: no carrier add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 bge0: link UP bge0: link state changed to UP Waiting 30s for the default route interface: ....(bge0) Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/evolution/2.26 /usr/local/lib/gcc/ia64-portbld-freebsd9.0/3.4.6 /usr/local/lib/graphviz /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/pth /usr/local/lib/qt4 Creating and/or trimming log files. Starting syslogd. No core dumps found. Setting date via ntp. ts_to_ct(1265156211.365533028) = [2010-02-03 00:16:51] 2 Feb 16:16:51 ntpdate[917]: step time server 192.168.4.1 offset 1.105587 sec Starting rpcbind. NFS access cache time=60 Setting NIS domain: xcllnt. Starting ypbind. Clearing /tmp. Starting statd. Starting lockd. Recovering vi editor sessions:. Starting ntpd. Starting rwhod. Starting squid. Starting dbus. Starting hald. Starting gmond. Starting gdm. Starting avahi-daemon. Starting avahi-dnsconfd. Starting sshd. Starting sendmail. Starting cron. Starting inetd. Tue Feb 2 16:16:57 PST 2010 FreeBSD/ia64 (hob.lan.xcllnt.net) (ttyu0) login: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x07 Depth 120 xpt_release_devq(0): requested 1 > present 0 xpt_release_devq(0): requested 1 > present 0 xpt_release_devq(0): requested 1 > present 0 *ad nauseam* -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 00:32:53 2010 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 116B51065670; Wed, 3 Feb 2010 00:32:53 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id EDC918FC08; Wed, 3 Feb 2010 00:32:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KX800BWXPI87120@asmtp026.mac.com>; Tue, 02 Feb 2010 16:32:34 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002020204 From: Marcel Moolenaar In-reply-to: <4B68B7AC.8050908@FreeBSD.org> Date: Tue, 02 Feb 2010 16:32:32 -0800 Message-id: References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Wed, 03 Feb 2010 00:32:53 -0000 On Feb 2, 2010, at 3:39 PM, Alexander Motin wrote: > Marcel Moolenaar wrote: >> On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: >>> Whether it is related or not, both issues definitely should be fixed. >>> Could you give me an access to debug that system, or it is in use? >> >> Unfortunately, I can't give you access to this machine. > > What's about full verbose dmesg up to the first few errors? *snip* Tue Feb 2 16:16:57 PST 2010 FreeBSD/ia64 (hob.lan.xcllnt.net) (ttyu0) login: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x07 Depth 120 xpt_release_devq(0): requested 1 > present 0 xpt_release_devq(0): requested 1 > present 0 xpt_release_devq(0): requested 1 > present 0 *ad nauseam* Actually, it's not ad nauseam. Every queue full event is followed by 256 xpt_release_devq(0) lines. Looks related to me... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 04:05:03 2010 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 D81401065676 for ; Wed, 3 Feb 2010 04:05:03 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C7D268FC15; Wed, 3 Feb 2010 04:05:03 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o13452g2071882; Wed, 3 Feb 2010 04:05:03 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4B68F5EE.9060606@freebsd.org> Date: Wed, 03 Feb 2010 12:05:02 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Justin Teller 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: Bug in kern_umtx.c -- read-write locks 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, 03 Feb 2010 04:05:03 -0000 Justin Teller wrote: > I was working on a highly threaded app (125+ threads) that was using > the pthread rw locks, and we were stalling at strange times. After a > lot of debugging in our app, we found that a call to > pthread_rwlock_wrlock() would sometimes never return -- it seemed like > a wakeup was lost. After we convinced ourselves the bug wasn't in the > app's locking code, I started digging into the kernel. I found that > there is an issue where a wakeup can be "lost" when a thread goes to > sleep calling pthread_rwlock_wrlock. The issue is in the file > kern_umtx.c in the function do_rw_wrlock(): the code busies the lock > before sleeping, but when it tries to set the waiters bit, it's > looking at at old value (from the "try-lock" just before the busy). > This allows a race where a thread can go to sleep w/o setting the > waiters bit. Then the last thread to unlock won't wakeup the sleeping > thread. The patch below (based off of 8.0 release) fixes my problem > for the write lock and should fix the complimentary issue in > do_rw_rdlock. > > Committed, thanks! From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 05:16:30 2010 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 AE1591065670; Wed, 3 Feb 2010 05:16:30 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 79B088FC0A; Wed, 3 Feb 2010 05:16:30 +0000 (UTC) Received: by pzk40 with SMTP id 40so972315pzk.7 for ; Tue, 02 Feb 2010 21:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d2feevyHe0wBpoN8VSEk2d/fOgwvdXMIwp6lrr6cO28=; b=JLRJeAgoJlsSgfXK7LDvOvNvxbxU7a0nQntuBhiI6fG+Ph/aEAigxskSbg6RusuXPO woH9YBBQHDQYD999wsKZ/RFw96YTMeiDQ9S6x4dg7BtcYlXFj9usgKfiSRs2evH5/x0Y Z65LFdID8R9VGicOMdLLqKgWqrS26BpHdBoDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZySeOiHWL8/vLcoTC3FBXsm1U8qhcexrgNXNPU1qL+OGxIXtuYd/B1F9WGqx0hceSW rNUjl/LThPALGLGeBg25zkv7d0GdAtP87tjduV6Te05bskUlSxMzBQw15TtTx9F9WKUk uAxeRw1iqFK9ekRIMMLksuPFiLmUkNPO0jYCo= MIME-Version: 1.0 Received: by 10.142.152.6 with SMTP id z6mr1200914wfd.214.1265174189885; Tue, 02 Feb 2010 21:16:29 -0800 (PST) In-Reply-To: <4B68F5EE.9060606@freebsd.org> References: <4B68F5EE.9060606@freebsd.org> Date: Tue, 2 Feb 2010 21:16:29 -0800 Message-ID: <7d6fde3d1002022116v28d50f75me27e7208619e2a3c@mail.gmail.com> From: Garrett Cooper To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Justin Teller Subject: Re: Bug in kern_umtx.c -- read-write locks 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, 03 Feb 2010 05:16:30 -0000 On Tue, Feb 2, 2010 at 8:05 PM, David Xu wrote: > Justin Teller wrote: >> >> I was working on a highly threaded app (125+ threads) that was using >> the pthread rw locks, and we were stalling at strange times. =A0After a >> lot of debugging in our app, we found that a call to >> pthread_rwlock_wrlock() would sometimes never return -- it seemed like >> a wakeup was lost. =A0After we convinced ourselves the bug wasn't in the >> app's locking code, I started digging into the kernel. =A0I found that >> there is an issue where a wakeup can be "lost" when a thread goes to >> sleep calling pthread_rwlock_wrlock. =A0The issue is in the file >> kern_umtx.c in the function do_rw_wrlock(): the code busies the lock >> before sleeping, but when it tries to set the waiters bit, it's >> looking at at old value (from the "try-lock" just before the busy). >> This allows a race where a thread can go to sleep w/o setting the >> waiters bit. =A0Then the last thread to unlock won't wakeup the sleeping >> thread. =A0The patch below (based off of 8.0 release) fixes my problem >> for the write lock and should fix the complimentary issue in >> do_rw_rdlock. >> >> =A0 > > Committed, thanks! This might be the reason why the pthreaded application I was working on was crashing when I had it spawn more than 100 threads (I tried 2k and 20k simple, short-lived threads that used a basic mutex, and it got into some deadlock state and bombed)... I'll see whether or not this fixes my issue as well (but FWIW Linux sucked when I ran the pthreaded app too and was busting up all over the place)... Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 07:20:44 2010 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 EC270106566B; Wed, 3 Feb 2010 07:20:43 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFAB8FC12; Wed, 3 Feb 2010 07:20:42 +0000 (UTC) Received: by fxm26 with SMTP id 26so130708fxm.13 for ; Tue, 02 Feb 2010 23:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xxpLgkbH5ordXCtcc2ZdYPZS28hbtdY5+YGaA0I25dk=; b=RaCWCbqF6TvEoee0Sz8qEsEehG24raCqnIrGp1ej0OtdZ3zYQHqwSKpsOusFDh+6CA QG2pZAPukzEt0hDq6tb26Bh+mu/2ObAV/zzMe6yQHQNDZFeb5oQ/Kw5t/S3vW7JaBQvx 7Y8ARd9R0RxXuouy0PLxq7nLI/zuKLFZJSCl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B+kYcBw6KGPEY0I5U8Hd7/OyuMn0nK5fI8Fqas+kSBZcZjoSsNKcA2OrAQ9usjdDfU iPn4EjFf2fmibTbAuCh6fUDj398fcZBDI5hL5pieUOlCktQs3Ne5GWHtRnjn+JQQywgM ZzS3m3Wh3NrdHs3a1Brz9JwyYhrbZ63DUBIIU= MIME-Version: 1.0 Received: by 10.223.164.156 with SMTP id e28mr1119608fay.27.1265181642136; Tue, 02 Feb 2010 23:20:42 -0800 (PST) In-Reply-To: <179b97fb1002011424p4a799ff6t8f6b39e6f4b66828@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> <179b97fb1002011424p4a799ff6t8f6b39e6f4b66828@mail.gmail.com> Date: Wed, 3 Feb 2010 08:20:42 +0100 Message-ID: <4e6cba831002022320u2bd5f325m6564556a1abcf4c5@mail.gmail.com> From: Giovanni Trematerra To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. 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, 03 Feb 2010 07:20:44 -0000 On Mon, Feb 1, 2010 at 11:24 PM, Brandon Gooch wrote: > On Mon, Feb 1, 2010 at 4:04 PM, Giovanni Trematerra > wrote: >> On Fri, Jan 29, 2010 at 9:12 PM, Brandon Gooch >> wrote: >>> On Fri, Jan 29, 2010 at 3:44 PM, Giovanni Trematerra >>> wrote: >>>> On Thu, Jan 28, 2010 at 10:55 PM, Randall Stewart w= rote: >>>>> I was running SCHED_ULE on an 8.0 and everything works >>>>> fine. >>>>> >>>>> On my 2 core head of yesterday I tried both SCHED_ULE AND >>>>> 4BSD.. and got the same results ;-0 >>>>> >>>>> I will try my 4 core when I get home ;-) >>>>> >>>>> R >>>>> On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: >>>>> >>>>>> On Thu, 28 Jan 2010 10:30:37 -0800 >>>>>> Randall Stewart wrote: >>>>>> >>>>>>> All: >>>>>>> >>>>>>> I just found a very strange thing with yesterdays head. >>>>>>> >>>>>>> The program >>>>>>> >>>>>>> http://www.freebsd.org/~rrs/my_thr.c >>>>>>> >>>>>>> I compile it: >>>>>>> >>>>>>> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >>>>>>> >>>> >>>> Hi Randal, >>>> I tried your code on an 8-core machine with a fresh head (i386) >>>> I have no problems with both 4BSD and ULE scheduler. >>>> I even upping the value of macro NUM_THREAD to 24 but I didn't notice >>>> nothing strange. >>>> >>>> Have you got a chance to reproduce it on your machines? >>>> >>>> -- >>>> Gianni >>>> _______________________________________________ >>>> 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" >>>> >>> >>> I ran it on my dual-core, 8-STABLE/ULE laptop. The very first time I >>> ran it, I experienced the temporary "seizure". It took several more >>> runs before I could get it to happen again. >>> >> >> Hi Brandon, >> which kind of processor your laptop has? AMD or Intel? >> -- >> Gianni >> > > CPU: Intel(R) Core(TM)2 Duo CPU =A0 =A0 L7100 =A0@ 1.20GHz (1197.01-MHz K= 8-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0x6fb =A0Stepping =3D 11 > =A0Features=3D0xbfebfbff > =A0Features2=3D0xe3bd > =A0AMD Features=3D0x20100800 > =A0AMD Features2=3D0x1 > =A0TSC: P-state invariant > > -Brandon > Hi, all I cannot reproduce the issue at least on 8.0-RELEASE. Can you please update to r203414 and give it a try? Thank you. -- Gianni From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 12:50:13 2010 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 72CDB106568D for ; Wed, 3 Feb 2010 12:50:13 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 26D428FC18 for ; Wed, 3 Feb 2010 12:50:13 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 46B7514DA50A for ; Wed, 3 Feb 2010 13:50:12 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0Fk3ccceIHzJ for ; Wed, 3 Feb 2010 13:50:02 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 8C64A14DA505 for ; Wed, 3 Feb 2010 13:50:02 +0100 (CET) Message-ID: <4B6970F8.2030807@FreeBSD.org> Date: Wed, 03 Feb 2010 13:50:00 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: FreeBSD Current References: <4B57780F.4070907@FreeBSD.org> In-Reply-To: <4B57780F.4070907@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] 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, 03 Feb 2010 12:50:13 -0000 El 2010. 01. 20. 22:39, Gabor Kovesdan escribió: > Hi all, > > I've just committed the BSDL versions of bc/dc ported from OpenBSD. FYI. I've just committed math/gnubc for those, who still want to use the GNU version. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 13:12:33 2010 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 788CE106566C for ; Wed, 3 Feb 2010 13:12:33 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 353A88FC08 for ; Wed, 3 Feb 2010 13:12:33 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ncf23-0003KR-5n; Wed, 03 Feb 2010 14:12:35 +0100 Message-ID: <4B69763E.1070901@continum.net> Date: Wed, 03 Feb 2010 14:12:30 +0100 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4B60694A.8010900@continum.net> <20100127175934.GN1187@michelle.cdnetworks.com> In-Reply-To: <20100127175934.GN1187@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: realtek 8111C-GR freeze with latest 8.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: Wed, 03 Feb 2010 13:12:33 -0000 Hello, Pyun YongHyeon wrote: [frequent hangs of RTL8111C-GR on Supermicro X7SLN-F mainboards] > Would you show me more information for the issue? Frequent freeze > is ambiguous to me. More specific issues like, watchdog timeout, or > console output generated by re(4) would be better to me. If you > know how to reliably trigger the issue, also include that > information. booting the system in verbose mode didn't show any difference. Any pointer to info on how one can debug re (4)? In the meantime we saw that very similar problems have been reported three months before: http://www.pubbs.net/freebsd/200909/111629/ What can we do in order to support you finding/fixing the bug? Best regards vt P.S.: The re manpage lists 8111S but not 8111C as supported. Maybe you need just access to a system in order to adapt the driver? If so - let me know. -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 14:00:48 2010 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 EFE62106566C for ; Wed, 3 Feb 2010 14:00:48 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 795718FC12 for ; Wed, 3 Feb 2010 14:00:48 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so269834fgb.13 for ; Wed, 03 Feb 2010 06:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=onQv4SQ/d05aRx+4WtBdclr6m8ZffBPAinyL2fE+kkk=; b=VNHQJU9Snx0rYBepilT7B3QYnZRRrpdcJ1pxID/3vUKYItxB13heSpLhuGfWrbsjNV IuMorNYLLhbL2bJsUtNdXp5H0K7CC7bZOA5kf5wFw/LKDNROAbJGAf47f0V8yiyMge9N bD3/7zzo7FKHQKuoi57vvcbJTaA7KLAzl2uZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=yB+LkZvZWrIn1hCmDxtBpPpqNysRz8n03Y/g1bMMpSBMb5mOEXyuFOxSxg9a9TMv9n pLmDGmmprl32L84kouSr82Z/du0XRjY3gAw5NVm2QR5XoyJGUu5HgiIzDSwbuL75x12Y GRw5Kr640x/Ne8lg4blO+H/3unyDg2f4oSHVk= Received: by 10.87.15.29 with SMTP id s29mr1610403fgi.34.1265205647171; Wed, 03 Feb 2010 06:00:47 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm3169130fxm.13.2010.02.03.06.00.45 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 06:00:46 -0800 (PST) Sender: Alexander Motin Message-ID: <4B69817B.8090706@FreeBSD.org> Date: Wed, 03 Feb 2010 16:00:27 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4B55D9D4.1000008@FreeBSD.org> <823F6536-32A7-4BC6-9C6A-C84865A38458@samsco.org> <4B570B4C.9000203@jrv.org> In-Reply-To: <4B570B4C.9000203@jrv.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements 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, 03 Feb 2010 14:00:49 -0000 James R. Van Artsdalen wrote: > At some point I hope to add support for staggered spin-ups, perhaps a > loader.conf setting for people with more than 20-30 disks. At the > 100-120 disk level it seems unlikely that any reasonable fixed delay > would be reasonable. I've just added Power Up In Stand-by (PUIS) feature support into CAM ATA in HEAD. It is one of the ways to implement staggered spin-up for ATA devices. Now CAM will spin-up no more then 4 of such devices at a time. Another way, based on SATA hard-reset sequence, is more complicated (especially when port multipliers used) and not supported yet. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 14:40:38 2010 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 EC8931065672 for ; Wed, 3 Feb 2010 14:40:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id AFAD68FC16 for ; Wed, 3 Feb 2010 14:40:37 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o13EebUG032908 for ; Wed, 3 Feb 2010 06:40:37 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o13EebuE032907 for current@freebsd.org; Wed, 3 Feb 2010 06:40:37 -0800 (PST) (envelope-from david) Date: Wed, 3 Feb 2010 06:40:37 -0800 From: David Wolfskill To: current@freebsd.org Message-ID: <20100203144037.GA32250@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed 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, 03 Feb 2010 14:40:38 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just updated my build machine from r203376 to r203425, which seeme dto go well, but after I issued "shutdown -p now" (as I leave the machine off when it's not in use), I saw the following on the serial console: Uptime: 1m45s (noperiph:aacp0:0:0:0): Device power down failed (noperiph:aacp0:0:1:0): Device power down failed (noperiph:aacp0:0:2:0): Device power down failed (noperiph:aacp0:0:3:0): Device power down failed (noperiph:aacp0:0:6:0): Device power down failed Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex AAC I/O lock (AAC I/O lock) r =3D 0 (0xc56f2130) lock= ed @ /usr/src/sys/dev/aac/aac.c:844 KDB: stack backtrace: db_trace_self_wrapper(c0ca2cb6,e9aefb14,c08d68a5,c0c48d6b,34c,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0c48d6b,34c,ffffffff,c0f3bf6c,e9aefb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0ca5178,e9aefb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cd9bf4,e9aefb88,c55717f8,...) at witness_warn+0x1fd trap(e9aefbec) at trap+0x19e calltrap() at calltrap+0x6 --- trap 0xc, eip =3D 0xc048550b, esp =3D 0xe9aefc2c, ebp =3D 0xe9aefc44 --- xpt_done(c5200704,c56f2130,8,c0c48d6b,c56f2000,...) at xpt_done+0x1b aac_cam_complete(c56fcec0,0,c0c48d6b,34c,c55fbd80,...) at aac_cam_complete+= 0x120 aac_new_intr(c56f2000,e9aefcc8,c0880bb4,c0e00340,c5576638,...) at aac_new_i= ntr+0x1f0 intr_event_execute_handlers(c55717f8,c5576600,c0c9adc4,533,c5576670,...) at= intr_event_execute_handlers+0x125 ithread_loop(c56f1bd0,e9aefd38,c0c9ab3d,343,c55717f8,...) at ithread_loop+0= x9f fork_exit(c08698b0,c56f1bd0,e9aefd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xe9aefd70, ebp =3D 0 --- Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x14 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc048550b stack pointer =3D 0x28:0xe9aefc2c frame pointer =3D 0x28:0xe9aefc44 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq24: aac0) [thread pid 12 tid 100024 ] Stopped at xpt_done+0x1b: movl 0x14(%eax),%ebx db> show locks exclusive sleep mutex AAC I/O lock (AAC I/O lock) r =3D 0 (0xc56f2130) lock= ed @ /usr/src/sys/dev/aac/aac.c:844 db>=20 I'll leave the machine in that state so I can poke at it, if there's interest in figuring out what's wrong. My laptop is a bit behind the build machine at the moment -- it's just started building the stable/8 kernel -- but I expect to be building head on it soon, and I'll report if anything interesting turns up. And to clarify, at r203376, the build machine handled the poweroff request just fine. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktpiuQACgkQmprOCmdXAD2K8wCffTKaq5l4TUlFa+DYb1GKPmCZ dBAAn3CzW6MlhzzgHaOZm4XHvbScOLQB =LsLf -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 13:38:16 2010 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 C7265106566B for ; Wed, 3 Feb 2010 13:38:16 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 584F88FC0A for ; Wed, 3 Feb 2010 13:38:15 +0000 (UTC) Received: from greatsheep.chaos.base (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id o13DcAS2025338; Wed, 3 Feb 2010 14:38:11 +0100 Received: from greatsheep.chaos.base ([85.181.52.80] helo=greatsheep.chaos.base) by ASSP.nospam.UpPeRnEt; 3 Feb 2010 14:38:10 +0100 Date: Wed, 3 Feb 2010 14:38:01 +0100 From: Marc UBM Bocklet To: Jung-uk Kim Message-Id: <20100203143801.d83b65ac.ubm@u-boot-man.de> In-Reply-To: <201002021643.09859.jkim@FreeBSD.org> References: <20100201184446.2325c04e.ubm.freebsd@gmail.com> <201002011617.31527.jkim@FreeBSD.org> <20100202193413.a497dd9d.ubm.freebsd@gmail.com> <201002021643.09859.jkim@FreeBSD.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.4; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Feb 2010 16:31:49 +0000 Cc: Marc UBM Bocklet , freebsd-current@freebsd.org Subject: Re: vidcontrol / resolution problems with latest current 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, 03 Feb 2010 13:38:16 -0000 On Tue, 2 Feb 2010 16:43:07 -0500 Jung-uk Kim wrote: > > > > Can anyone point me to a solution / is more info required? > > > > > > Hmm... The attached patch should restore the previous behavior. > > > > No change, unfortunately. Anything I can provide to help? > > How about the attached patch, then? Thanks for the quick response! Unfortunately, no change, even with the new patch. Screen stays on and lit up, but I see not text. Starting X blindly still works. Bye Marc From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 16:59:47 2010 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 2228D106566B for ; Wed, 3 Feb 2010 16:59:47 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id E074C8FC1D for ; Wed, 3 Feb 2010 16:59:46 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o13GxkuS033701 for ; Wed, 3 Feb 2010 08:59:46 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o13GxkZR033700 for current@freebsd.org; Wed, 3 Feb 2010 08:59:46 -0800 (PST) (envelope-from david) Date: Wed, 3 Feb 2010 08:59:46 -0800 From: David Wolfskill To: current@freebsd.org Message-ID: <20100203165946.GC32250@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20100203144037.GA32250@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uh9ZiVrAOUUm9fzH" Content-Disposition: inline In-Reply-To: <20100203144037.GA32250@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed 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, 03 Feb 2010 16:59:47 -0000 --uh9ZiVrAOUUm9fzH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2010 at 06:40:37AM -0800, David Wolfskill wrote: > Just updated my build machine from r203376 to r203425, which seeme dto > go well, but after I issued "shutdown -p now" (as I leave the machine > off when it's not in use), I saw the following on the serial console: >=20 > Uptime: 1m45s > (noperiph:aacp0:0:0:0): Device power down failed > (noperiph:aacp0:0:1:0): Device power down failed > (noperiph:aacp0:0:2:0): Device power down failed > (noperiph:aacp0:0:3:0): Device power down failed > (noperiph:aacp0:0:6:0): Device power down failed > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex AAC I/O lock (AAC I/O lock) r =3D 0 (0xc56f2130) lo= cked @ /usr/src/sys/dev/aac/aac.c:844 > KDB: stack backtrace: > db_trace_self_wrapper(c0ca2cb6,e9aefb14,c08d68a5,c0c48d6b,34c,...) at db_= trace_self_wrapper+0x26 > ... > I'll leave the machine in that state so I can poke at it, if there's > interest in figuring out what's wrong. My laptop is a bit behind > the build machine at the moment -- it's just started building the > stable/8 kernel -- but I expect to be building head on it soon, and > I'll report if anything interesting turns up. >=20 > And to clarify, at r203376, the build machine handled the poweroff > request just fine. Tried the same experiment with the laptop; didn't get the above failure, but am seeing many (as in "hundreds") of atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! atapi_poll called! with an occasional=20 t_delta 15.feae7d37eafc8830 too short or t_delta 16.045c565d970952d0 too long tossed in (maybe one of these t_delta whines for every 60 or so "atapi_poll called!" messages?). I'll interrupt the laptop & get it up & running again; the build machine is still at the DDB prompt. Each is i386 architecture; each was just upgraded this morning from r203376 to r203425. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uh9ZiVrAOUUm9fzH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktpq4EACgkQmprOCmdXAD12sQCfVwBmAzSceOGfV2674LTtTlAh rAgAoIingASUsZn8i9dMJgZyG6rfvhZ+ =BXrW -----END PGP SIGNATURE----- --uh9ZiVrAOUUm9fzH-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 17:14:18 2010 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 374421065692 for ; Wed, 3 Feb 2010 17:14:18 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id D9CB88FC1A for ; Wed, 3 Feb 2010 17:14:17 +0000 (UTC) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id C7F1D6E5AB for ; Wed, 3 Feb 2010 17:58:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:subject:message-id:mime-version:content-type: content-transfer-encoding; s=selector1; bh=D6xrIMsYbi4PEdhJaQ0ia Trwtrs=; b=B0ul1YeFhZvl8O8Fvmb/P9xk55mv1KSeX6U5ggC4KndmSxgPrwIG8 JIN31RtEPl8cOdXjkXwUsytbewfeeZq0XIwrYkP0k29RaF+5xY+N5ceTB4IvLi/f jYdqi6p7alyKO63t63vOMkSaTbQZ7unkT4rGlXY/tYbwTsrlBbokdY= Received: from [10.255.253.2] (unknown [10.255.253.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id BAE336E5AA for ; Wed, 3 Feb 2010 17:58:33 +0100 (CET) Date: Wed, 03 Feb 2010 17:58:33 +0100 From: Goran Lowkrantz To: current@freebsd.org Message-ID: <0217C80176ED4ABCC821312F@[10.255.253.2]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Q: Building release in jail? 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, 03 Feb 2010 17:14:18 -0000 Hi, Tried this over on questions but no takers. So I try it here: I am trying to get a working release build environment in a jail but it fails because the release script needs to mount devfs in the chrooted build environment and the md devices used to build the images. I have set the following syscontrols vfs.usermount=1 security.jail.mount_allowed=1 security.jail.chflags_allowed=1 but still can't mount inside the jail. I tried with delegating the chroot filesystem to the jail using zfs jail and can mount it within the jail (but not umount it???) but still can't mount the md devices on this jaild filesystem. My filesystem setup is with the jail root at /usr/jails/release/ where the startup scripts put a restricted devfs on /usr/jails/release/dev. I put my CVS copy at /home/ncvs (/usr/jails/release/usr/home/ncvs) and the chroot target at /home/release/8/dev (/usr/jails/release/usr/home/release/8). I managed to mount a devfs on /usr/jails/release/usr/home/release/8/dev from outside the jail after the release make had started as a workaround but whatever I did, mounting md-devices on /mnt (/usr/home/release/8/mnt) (/usr/jails/release/usr/home/release/8/mnt) always failed. Is it possible to build a release in a jail? What am I missing? /glz --- Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 17:34:22 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id DEC781065672; Wed, 3 Feb 2010 17:34:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 3 Feb 2010 12:33:58 -0500 User-Agent: KMail/1.6.2 References: <20100201184446.2325c04e.ubm.freebsd@gmail.com> <201002021643.09859.jkim@FreeBSD.org> <20100203143801.d83b65ac.ubm@u-boot-man.de> In-Reply-To: <20100203143801.d83b65ac.ubm@u-boot-man.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002031234.16137.jkim@FreeBSD.org> Cc: Marc UBM Bocklet , Marc UBM Bocklet Subject: Re: vidcontrol / resolution problems with latest current 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, 03 Feb 2010 17:34:22 -0000 On Wednesday 03 February 2010 08:38 am, Marc UBM Bocklet wrote: > On Tue, 2 Feb 2010 16:43:07 -0500 > > Jung-uk Kim wrote: > > > > > Can anyone point me to a solution / is more info required? > > > > > > > > Hmm... The attached patch should restore the previous > > > > behavior. > > > > > > No change, unfortunately. Anything I can provide to help? > > > > How about the attached patch, then? > > Thanks for the quick response! > > Unfortunately, no change, even with the new patch. Screen stays on > and lit up, but I see not text. Starting X blindly still works. What happens if you blindly display screen-full of text ('dmesg' or 'ls -lR /' for example)? Also, can you show me verbose boot messages and 'vidcontrol -i mode' output? 'vidcontrol -i adapter' output from the mode (VESA_800x600) will be useful as well, e.g., 'vidcontrol -i adapter > vesa.txt' and please send me the vesa.txt. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 17:40:13 2010 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 B5CB11065692 for ; Wed, 3 Feb 2010 17:40:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4351B8FC15 for ; Wed, 3 Feb 2010 17:40:12 +0000 (UTC) Received: by fxm10 with SMTP id 10so1493438fxm.3 for ; Wed, 03 Feb 2010 09:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jmccCo5vwRlqeFRUTdsT/loN/pata7Eb+v6rH5FMWfI=; b=ezm/9Bx6BUYc26vB5fjosYe17tv0WjM8JFUeHl324J+10x1GoR/qLeKNTMqohiC3Eg Qeny6EnT+bwb+BezniTk3bYhLCxCiCteuRlFjEyRANB7klXFzR+qntV9prW8hCruUtQB uLYRd7n7QERLeIajuRkWsxbsOctAYvmjWDYxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YQBOcqxg9wOKoX79iRGj8hHQY0D9tdsXvlSJWnzxQZmPxZ/iGtAhk1V4zQufW9nvwY twOlHZ2d1dSBzFwqZJn/3W3DGft5mYGn1kq2ufEaB6N4zk0gAf9vEXGJ282JJMJb0kjB Rvr6eua34vM9CDYctcZ2NkliSfQ7HBVm1oNxo= Received: by 10.87.62.39 with SMTP id p39mr360185fgk.9.1265218812011; Wed, 03 Feb 2010 09:40:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm3321691fxm.15.2010.02.03.09.40.10 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 09:40:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4B69B4F6.1090608@FreeBSD.org> Date: Wed, 03 Feb 2010 19:40:06 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Wolfskill , FreeBSD-Current References: <20100203144037.GA32250@bunrab.catwhisker.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Re: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed 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, 03 Feb 2010 17:40:13 -0000 David Wolfskill wrote: > On Wed, Feb 03, 2010 at 06:40:37AM -0800, David Wolfskill wrote: >> Just updated my build machine from r203376 to r203425, which seeme dto >> go well, but after I issued "shutdown -p now" (as I leave the machine >> off when it's not in use), I saw the following on the serial console: >> >> Uptime: 1m45s >> (noperiph:aacp0:0:0:0): Device power down failed >> (noperiph:aacp0:0:1:0): Device power down failed >> (noperiph:aacp0:0:2:0): Device power down failed >> (noperiph:aacp0:0:3:0): Device power down failed >> (noperiph:aacp0:0:6:0): Device power down failed >> Kernel page fault with the following non-sleepable locks held: >> exclusive sleep mutex AAC I/O lock (AAC I/O lock) r = 0 (0xc56f2130) locked @ /usr/src/sys/dev/aac/aac.c:844 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0ca2cb6,e9aefb14,c08d68a5,c0c48d6b,34c,...) at db_trace_self_wrapper+0x26 >> ... >> I'll leave the machine in that state so I can poke at it, if there's >> interest in figuring out what's wrong. My laptop is a bit behind >> the build machine at the moment -- it's just started building the >> stable/8 kernel -- but I expect to be building head on it soon, and >> I'll report if anything interesting turns up. That was my change r203420. `sysctl kern.cam.power_down=0` should disable new behavior. It can be a bug of aac driver. Is it repeatable each time at the same place? > Tried the same experiment with the laptop; didn't get the above failure, > but am seeing many (as in "hundreds") of > > atapi_poll called! > atapi_poll called! This looks like atapicam misfeature. I'll look on it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 17:49:04 2010 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 3D6FF1065670 for ; Wed, 3 Feb 2010 17:49:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id BC63C8FC1E for ; Wed, 3 Feb 2010 17:49:03 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so50910fgg.13 for ; Wed, 03 Feb 2010 09:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=A0L1b0Ly+46JySUoyqKdaCQI/DHkr/0n1Urx9aRts0k=; b=tI/LjbCi6h4qmmmkdHH5AEnfzom0jUwD+dG3fr3R64ZBIojSAv/FXwJ/1zC9qq19zo jF6iY+vMy+gvqzWV4lhUpBrO7ZygFb+9vxz5FWSuWn+LNO4Dit8fEnRW/pSzpRxO+oxw brp2UxTbEVJdg4st5lManbx0xuF2ycN21N2rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VhNtI+sI+zXZWR2T6mjcnqwtmiTSKH8fRi1ueZhj4xk7cWhhPB/hzmV+Sywqn6HSp4 dljYz397f6uy6SmAwPYgu8P6OqGh+Wy11IUlXd9D8UH3e9TD9cMVjL2gd82HsQbm2O1s i6GgHky2NqLEp5d3/ks4bhOoRz2wIe6d9/gYk= Received: by 10.86.6.30 with SMTP id 30mr218560fgf.62.1265219340692; Wed, 03 Feb 2010 09:49:00 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm3310049fxm.5.2010.02.03.09.48.59 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 09:48:59 -0800 (PST) Sender: Alexander Motin Message-ID: <4B69B707.2020504@FreeBSD.org> Date: Wed, 03 Feb 2010 19:48:55 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Michael Reifenberger References: <1264818191.00213314.1264807803@10.7.7.3> <1264861382.00213426.1264851002@10.7.7.3> <1264864983.00213434.1264852204@10.7.7.3> <1265026986.00214174.1265016606@10.7.7.3> <1265030583.00214182.1265019602@10.7.7.3> <1265037797.00214273.1265026205@10.7.7.3> <1265037810.00214278.1265026802@10.7.7.3> <1265048584.00214331.1265035802@10.7.7.3> In-Reply-To: <1265048584.00214331.1265035802@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Odd ada(4) failures when trying using USB scanner 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, 03 Feb 2010 17:49:04 -0000 Michael Reifenberger wrote: > On Mon, 1 Feb 2010, Alexander Motin wrote: > >> Date: Mon, 01 Feb 2010 14:18:17 +0200 >> From: Alexander Motin >> To: Michael Reifenberger >> Cc: FreeBSD-Current >> Subject: Re: Odd ada(4) failures when trying using USB scanner >> >> Michael Reifenberger wrote: >>> I'm using -current as of r202157. >>> >>> When attaching an epson USB scanner and trying to `scanimage -L` >>> I get a freeze for some time and the following console logs: >>> ... >>> ata1: FAILURE - odd-sized DMA transfer attempt 5 % 2 >>> ata1: setting up DMA failed >> >> I would say that scanner application tries to probe all CAM devices, >> looking for scanner. While doing it, it uses SCSI/ATAPI commands with >> odd-sized transfer sizes. It causes errors from ata(4) and triggers bug >> in IXP700 AHCI controller. Odd-sized requests are generally not >> supported by ATA/SATA. Second problem is in work now. > > Could odd-sized commands be prohibited/ignored by the driver then? I've recently committed patch to 9-CURRENT, that should block sending of SCSI commands to non-ATAPI devices. That should fix your problem. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 18:02:47 2010 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 014A8106566C; Wed, 3 Feb 2010 18:02:47 +0000 (UTC) (envelope-from jamesbrandongooch@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 8BA9F8FC2B; Wed, 3 Feb 2010 18:02:46 +0000 (UTC) Received: by vws11 with SMTP id 11so892712vws.13 for ; Wed, 03 Feb 2010 10:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5NLjAZqW7s+JQpB3dWncA+lsHT+ETbd0TWWkD3Rw/cQ=; b=i2+hWGPdBXEMGtPFMrdPRh9/HGhNgh5x7hbJOv/9EXbvxtOk/7bUeY4/ShnZ9s9u/G nY7xdj/h+Jo07UECEvr5041m9SilnqLtA/TncDXBMd0gmWeCtD20K8Ks86j1nzSwYD5E pU+lSeZwNSdI/kHG1JXK1rHgw9tOQO0r4RHXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tdRm3Sn4z+B8csF7FUspccckzwermu1A95+ZeDh32Tg+VGYGQYh0alG2Kxkw1uY2JH krmApG8xaKuFD5skZQ/ii2N4LrO8h4vg5jHgK8yq7EkAggw00nFGh39baDYBV7zIhNBM IiGoXXvYQ+40myUq1HUI2XNGgRLEy7hF2vP4Q= MIME-Version: 1.0 Received: by 10.142.250.21 with SMTP id x21mr1755284wfh.216.1265220164508; Wed, 03 Feb 2010 10:02:44 -0800 (PST) In-Reply-To: <4e6cba831002022320u2bd5f325m6564556a1abcf4c5@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> <179b97fb1002011424p4a799ff6t8f6b39e6f4b66828@mail.gmail.com> <4e6cba831002022320u2bd5f325m6564556a1abcf4c5@mail.gmail.com> Date: Wed, 3 Feb 2010 12:02:44 -0600 Message-ID: <179b97fb1002031002g617aee35uec79e3367b2ff7a5@mail.gmail.com> From: Brandon Gooch To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. 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, 03 Feb 2010 18:02:47 -0000 On Wed, Feb 3, 2010 at 1:20 AM, Giovanni Trematerra wrote: > On Mon, Feb 1, 2010 at 11:24 PM, Brandon Gooch > wrote: >> On Mon, Feb 1, 2010 at 4:04 PM, Giovanni Trematerra >> wrote: >>> On Fri, Jan 29, 2010 at 9:12 PM, Brandon Gooch >>> wrote: >>>> On Fri, Jan 29, 2010 at 3:44 PM, Giovanni Trematerra >>>> wrote: >>>>> On Thu, Jan 28, 2010 at 10:55 PM, Randall Stewart = wrote: >>>>>> I was running SCHED_ULE on an 8.0 and everything works >>>>>> fine. >>>>>> >>>>>> On my 2 core head of yesterday I tried both SCHED_ULE AND >>>>>> 4BSD.. and got the same results ;-0 >>>>>> >>>>>> I will try my 4 core when I get home ;-) >>>>>> >>>>>> R >>>>>> On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: >>>>>> >>>>>>> On Thu, 28 Jan 2010 10:30:37 -0800 >>>>>>> Randall Stewart wrote: >>>>>>> >>>>>>>> All: >>>>>>>> >>>>>>>> I just found a very strange thing with yesterdays head. >>>>>>>> >>>>>>>> The program >>>>>>>> >>>>>>>> http://www.freebsd.org/~rrs/my_thr.c >>>>>>>> >>>>>>>> I compile it: >>>>>>>> >>>>>>>> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >>>>>>>> >>>>> >>>>> Hi Randal, >>>>> I tried your code on an 8-core machine with a fresh head (i386) >>>>> I have no problems with both 4BSD and ULE scheduler. >>>>> I even upping the value of macro NUM_THREAD to 24 but I didn't notice >>>>> nothing strange. >>>>> >>>>> Have you got a chance to reproduce it on your machines? >>>>> >>>>> -- >>>>> Gianni >>>>> _______________________________________________ >>>>> 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" >>>>> >>>> >>>> I ran it on my dual-core, 8-STABLE/ULE laptop. The very first time I >>>> ran it, I experienced the temporary "seizure". It took several more >>>> runs before I could get it to happen again. >>>> >>> >>> Hi Brandon, >>> which kind of processor your laptop has? AMD or Intel? >>> -- >>> Gianni >>> >> >> CPU: Intel(R) Core(TM)2 Duo CPU =A0 =A0 L7100 =A0@ 1.20GHz (1197.01-MHz = K8-class CPU) >> =A0Origin =3D "GenuineIntel" =A0Id =3D 0x6fb =A0Stepping =3D 11 >> =A0Features=3D0xbfebfbff >> =A0Features2=3D0xe3bd >> =A0AMD Features=3D0x20100800 >> =A0AMD Features2=3D0x1 >> =A0TSC: P-state invariant >> >> -Brandon >> > > Hi, all > I cannot reproduce the issue at least on 8.0-RELEASE. > Can you please update to r203414 and give it a try? > > Thank you. > > -- > Gianni > Just tried it again (a few times) at r203430, with similar results. -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 18:05:09 2010 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 7DF3E1065676; Wed, 3 Feb 2010 18:05:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id E993C8FC15; Wed, 3 Feb 2010 18:05:08 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o13I58b4035056; Wed, 3 Feb 2010 10:05:08 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o13I58xG035055; Wed, 3 Feb 2010 10:05:08 -0800 (PST) (envelope-from david) Date: Wed, 3 Feb 2010 10:05:08 -0800 From: David Wolfskill To: Alexander Motin Message-ID: <20100203180508.GD32250@bunrab.catwhisker.org> References: <20100203144037.GA32250@bunrab.catwhisker.org> <4B69B4F6.1090608@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tEFtbjk+mNEviIIX" Content-Disposition: inline In-Reply-To: <4B69B4F6.1090608@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD-Current Subject: Re: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed 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, 03 Feb 2010 18:05:09 -0000 --tEFtbjk+mNEviIIX Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2010 at 07:40:06PM +0200, Alexander Motin wrote: > David Wolfskill wrote: > > On Wed, Feb 03, 2010 at 06:40:37AM -0800, David Wolfskill wrote: > >> Just updated my build machine from r203376 to r203425, which seeme dto > >> go well, but after I issued "shutdown -p now" (as I leave the machine > >> off when it's not in use), I saw the following on the serial console: > >> > >> Uptime: 1m45s > >> (noperiph:aacp0:0:0:0): Device power down failed > >> (noperiph:aacp0:0:1:0): Device power down failed > >> ... > That was my change r203420. `sysctl kern.cam.power_down=3D0` should > disable new behavior. It can be a bug of aac driver. Is it repeatable > each time at the same place? Well, I just tried it a second time, and the failure mode appears identical, yes. I won't (quite) claim that it's "repeatable=A0each time at the same place" yet, but the evidence certainly tends toward that direction. > > Tried the same experiment with the laptop; didn't get the above failure, > > but am seeing many (as in "hundreds") of > >=20 > > atapi_poll called! > > atapi_poll called! >=20 > This looks like atapicam misfeature. I'll look on it. > ... Cool; thanks! I'm quite willing to test patches &c. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --tEFtbjk+mNEviIIX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktputQACgkQmprOCmdXAD3SOACeJSR6rJ8WJSvFS2s7NZNLGifw kwcAnjzZTDiGihRlKH9J/P20RgmSS/KB =YARQ -----END PGP SIGNATURE----- --tEFtbjk+mNEviIIX-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 20:06:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 857F41065676; Wed, 3 Feb 2010 20:06:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Marc UBM Bocklet Date: Wed, 3 Feb 2010 15:06:38 -0500 User-Agent: KMail/1.6.2 References: <20100201184446.2325c04e.ubm.freebsd@gmail.com> <201002031234.16137.jkim@FreeBSD.org> <20100203191126.356d8132.ubm@u-boot-man.de> In-Reply-To: <20100203191126.356d8132.ubm@u-boot-man.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_RddaLYHKoXxkOxF" Message-Id: <201002031506.41531.jkim@FreeBSD.org> Cc: Marc UBM Bocklet , freebsd-current@freebsd.org Subject: Re: vidcontrol / resolution problems with latest current 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, 03 Feb 2010 20:06:48 -0000 --Boundary-00=_RddaLYHKoXxkOxF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 03 February 2010 01:11 pm, Marc UBM Bocklet wrote: > On Wed, 3 Feb 2010 12:33:58 -0500 > > Jung-uk Kim wrote: > > On Wednesday 03 February 2010 08:38 am, Marc UBM Bocklet wrote: > > > On Tue, 2 Feb 2010 16:43:07 -0500 > > > > > > Jung-uk Kim wrote: > > > > > > > Can anyone point me to a solution / is more info > > > > > > > required? > > > > > > > > > > > > Hmm... The attached patch should restore the previous > > > > > > behavior. > > > > > > > > > > No change, unfortunately. Anything I can provide to help? > > > > > > > > How about the attached patch, then? > > > > > > Thanks for the quick response! > > > > > > Unfortunately, no change, even with the new patch. Screen stays > > > on and lit up, but I see not text. Starting X blindly still > > > works. > > > > What happens if you blindly display screen-full of text ('dmesg' > > or 'ls -lR /' for example)? Also, can you show me verbose boot > > messages and 'vidcontrol -i mode' output? 'vidcontrol -i > > adapter' output from the mode (VESA_800x600) will be useful as > > well, e.g., 'vidcontrol -i adapter > vesa.txt' and please send me > > the vesa.txt. > > Textfiles & dmesg are attached, blindly typing dmesg or ls -lR / > changes nothing, screen stays lit but blank. I think I got it now. Please try this patch. Thanks, Jung-uk Kim --Boundary-00=_RddaLYHKoXxkOxF Content-Type: text/plain; charset="iso-8859-1"; name="vesa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vesa.diff" --- sys/dev/fb/vesa.c 2010-02-02 16:34:30.000000000 -0500 +++ sys/dev/fb/vesa.c 2010-02-03 15:04:35.000000000 -0500 @@ -1293,7 +1293,7 @@ } else { vesa_adp->va_buffer = 0; vesa_adp->va_buffer_size = info.vi_buffer_size; - vesa_adp->va_window = BIOS_PADDRTOVADDR(info.vi_window); + vesa_adp->va_window = (vm_offset_t)x86bios_offset(info.vi_window); vesa_adp->va_window_size = info.vi_window_size; vesa_adp->va_window_gran = info.vi_window_gran; } --Boundary-00=_RddaLYHKoXxkOxF-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 21:38:09 2010 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 2171C106566C; Wed, 3 Feb 2010 21:38:09 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id C851A8FC0A; Wed, 3 Feb 2010 21:38:08 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 655B41C153F3; Wed, 3 Feb 2010 22:38:07 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.6.166]) by mail.m-online.net (Postfix) with ESMTP id 54CAE90228; Wed, 3 Feb 2010 22:38:07 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.6.166]) (amavisd-new, port 10024) with ESMTP id klgJm0GSfgIE; Wed, 3 Feb 2010 22:38:06 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-101-89.dynamic.mnet-online.de [93.104.101.89]) by mail.mnet-online.de (Postfix) with ESMTP; Wed, 3 Feb 2010 22:38:06 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id E036E2C2E9; Wed, 3 Feb 2010 22:38:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id CE4D52C2E6; Wed, 3 Feb 2010 22:38:05 +0100 (CET) Date: Wed, 3 Feb 2010 22:38:05 +0100 (CET) From: Michael Reifenberger To: Alexander Motin In-Reply-To: <4B69B707.2020504@FreeBSD.org> Message-ID: References: <1264818191.00213314.1264807803@10.7.7.3> <1264861382.00213426.1264851002@10.7.7.3> <1264864983.00213434.1264852204@10.7.7.3> <1265026986.00214174.1265016606@10.7.7.3> <1265030583.00214182.1265019602@10.7.7.3> <1265037797.00214273.1265026205@10.7.7.3> <1265037810.00214278.1265026802@10.7.7.3> <1265048584.00214331.1265035802@10.7.7.3> <4B69B707.2020504@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current Subject: Re: Odd ada(4) failures when trying using USB scanner 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, 03 Feb 2010 21:38:09 -0000 On Wed, 3 Feb 2010, Alexander Motin wrote: ... >>> I would say that scanner application tries to probe all CAM devices, >>> looking for scanner. While doing it, it uses SCSI/ATAPI commands with >>> odd-sized transfer sizes. It causes errors from ata(4) and triggers bug >>> in IXP700 AHCI controller. Odd-sized requests are generally not >>> supported by ATA/SATA. Second problem is in work now. >> >> Could odd-sized commands be prohibited/ignored by the driver then? > > I've recently committed patch to 9-CURRENT, that should block sending of > SCSI commands to non-ATAPI devices. That should fix your problem. I'm currently running HEAD @ r203376 and it fixed my problem already. Thanks for your work! Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 21:40:28 2010 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 CD86A106566C for ; Wed, 3 Feb 2010 21:40:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5266C8FC0C for ; Wed, 3 Feb 2010 21:40:28 +0000 (UTC) Received: by fxm25 with SMTP id 25so468956fxm.14 for ; Wed, 03 Feb 2010 13:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=La1Q8AXIbOL+2s+0Jans1/+yMxAwUYXH3NwVAQwmkfA=; b=e73qp1Ssko4CDY1yX/iYp51rsjYfdhXBABTUnBchbXqLzcs46Lefr+Err4rh9NYq+v Z+N47B6M1Au64tRuYEyqx8hak+Zyy7zJ9QDuxDJ4l+ZaRSNf4rmQa8tldc3ROsYiAjvG 1S0NJIaoF3wP6BvhAe13LYTSVorPq8YxMD4mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=BBbYMNHuQNP84YYtFddWxRKEzOER/+xgc3vIRT8IZfB6uGEHJyQ762Kk3ywS587hja moN4W95FkG1JtJ/sTfqSJgc88QZTtSJNiIg/q7P9bkjBpINzVn9O0y5/cTGQy4DornMT 70Epo0l+UfJZxpUkSwtY64RYeR64WrnLB7Ox8= Received: by 10.223.16.216 with SMTP id p24mr145955faa.66.1265233227084; Wed, 03 Feb 2010 13:40:27 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm3432771fxm.10.2010.02.03.13.40.26 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 13:40:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4B69ED46.7030400@FreeBSD.org> Date: Wed, 03 Feb 2010 23:40:22 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Wolfskill References: <20100203144037.GA32250@bunrab.catwhisker.org> <4B69B4F6.1090608@FreeBSD.org> <20100203180508.GD32250@bunrab.catwhisker.org> In-Reply-To: <20100203180508.GD32250@bunrab.catwhisker.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040202040601010206060600" Cc: FreeBSD-Current Subject: Re: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed 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, 03 Feb 2010 21:40:29 -0000 This is a multi-part message in MIME format. --------------040202040601010206060600 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit David Wolfskill wrote: > On Wed, Feb 03, 2010 at 07:40:06PM +0200, Alexander Motin wrote: >> David Wolfskill wrote: >>> On Wed, Feb 03, 2010 at 06:40:37AM -0800, David Wolfskill wrote: >>>> Just updated my build machine from r203376 to r203425, which seeme dto >>>> go well, but after I issued "shutdown -p now" (as I leave the machine >>>> off when it's not in use), I saw the following on the serial console: >>>> >>>> Uptime: 1m45s >>>> (noperiph:aacp0:0:0:0): Device power down failed >>>> (noperiph:aacp0:0:1:0): Device power down failed >>>> ... >> That was my change r203420. `sysctl kern.cam.power_down=0` should >> disable new behavior. It can be a bug of aac driver. Is it repeatable >> each time at the same place? > > Well, I just tried it a second time, and the failure mode appears > identical, yes. I won't (quite) claim that it's "repeatable each time > at the same place" yet, but the evidence certainly tends toward that > direction. > >>> Tried the same experiment with the laptop; didn't get the above failure, >>> but am seeing many (as in "hundreds") of >>> >>> atapi_poll called! >>> atapi_poll called! >> This looks like atapicam misfeature. I'll look on it. >> ... > > Cool; thanks! > > I'm quite willing to test patches &c. Attached patch implements poll method for atapicam. It is probably not good from the locking point of view. But it is better then nothing and seems enough for now, especially because atapicam is going to die. As there can be other controllers with poll problems, I've disabled this feature by default for now. -- Alexander Motin --------------040202040601010206060600 Content-Type: text/plain; name="atapicam.poll.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="atapicam.poll.patch" diff -ruNp ata.prev/atapi-cam.c ata/atapi-cam.c --- ata.prev/atapi-cam.c 2010-02-03 23:30:12.000000000 +0200 +++ ata/atapi-cam.c 2010-02-03 23:29:37.000000000 +0200 @@ -682,8 +682,12 @@ action_invalid: static void atapi_poll(struct cam_sim *sim) { - /* do nothing - we do not actually service any interrupts */ - printf("atapi_poll called!\n"); + struct atapi_xpt_softc *softc = + (struct atapi_xpt_softc*)cam_sim_softc(sim); + + mtx_unlock(&softc->state_lock); + ata_interrupt(softc->ata_ch); + mtx_lock(&softc->state_lock); } static void --------------040202040601010206060600-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 22:24:09 2010 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 492D1106566B for ; Wed, 3 Feb 2010 22:24:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id C60EF8FC0A for ; Wed, 3 Feb 2010 22:24:08 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so50035fga.13 for ; Wed, 03 Feb 2010 14:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=wksatHkNu5bczv2yr+cPs3nod9ec0AE5FrOE4vy8QGw=; b=TPtAPPU0C3rhUdmLL6TqheGVvuWvpCcLAKHiQSkmcejvZUSkisdzbZQ9QUDM4rVboF PT7RW6MvEVaSCSKPgSOOfiv6RQn9JGbzTr0HwRoQHE2Wv/oMnLjGuWJQBlksGG1FWppt lxjtJSJmPh/fbyL2rtmGHyBGD+PpQ5/TQ6eGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=T25SffKEVrRtpdMBkLG5hB3bgc6p3eXyDB39tj78msuJf211BUxYlRixtj/AK2oA5W PSvaQ07tB+KkRZdRbnHPjGVRso1rmbVWkln+6xIjvbs6tR8Txu7w9zyaL0xpWbkSokJj fqePetcJrsUcToGxnYcqNHetgFzDwKNBx1uWM= Received: by 10.87.47.3 with SMTP id z3mr717190fgj.70.1265235846768; Wed, 03 Feb 2010 14:24:06 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm3456474fxm.6.2010.02.03.14.24.05 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 14:24:05 -0800 (PST) Sender: Alexander Motin Message-ID: <4B69F782.5050108@FreeBSD.org> Date: Thu, 04 Feb 2010 00:24:02 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Wed, 03 Feb 2010 22:24:09 -0000 Marcel Moolenaar wrote: > On Feb 2, 2010, at 3:39 PM, Alexander Motin wrote: >> Marcel Moolenaar wrote: >>> On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: >>>> Whether it is related or not, both issues definitely should be fixed. >>>> Could you give me an access to debug that system, or it is in use? >>> Unfortunately, I can't give you access to this machine. >> What's about full verbose dmesg up to the first few errors? > > *snip* > Tue Feb 2 16:16:57 PST 2010 > > FreeBSD/ia64 (hob.lan.xcllnt.net) (ttyu0) > > login: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x07 Depth 120 > xpt_release_devq(0): requested 1 > present 0 > xpt_release_devq(0): requested 1 > present 0 > xpt_release_devq(0): requested 1 > present 0 > *ad nauseam* > > Actually, it's not ad nauseam. Every queue full event is > followed by 256 xpt_release_devq(0) lines. Looks related > to me... Indeed related. This driver seems handles queue full status by itself, instead of returning respective request status to CAM. I have too small information now to understand why number of openings is not changing, as you said. But errors you've got look reasonable. I have doubts that driver frozen all 256 luns before adjusting openings, so releasing them by this call causes such errors. I expect such patch should fix the problem: --- mpt_cam.c.prev 2009-11-01 13:16:39.000000000 +0200 +++ mpt_cam.c 2010-02-04 00:16:31.000000000 +0200 @@ -2558,6 +2558,7 @@ mpt_cam_event(struct mpt_softc *mpt, req } xpt_setup_ccb(&crs.ccb_h, tmppath, 5); crs.ccb_h.func_code = XPT_REL_SIMQ; + crs.ccb_h.flags = CAM_DEV_QFREEZE; crs.release_flags = RELSIM_ADJUST_OPENINGS; crs.openings = pqf->CurrentDepth - 1; xpt_action((union ccb *)&crs); Do you receive message like "tagged openings now %d" in verbose log? It should be there if queue size was adjusted. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 23:40:01 2010 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 CB4F11065679 for ; Wed, 3 Feb 2010 23:40:01 +0000 (UTC) (envelope-from vincepoy@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 772468FC08 for ; Wed, 3 Feb 2010 23:40:01 +0000 (UTC) Received: by yxe2 with SMTP id 2so1613363yxe.7 for ; Wed, 03 Feb 2010 15:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xplMmOSP4I6jpgd9c4tP2CnRPmAtiyWsVF9CI6CNq2w=; b=ELu7C0Luqb2SeeSf1ABkSutSuavGIpswNvcrnIqQKRFIStsHhm69a56imNJz0wGQPl K8lfQh2OUCwW8zFkjQHIM8LgGz/tHi+7v7h9PQFMi5NwSr1SJ6H9a2hlFYozHwxS1x0k LhKcoH5Tldz5Av4rewAwH5kCGS7MA5B7jsnX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A2Py/MjCVexmQQ7/05D4SjQcmY98GQEo0KJPmKJKv4SciNecPy2ZHB2LApnV1PXjFF FjO4Ri3/FmDlPj98/bI9Bw89XuGCBOrB/tuYUVC/vOnZlcNWJ1sy8o8eJczgOJ8YeOsS UZtB+hOPEFvbGQnKlUH7VBAMJ36y/8mijJaZE= MIME-Version: 1.0 Received: by 10.150.179.20 with SMTP id b20mr869335ybf.181.1265240400495; Wed, 03 Feb 2010 15:40:00 -0800 (PST) In-Reply-To: <20100202175505.5d0d5d3e@ernst.jennejohn.org> References: <429af92e1002011500q59b9ae09g908154ae63881ff5@mail.gmail.com> <20100201233216.GL77705@hoeg.nl> <20100202175505.5d0d5d3e@ernst.jennejohn.org> Date: Wed, 3 Feb 2010 15:40:00 -0800 Message-ID: <429af92e1002031540u46a370c0gf633b2cf19e17bf7@mail.gmail.com> From: Vincent Poy To: gary.jennejohn@freenet.de Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . 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, 03 Feb 2010 23:40:01 -0000 On Tue, Feb 2, 2010 at 8:55 AM, Gary Jennejohn wrote: > On Tue, 2 Feb 2010 00:32:16 +0100 > Ed Schouten wrote: > > > * Vincent Poy wrote: > > > 3) I noticed that it seems the system in the w, who, finger, last, > > > lastlogin output is not recognizing additional sessions of the same > user on > > > a new tty if they are already logged in such as this example. I am > already > > > logged in as vince on ptys/0 so I login again as vince on ptys/1: > > > > > > > This is very odd. Could you try debugging this a bit more? In order to > > ease debugging, I extended the getent command. You should be able to use > > the following commands: > > > > - getent utmpx active > > Get list of active sessions (`utmp') > > - getent utmpx log > > Get list of log entries (`wtmp') > > - getent utmpx lastlogin > > Get list of last login entries (`lastlog') > > > > When you log in, it should add a "user process" entry to the active > > sessions database, append the same entry to the log and overwrite the > > lastlogin entry for the corresponding user. > > > > An advantage of these commands is that they just perform a raw dump of > > the data on screen, instead of having many forms of unwanted processing > > on top. > > > > What terminal emulator are you using? I'm using mrxvt-devel and I _do_ > see every mrxvt which I have running with w, who, finger and last. > > --- > Gary Jennejohn I'm using telnet/ssh client on unix boxes including the same machine in question, doing a cvsup on February 1, 2010 and rebuilding world fixed the problem. Cheers, Vince Vincent Poy, Ph.D. - Astrophysics From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 23:43:37 2010 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 8F42F106566C; Wed, 3 Feb 2010 23:43:37 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id E7E7F8FC13; Wed, 3 Feb 2010 23:43:36 +0000 (UTC) Received: by fxm26 with SMTP id 26so282023fxm.13 for ; Wed, 03 Feb 2010 15:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ONXzQUyVigQUAxxj1P+nHWFA+xST/O6ptwshE8h5xuI=; b=CmViG9JrQpq7hHVzUyiQRK7jPTb1sAILjq+uFesa7OzA/15O8ylxREMUBljJTAmy6H hDoPFYOLZMAdpf1m8GfKeAFUHRRdZBrAH2NOg/po0P7oldZhLFIh9OGpVgLsMSkOZVGZ GbXV/ELv5KmXqcBNICiw6sMLvibO3ftZFVyXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=owecXU911Pzke+9aPQtfw8PFZxcmzmHxB7UcYdijENG9LjLwuafwOjSBUZMmOyEKrT nFMqO/Y1JZ0qKDA1kGffSzYR+VyJEYTpU4F6xYIgpsRgm8NuQztdWAJOjhoPBYXkKrlS A/vHwej8T1J4Gm9uF/A6ixirNNU0/7My4QSfA= MIME-Version: 1.0 Received: by 10.223.4.25 with SMTP id 25mr277264fap.38.1265240616005; Wed, 03 Feb 2010 15:43:36 -0800 (PST) In-Reply-To: <179b97fb1002031002g617aee35uec79e3367b2ff7a5@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> <179b97fb1002011424p4a799ff6t8f6b39e6f4b66828@mail.gmail.com> <4e6cba831002022320u2bd5f325m6564556a1abcf4c5@mail.gmail.com> <179b97fb1002031002g617aee35uec79e3367b2ff7a5@mail.gmail.com> Date: Thu, 4 Feb 2010 00:43:35 +0100 Message-ID: <4e6cba831002031543r391ba4c7m620868fe9cc044a8@mail.gmail.com> From: Giovanni Trematerra To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. 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, 03 Feb 2010 23:43:37 -0000 > Just tried it again (a few times) at r203430, with similar results. Hi Brandon, did you update -STABLE? I meant -CURRENT! Anyway, if you are updating -STABLE, please try the patch below. I don't know if it applies on -STABLE, let me know. Thanks for your time. -- Gianni --- head/sys/kern/kern_umtx.c 2010/01/10 09:31:57 201991 +++ head/sys/kern/kern_umtx.c 2010/02/03 03:56:32 203414 @@ -2526,6 +2526,12 @@ umtxq_busy(&uq->uq_key); umtxq_unlock(&uq->uq_key); + /* + * re-read the state, in case it changed between the try-lock above + * and the check below + */ + state = fuword32(__DEVOLATILE(int32_t *, &rwlock->rw_state)); + /* set read contention bit */ while ((state & wrflags) && !(state & URWLOCK_READ_WAITERS)) { oldstate = casuword32(&rwlock->rw_state, state, state | URWLOCK_READ_WAITERS); @@ -2658,6 +2664,12 @@ umtxq_busy(&uq->uq_key); umtxq_unlock(&uq->uq_key); + /* + * re-read the state, in case it changed between the try-lock above + * and the check below + */ + state = fuword32(__DEVOLATILE(int32_t *, &rwlock->rw_state)); + while (((state & URWLOCK_WRITE_OWNER) || URWLOCK_READER_COUNT(state) != 0) && (state & URWLOCK_WRITE_WAITERS) == 0) { oldstate = casuword32(&rwlock->rw_state, state, state | URWLOCK_WRITE_WAITERS); From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 01:04:29 2010 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 910C9106566C for ; Thu, 4 Feb 2010 01:04:29 +0000 (UTC) (envelope-from vincepoy@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 109E58FC14 for ; Thu, 4 Feb 2010 01:04:28 +0000 (UTC) Received: by yxe2 with SMTP id 2so1667896yxe.7 for ; Wed, 03 Feb 2010 17:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EKkhu1w9lzaIJlmApNxXpStuK8vjPwSuM/kqBq+r4Mw=; b=T2ySNtLE8D6+2Bq0Hs6OlavqRnXjbDJK+M8zC1te3UePxcerrg+TOhBW5d50jANXfp KTuATs+3TwUDoGH28zFZs/DlVsmY26kNI2wcO7l4p049w0twDBds9PHvgc+b+VKlA7E5 uH4ZzCKHI3yft6VvVYwKVBzwiC4P4goLWSuXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JYZoeDTLxtqjyeL1ugO4EFmoshn81IfSUKseoPKLHdaR3F4x2GJy7mG3sVTFFcU2oY ME+JHumUPH9a8FBCkFNuuA+JlYd7Pq5sv+869rDQ8MpQ19M7koWFJNWXKLcNbk+NNT7m a6fg83sxa0LfDDLyu/kbX1Xhe2yuOzuHQdd5w= MIME-Version: 1.0 Received: by 10.150.179.20 with SMTP id b20mr957912ybf.181.1265245467137; Wed, 03 Feb 2010 17:04:27 -0800 (PST) In-Reply-To: <20100201233216.GL77705@hoeg.nl> References: <429af92e1002011500q59b9ae09g908154ae63881ff5@mail.gmail.com> <20100201233216.GL77705@hoeg.nl> Date: Wed, 3 Feb 2010 17:04:27 -0800 Message-ID: <429af92e1002031704s2145570bo708439e9c87f6c80@mail.gmail.com> From: Vincent Poy To: Ed Schouten , cy@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . 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, 04 Feb 2010 01:04:29 -0000 On Mon, Feb 1, 2010 at 3:32 PM, Ed Schouten wrote: Hello Ed: > Hello Vincent, > > * Vincent Poy wrote: > > I just updated to a January 31, 2010 -CURRENT from a -CURRENT prior to > the > > above change and have a few questions and issues: > > > > 1) What's the correct way to use wtmpcvt(1) as the usage is wtmpcvt > oldfile > > newfile > > out of the utmp, wtmp, lastlog, the utmp is not important as that's > > basically the current logins. wtmp is not important either as that's > just > > the recent monthly logins. What is the correct procedure to convert > lastlog > > as that is basically the database that showed when the last time a user > > logged on to the system so that when using lastlogin or finger, it will > > showed when the person last logged in? > > > > I've tried wtmpcvt /var/log/lastlog /var/log/utx.lastlogin after backing > up > > /var/log/utx.lastlogin but when I ran lastlogin, it was all blank. > > Right now there is no way to convert lastlog files. The point is that > unlike you mentioned, the wtmp is actually the only important log file. > All information could in theory be derived from it. You could convert > wtmp files and use last -f to scroll through history to figure out when > someone logged in. > The problem with figuring out when someone last logged in is that newsyslog with the default newsyslog.conf would rotate the wtmp files once a month so that there would be one wtmp followed by wtmp.0, wtmp.1, wtmp.2, wtmp.3 so it will only hold the last months worth of data so if the person logs in anytime more than 5 months, they won't be in the wtmp. > From an administrative point of view, you just want to be able to > inspect log files in case it turns out a couple of months earlier > something bad happened with your system (getting hacked, etc). lastlog > is a nice feature, but it should just be considered being a bonus. > The thing with something bad happening with the system is usually looking at data that far back will not really help since if it took a admin that long to figure it out, then there is a bigger issue at hand because the system probably is heavily compromised already as when we had hacks, usually we have to get to it in real-time or atleast within a few hours or otherwise the system will really be history. I just meant that traditionally, when you finger a username, regardless if they are still in the wtmp/wtmp.* or not, it will always showed when they last logged in even though it might be a long time ago. last will only show whatever is in the wtmp and in this case, anything in the current month. lastlogin probably would show their last logged in timestamp. > Using wtmpcvt(1) on non-wtmp files will indeed generate unreadable data > files. > > > 2) I noticed that for last for ftp sessions, it will not show it as a ftp > > session like how the previous utmp did even though w now shows the > session > > when it's still connected, not sure if this is really a bad thing unless > ftp > > isn't the only way to not use a tty. It seems finger now will report the > > last login session which previously was only for tty sessions. > > > > > > I have been thinking about possibly extending the utmpx interface to > include an application name string for login entries, like "sshd" or > "ftpd". > Actually, from looking at the older last output using a example at http://markmail.org/message/gbjgkwrwtt7s3spf: It is in the format of: user1 ftp 10.12.21.156 Fri Aug 20 13:17 - 13:17 (00:00) user1 ttyp0 10.12.21.156 Fri Aug 20 13:16 - 13:17 (00:00) while the new format is: user1 10.12.21.156 Wed Feb 3 14:22 - 14:22 (00:00) user1 pts/12 10.12.21.156 Tue Feb 2 20:47 - 20:48 (00:00) So it seems like any connection that user a pty/vty was always listed with the tty's name while ftp was only for ftp sessions. sshd would be listed as the former. Speaking about ftp, anonymous ftp to be exact, it doesn't show up in the last/lastlogin. In utmp, it looked like this: ftp ftp 10.12.21.156 Wed Feb 3 16:18 - 16:18 (00:00) > > 3) I noticed that it seems the system in the w, who, finger, last, > > lastlogin output is not recognizing additional sessions of the same user > on > > a new tty if they are already logged in such as this example. I am > already > > logged in as vince on ptys/0 so I login again as vince on ptys/1: > > > > This is very odd. Could you try debugging this a bit more? In order to > ease debugging, I extended the getent command. You should be able to use > the following commands: > > - getent utmpx active > Get list of active sessions (`utmp') > - getent utmpx log > Get list of log entries (`wtmp') > - getent utmpx lastlogin > Get list of last login entries (`lastlog') > > When you log in, it should add a "user process" entry to the active > sessions database, append the same entry to the log and overwrite the > lastlogin entry for the corresponding user. > > An advantage of these commands is that they just perform a raw dump of > the data on screen, instead of having many forms of unwanted processing > on top. > I actually fixed the problem after I sup the latest -current of February 1, 2010 and then build/install world with a new kernel. > > lastlogin shows only the last ftp session but not acknowledging that the > > current ptys/1 session as the ptys/0 session is still active. > > vince@bigbang [2:44pm][~] >> lastlogin > > vince solar Mon Feb 1 14:20:03 2010 > > No, but that's not what lastlogin is supposed to do. lastlogin will only > print information about the last login, which means it will only list > the FTP login. > The only thing was that I did a telnet session after the ftp login and that one didn't show up but the problem has been solved now after I sup the latest -current of February 1, 2010 and then build/install world with a new kernel. > > > > > > 4) the misc/screen port appears to be broken: > > > > Are you sure your ports tree is up-to-date? It was at that time but when I resup the ports tree again and noticed that cy put in some patches so it compiles and installs with no problem except that the tty's that screen creates are not showing up in w, who, finger, last, lastlogin as basically I'm logged into pts/0 and run screen which starts pts/1 but that one doesn't show up: vince@bigbang [4:53pm][~] >> w 4:54PM up 2:43, 1 user, load averages: 0.01, 0.09, 0.07 USER TTY FROM LOGIN@ IDLE WHAT vince pts/0 solar.dnalogic.net 2:17PM - screen vince@bigbang [4:54pm][~] >> ps -agx 2174 0 Is 0:00.27 -tcsh (tcsh) 6986 0 S+ 0:00.03 screen 6989 1 Rs 0:00.08 /bin/tcsh 7023 1 R+ 0:00.00 ps -agx Using your debugging instructions above: vince@bigbang [4:55pm][~] >> getent utmpx active [1265235448.137844 -- Wed Feb 3 14:17:28 2010] user process: id="7074732f30000000" pid="2173" user="vince" line="pts/0" host=" solar.dnalogic.net" [1265244775.030533 -- Wed Feb 3 16:52:55 2010] dead process: id="7074732f31000000" pid="2214" [1265243360.515028 -- Wed Feb 3 16:29:20 2010] dead process: id="6363336674706400" pid="3267" vince@bigbang [4:56pm][~] >> getent utmpx log [1265235448.137844 -- Wed Feb 3 14:17:28 2010] user process: id="7074732f30000000" pid="2173" user="vince" line="pts/0" host=" solar.dnalogic.net" [1265244775.030533 -- Wed Feb 3 16:52:55 2010] dead process: id="7074732f31000000" pid="2214" vince@bigbang [DING!][~] >> getent utmpx lastlogin [1265235448.137844 -- Wed Feb 3 14:17:28 2010] user process: id="7074732f30000000" pid="2173" user="vince" line="pts/0" host=" solar.dnalogic.net" [1265242798.149182 -- Wed Feb 3 16:19:58 2010] user process: id="6363336674706400" pid="3267" user="vince" line="" host="localhost" [1265234174.120127 -- Wed Feb 3 13:56:14 2010] user process: id="016b68bfc68e7691" pid="2184" user="root" line="ttyv0" host="" Cheers, Vince Vincent Poy, Ph.D. - Astrophysics From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 01:16:15 2010 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 82910106566C for ; Thu, 4 Feb 2010 01:16:15 +0000 (UTC) (envelope-from vincepoy@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 33FC98FC17 for ; Thu, 4 Feb 2010 01:16:14 +0000 (UTC) Received: by yxe2 with SMTP id 2so1675312yxe.7 for ; Wed, 03 Feb 2010 17:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=nzZYUhVj1JNtNS4o71GJZZ4s3tRqw/rneSxHXSqUeQ0=; b=XF/B11Yz+8nGImP8yLdraAJa40tDtwWwn7yihPI+zseWmSZtJMuKA4D4aTMeg6rGVK vYYXZdY2mfOZaeDFIWViswTwT7lRd8V8tf8JvMmWrG4crM7yc671ZMtQ1LW26Fg1U5As VRmDfmyVgtk2rGNzQsCeECITUedXGPhR3CbIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ptPbhLIYZJA71TyuI49U/5i36ESGbJIY+v8hWCuwNSGzHTgHU7X5RcVBI9e3ywRUGt 0msQSUn+zmGnn4rxe4rXb6M8d0fHOoxvOqAQ+wVCIe0ig9jlA0JQVc+ChJIq8choxvas ewEAyPMWuWKqv4+Xid4XkhVgzm7ii9rKYGNcY= MIME-Version: 1.0 Received: by 10.150.127.27 with SMTP id z27mr998402ybc.104.1265246173629; Wed, 03 Feb 2010 17:16:13 -0800 (PST) Date: Wed, 3 Feb 2010 17:16:13 -0800 Message-ID: <429af92e1002031716j3fcdedc7j7d46d05cfb76798e@mail.gmail.com> From: Vincent Poy To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: fsck panic's -CURRENT gmirror and kernel 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, 04 Feb 2010 01:16:15 -0000 Greetings everyone: With a February 1, 2010 -CURRENT, I experienced a kernel panic and running a gmirror system so when I rebooted, it said /usr was not properly mounted and gmirror said it will mount /usr pending fsck so it runs the fsck and after a few minutes, gmirror complains and the kernel panics so I had to reboot from the db> prompt. It seems the only way to fix it is to boot in single user mode, fsck /dev/mirror/gm0s1a and fsck /dev/mirror/gm0s1d so that fsck fixes the problems and marks it clean before rebooting in multi-user mode. Cheers, Vince Vincent Poy, Ph.D. - Astrophysics From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 01:43:25 2010 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 5054E1065672; Thu, 4 Feb 2010 01:43:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 35E518FC15; Thu, 4 Feb 2010 01:43:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXA0085ONGCS620@asmtp024.mac.com>; Wed, 03 Feb 2010 17:43:24 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002030217 From: Marcel Moolenaar In-reply-to: <4B69F782.5050108@FreeBSD.org> Date: Wed, 03 Feb 2010 17:43:24 -0800 Message-id: <800D6F19-6286-4ECB-84D8-F9E37F529552@mac.com> References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> <4B69F782.5050108@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Thu, 04 Feb 2010 01:43:25 -0000 On Feb 3, 2010, at 2:24 PM, Alexander Motin wrote: > Do you receive message like "tagged openings now %d" in verbose log? It > should be there if queue size was adjusted. No, that's the problem and it has always been the problem: the queue never gets adjusted, because when the "adjust openings" request is sent up with, say, 120 openings, there are already 121 or more requests queued. This prevents the queue from being adjusted (XPT fails, doesn't propagate an error down but expects any interested drivers to try again in case of a failure)... I'll try the patch, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 03:10:25 2010 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 365661065676; Thu, 4 Feb 2010 03:10:25 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id F03538FC1A; Thu, 4 Feb 2010 03:10:24 +0000 (UTC) Received: by pzk14 with SMTP id 14so117347pzk.3 for ; Wed, 03 Feb 2010 19:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m2pRwukvqbtjXfAU0FDJLQ9sf95hSXWEtDKTZvNKleE=; b=aSqPLabdlfoDoxLCgU8NcBWiXrBXxpfh8Znx0NeKna8wBEqcITopgmrpm+OKGCC0qh XR5Yym/3u4nEe6Q/oA2zGlzOCCVG6JELj0QjXA/3NG33CcVTgMrXiYeIadBdm5mRRjYY Va9JWm7HB9U4Mr3y1FIbLn25dutqDyB6GBS5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lk6FdypsS81uj8cF7EYf8peJcXPjDkxTIbdiPGPZ1Y7PYz0sr8ajZ3e41pJXCkWds4 AFZdTaL5coz234t8PIx/AdtMFsHzvp8kWOwZ4+kdIV3NIxlZvVHrmLUmXpNkyu8lTItn X0ePux257TKySJ+LZ5HzW7q33ahWGNCFJam0w= MIME-Version: 1.0 Received: by 10.142.66.6 with SMTP id o6mr324929wfa.226.1265253024512; Wed, 03 Feb 2010 19:10:24 -0800 (PST) In-Reply-To: <4e6cba831002031543r391ba4c7m620868fe9cc044a8@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> <4e6cba831002011404h1b6b893cj2390bf0a7560a7f2@mail.gmail.com> <179b97fb1002011424p4a799ff6t8f6b39e6f4b66828@mail.gmail.com> <4e6cba831002022320u2bd5f325m6564556a1abcf4c5@mail.gmail.com> <179b97fb1002031002g617aee35uec79e3367b2ff7a5@mail.gmail.com> <4e6cba831002031543r391ba4c7m620868fe9cc044a8@mail.gmail.com> Date: Thu, 4 Feb 2010 03:10:24 +0000 Message-ID: <179b97fb1002031910q5889eb7fp3600059da191b3d3@mail.gmail.com> From: Brandon Gooch To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. 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, 04 Feb 2010 03:10:25 -0000 On Wed, Feb 3, 2010 at 11:43 PM, Giovanni Trematerra wrote: >> Just tried it again (a few times) at r203430, with similar results. > > Hi Brandon, > did you update -STABLE? I meant -CURRENT! > Anyway, if you are updating -STABLE, please try the patch below. I > don't know if it applies on -STABLE, let me know. > > Thanks for your time. > > -- > Gianni > > --- head/sys/kern/kern_umtx.c =A0 2010/01/10 09:31:57 =A0 =A0 201991 > +++ head/sys/kern/kern_umtx.c =A0 2010/02/03 03:56:32 =A0 =A0 203414 > @@ -2526,6 +2526,12 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0umtxq_busy(&uq->uq_key); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0umtxq_unlock(&uq->uq_key); > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* re-read the state, in case it changed = between the try-lock above > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* and the check below > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D fuword32(__DEVOLATILE(int32_t *, = &rwlock->rw_state)); > + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* set read contention bit */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while ((state & wrflags) && !(state & URWL= OCK_READ_WAITERS)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oldstate =3D casuword32(&r= wlock->rw_state, state, state | > URWLOCK_READ_WAITERS); > @@ -2658,6 +2664,12 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0umtxq_busy(&uq->uq_key); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0umtxq_unlock(&uq->uq_key); > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* re-read the state, in case it changed = between the try-lock above > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* and the check below > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 state =3D fuword32(__DEVOLATILE(int32_t *, = &rwlock->rw_state)); > + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (((state & URWLOCK_WRITE_OWNER) || U= RWLOCK_READER_COUNT(state) !=3D 0) && > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (state & URWLOCK_WRITE_WAITER= S) =3D=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oldstate =3D casuword32(&r= wlock->rw_state, state, state | > URWLOCK_WRITE_WAITERS); > I rebuilt the kernel (and libthr for safe measure), recompiled my_thr.c, and reran it. It still seems to freak X out (noticeably Firefox) and the machine, even after 'my_thr' completes, just acts very strange. It's as if something never completely finishes its business -- I don't know exactly what I'm talking about though :) Am I testing this right? Am I rebuilding everything I should be? -Brandon From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 04:00:39 2010 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 27BA2106566C; Thu, 4 Feb 2010 04:00:39 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECD18FC0C; Thu, 4 Feb 2010 04:00:38 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXA00BMGTT2I660@asmtp024.mac.com>; Wed, 03 Feb 2010 20:00:38 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002030248 From: Marcel Moolenaar In-reply-to: <4B69F782.5050108@FreeBSD.org> Date: Wed, 03 Feb 2010 20:00:38 -0800 Message-id: <12043867-D294-4201-82CC-A31A7D06C83D@mac.com> References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> <4B69F782.5050108@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Thu, 04 Feb 2010 04:00:39 -0000 On Feb 3, 2010, at 2:24 PM, Alexander Motin wrote: > > --- mpt_cam.c.prev 2009-11-01 13:16:39.000000000 +0200 > +++ mpt_cam.c 2010-02-04 00:16:31.000000000 +0200 > @@ -2558,6 +2558,7 @@ mpt_cam_event(struct mpt_softc *mpt, req > } > xpt_setup_ccb(&crs.ccb_h, tmppath, 5); > crs.ccb_h.func_code = XPT_REL_SIMQ; > + crs.ccb_h.flags = CAM_DEV_QFREEZE; > crs.release_flags = RELSIM_ADJUST_OPENINGS; > crs.openings = pqf->CurrentDepth - 1; > xpt_action((union ccb *)&crs); > Works like a charm. Thanks! -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 06:06:15 2010 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 057F6106566B; Thu, 4 Feb 2010 06:06:15 +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 D102D8FC20; Thu, 4 Feb 2010 06:06:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o1466EUe089711; Thu, 4 Feb 2010 01:06:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o1466E0Y089699; Thu, 4 Feb 2010 06:06:14 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 06:06:14 GMT Message-Id: <201002040606.o1466E0Y089699@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, 04 Feb 2010 06:06:15 -0000 TB --- 2010-02-04 05:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 05:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-02-04 05:00:00 - cleaning the object tree TB --- 2010-02-04 05:00:32 - cvsupping the source tree TB --- 2010-02-04 05:00:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-02-04 05:01:10 - building world TB --- 2010-02-04 05:01:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 05:01:10 - TARGET=pc98 TB --- 2010-02-04 05:01:10 - TARGET_ARCH=i386 TB --- 2010-02-04 05:01:10 - TZ=UTC TB --- 2010-02-04 05:01:10 - __MAKE_CONF=/dev/null TB --- 2010-02-04 05:01:10 - cd /src TB --- 2010-02-04 05:01:10 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 05:01:11 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 4 06:00:35 UTC 2010 TB --- 2010-02-04 06:00:35 - generating LINT kernel config TB --- 2010-02-04 06:00:35 - cd /src/sys/pc98/conf TB --- 2010-02-04 06:00:35 - /usr/bin/make -B LINT TB --- 2010-02-04 06:00:35 - building LINT kernel TB --- 2010-02-04 06:00:35 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 06:00:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 06:00:35 - TARGET=pc98 TB --- 2010-02-04 06:00:35 - TARGET_ARCH=i386 TB --- 2010-02-04 06:00:35 - TZ=UTC TB --- 2010-02-04 06:00:35 - __MAKE_CONF=/dev/null TB --- 2010-02-04 06:00:35 - cd /src TB --- 2010-02-04 06:00:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 06:00:35 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 06:06:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 06:06:14 - ERROR: failed to build lint kernel TB --- 2010-02-04 06:06:14 - 2883.18 user 693.66 system 3973.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 06:07:43 2010 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 6DED1106568B; Thu, 4 Feb 2010 06:07:43 +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 480A68FC16; Thu, 4 Feb 2010 06:07:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o1467gGF096934; Thu, 4 Feb 2010 01:07:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o1467gf2096923; Thu, 4 Feb 2010 06:07:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 06:07:42 GMT Message-Id: <201002040607.o1467gf2096923@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/i386 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, 04 Feb 2010 06:07:43 -0000 TB --- 2010-02-04 05:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 05:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-02-04 05:00:00 - cleaning the object tree TB --- 2010-02-04 05:00:33 - cvsupping the source tree TB --- 2010-02-04 05:00:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-02-04 05:01:10 - building world TB --- 2010-02-04 05:01:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 05:01:10 - TARGET=i386 TB --- 2010-02-04 05:01:10 - TARGET_ARCH=i386 TB --- 2010-02-04 05:01:10 - TZ=UTC TB --- 2010-02-04 05:01:10 - __MAKE_CONF=/dev/null TB --- 2010-02-04 05:01:10 - cd /src TB --- 2010-02-04 05:01:10 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 05:01:11 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 4 06:00:50 UTC 2010 TB --- 2010-02-04 06:00:50 - generating LINT kernel config TB --- 2010-02-04 06:00:50 - cd /src/sys/i386/conf TB --- 2010-02-04 06:00:50 - /usr/bin/make -B LINT TB --- 2010-02-04 06:00:50 - building LINT kernel TB --- 2010-02-04 06:00:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 06:00:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 06:00:50 - TARGET=i386 TB --- 2010-02-04 06:00:50 - TARGET_ARCH=i386 TB --- 2010-02-04 06:00:50 - TZ=UTC TB --- 2010-02-04 06:00:50 - __MAKE_CONF=/dev/null TB --- 2010-02-04 06:00:50 - cd /src TB --- 2010-02-04 06:00:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 06:00:50 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 06:07:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 06:07:42 - ERROR: failed to build lint kernel TB --- 2010-02-04 06:07:42 - 2971.76 user 682.22 system 4061.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 06:33:32 2010 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 D2C8A1065695; Thu, 4 Feb 2010 06:33:32 +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 AC5B38FC1A; Thu, 4 Feb 2010 06:33:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o146XWbG022301; Thu, 4 Feb 2010 01:33:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o146XWOA022287; Thu, 4 Feb 2010 06:33:32 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 06:33:32 GMT Message-Id: <201002040633.o146XWOA022287@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 amd64/amd64 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, 04 Feb 2010 06:33:32 -0000 TB --- 2010-02-04 05:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 05:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-02-04 05:00:00 - cleaning the object tree TB --- 2010-02-04 05:00:36 - cvsupping the source tree TB --- 2010-02-04 05:00:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-02-04 05:01:10 - building world TB --- 2010-02-04 05:01:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 05:01:10 - TARGET=amd64 TB --- 2010-02-04 05:01:10 - TARGET_ARCH=amd64 TB --- 2010-02-04 05:01:10 - TZ=UTC TB --- 2010-02-04 05:01:10 - __MAKE_CONF=/dev/null TB --- 2010-02-04 05:01:10 - cd /src TB --- 2010-02-04 05:01:10 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 05:01:11 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Feb 4 06:27:04 UTC 2010 TB --- 2010-02-04 06:27:04 - generating LINT kernel config TB --- 2010-02-04 06:27:04 - cd /src/sys/amd64/conf TB --- 2010-02-04 06:27:04 - /usr/bin/make -B LINT TB --- 2010-02-04 06:27:04 - building LINT kernel TB --- 2010-02-04 06:27:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 06:27:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 06:27:04 - TARGET=amd64 TB --- 2010-02-04 06:27:04 - TARGET_ARCH=amd64 TB --- 2010-02-04 06:27:04 - TZ=UTC TB --- 2010-02-04 06:27:04 - __MAKE_CONF=/dev/null TB --- 2010-02-04 06:27:04 - cd /src TB --- 2010-02-04 06:27:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 06:27:04 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 06:33:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 06:33:32 - ERROR: failed to build lint kernel TB --- 2010-02-04 06:33:32 - 4123.58 user 960.49 system 5611.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 07:13:50 2010 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 7F136106566B; Thu, 4 Feb 2010 07:13:50 +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 3FC1F8FC18; Thu, 4 Feb 2010 07:13:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o147DnSZ030217; Thu, 4 Feb 2010 02:13:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o147DnYq030216; Thu, 4 Feb 2010 07:13:49 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 07:13:49 GMT Message-Id: <201002040713.o147DnYq030216@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 ia64/ia64 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, 04 Feb 2010 07:13:50 -0000 TB --- 2010-02-04 05:49:42 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 05:49:42 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-02-04 05:49:42 - cleaning the object tree TB --- 2010-02-04 05:50:05 - cvsupping the source tree TB --- 2010-02-04 05:50:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-02-04 05:50:53 - building world TB --- 2010-02-04 05:50:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 05:50:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 05:50:53 - TARGET=ia64 TB --- 2010-02-04 05:50:53 - TARGET_ARCH=ia64 TB --- 2010-02-04 05:50:53 - TZ=UTC TB --- 2010-02-04 05:50:53 - __MAKE_CONF=/dev/null TB --- 2010-02-04 05:50:53 - cd /src TB --- 2010-02-04 05:50:53 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 05:50:55 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 4 07:07:00 UTC 2010 TB --- 2010-02-04 07:07:00 - generating LINT kernel config TB --- 2010-02-04 07:07:00 - cd /src/sys/ia64/conf TB --- 2010-02-04 07:07:00 - /usr/bin/make -B LINT TB --- 2010-02-04 07:07:00 - building LINT kernel TB --- 2010-02-04 07:07:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 07:07:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 07:07:00 - TARGET=ia64 TB --- 2010-02-04 07:07:00 - TARGET_ARCH=ia64 TB --- 2010-02-04 07:07:00 - TZ=UTC TB --- 2010-02-04 07:07:00 - __MAKE_CONF=/dev/null TB --- 2010-02-04 07:07:00 - cd /src TB --- 2010-02-04 07:07:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 07:07:00 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 07:13:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 07:13:49 - ERROR: failed to build lint kernel TB --- 2010-02-04 07:13:49 - 3977.53 user 666.08 system 5047.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 07:14:18 2010 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 750F61065692; Thu, 4 Feb 2010 07:14:18 +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 4F6158FC08; Thu, 4 Feb 2010 07:14:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o147EHFu031247; Thu, 4 Feb 2010 02:14:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o147EHnZ031245; Thu, 4 Feb 2010 07:14:17 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 07:14:17 GMT Message-Id: <201002040714.o147EHnZ031245@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 powerpc/powerpc 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, 04 Feb 2010 07:14:18 -0000 TB --- 2010-02-04 06:07:42 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 06:07:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-02-04 06:07:42 - cleaning the object tree TB --- 2010-02-04 06:08:02 - cvsupping the source tree TB --- 2010-02-04 06:08:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-02-04 06:08:52 - building world TB --- 2010-02-04 06:08:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 06:08:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 06:08:52 - TARGET=powerpc TB --- 2010-02-04 06:08:52 - TARGET_ARCH=powerpc TB --- 2010-02-04 06:08:52 - TZ=UTC TB --- 2010-02-04 06:08:52 - __MAKE_CONF=/dev/null TB --- 2010-02-04 06:08:52 - cd /src TB --- 2010-02-04 06:08:52 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 06:08:53 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 4 07:09:22 UTC 2010 TB --- 2010-02-04 07:09:22 - generating LINT kernel config TB --- 2010-02-04 07:09:22 - cd /src/sys/powerpc/conf TB --- 2010-02-04 07:09:22 - /usr/bin/make -B LINT TB --- 2010-02-04 07:09:22 - building LINT kernel TB --- 2010-02-04 07:09:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 07:09:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 07:09:22 - TARGET=powerpc TB --- 2010-02-04 07:09:22 - TARGET_ARCH=powerpc TB --- 2010-02-04 07:09:22 - TZ=UTC TB --- 2010-02-04 07:09:22 - __MAKE_CONF=/dev/null TB --- 2010-02-04 07:09:22 - cd /src TB --- 2010-02-04 07:09:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 07:09:22 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 07:14:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 07:14:17 - ERROR: failed to build lint kernel TB --- 2010-02-04 07:14:17 - 2972.73 user 621.61 system 3994.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 07:35:16 2010 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 9FE00106566B; Thu, 4 Feb 2010 07:35:16 +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 79EB98FC17; Thu, 4 Feb 2010 07:35:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o147ZF2X018388; Thu, 4 Feb 2010 02:35:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o147ZF23018387; Thu, 4 Feb 2010 07:35:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 07:35:15 GMT Message-Id: <201002040735.o147ZF23018387@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 sparc64/sparc64 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, 04 Feb 2010 07:35:16 -0000 TB --- 2010-02-04 06:33:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 06:33:32 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-02-04 06:33:32 - cleaning the object tree TB --- 2010-02-04 06:33:48 - cvsupping the source tree TB --- 2010-02-04 06:33:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-02-04 06:34:37 - building world TB --- 2010-02-04 06:34:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 06:34:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 06:34:37 - TARGET=sparc64 TB --- 2010-02-04 06:34:37 - TARGET_ARCH=sparc64 TB --- 2010-02-04 06:34:37 - TZ=UTC TB --- 2010-02-04 06:34:37 - __MAKE_CONF=/dev/null TB --- 2010-02-04 06:34:37 - cd /src TB --- 2010-02-04 06:34:37 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 06:34:38 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 4 07:30:39 UTC 2010 TB --- 2010-02-04 07:30:39 - generating LINT kernel config TB --- 2010-02-04 07:30:39 - cd /src/sys/sparc64/conf TB --- 2010-02-04 07:30:39 - /usr/bin/make -B LINT TB --- 2010-02-04 07:30:39 - building LINT kernel TB --- 2010-02-04 07:30:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 07:30:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 07:30:39 - TARGET=sparc64 TB --- 2010-02-04 07:30:39 - TARGET_ARCH=sparc64 TB --- 2010-02-04 07:30:39 - TZ=UTC TB --- 2010-02-04 07:30:39 - __MAKE_CONF=/dev/null TB --- 2010-02-04 07:30:39 - cd /src TB --- 2010-02-04 07:30:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 07:30:39 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 07:35:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 07:35:15 - ERROR: failed to build lint kernel TB --- 2010-02-04 07:35:15 - 2805.17 user 592.52 system 3703.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 07:54:06 2010 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 1D3C7106568D; Thu, 4 Feb 2010 07:54:06 +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 EB8398FC08; Thu, 4 Feb 2010 07:54:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o147s5qR061176; Thu, 4 Feb 2010 02:54:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o147s587061175; Thu, 4 Feb 2010 07:54:05 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 4 Feb 2010 07:54:05 GMT Message-Id: <201002040754.o147s587061175@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 sparc64/sun4v 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, 04 Feb 2010 07:54:06 -0000 TB --- 2010-02-04 06:55:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-04 06:55:12 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-02-04 06:55:12 - cleaning the object tree TB --- 2010-02-04 06:55:27 - cvsupping the source tree TB --- 2010-02-04 06:55:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-02-04 06:55:51 - building world TB --- 2010-02-04 06:55:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 06:55:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 06:55:51 - TARGET=sun4v TB --- 2010-02-04 06:55:51 - TARGET_ARCH=sparc64 TB --- 2010-02-04 06:55:51 - TZ=UTC TB --- 2010-02-04 06:55:51 - __MAKE_CONF=/dev/null TB --- 2010-02-04 06:55:51 - cd /src TB --- 2010-02-04 06:55:51 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 4 06:55:51 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 4 07:49:19 UTC 2010 TB --- 2010-02-04 07:49:19 - generating LINT kernel config TB --- 2010-02-04 07:49:19 - cd /src/sys/sun4v/conf TB --- 2010-02-04 07:49:19 - /usr/bin/make -B LINT TB --- 2010-02-04 07:49:19 - building LINT kernel TB --- 2010-02-04 07:49:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-04 07:49:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-04 07:49:19 - TARGET=sun4v TB --- 2010-02-04 07:49:19 - TARGET_ARCH=sparc64 TB --- 2010-02-04 07:49:19 - TZ=UTC TB --- 2010-02-04 07:49:19 - __MAKE_CONF=/dev/null TB --- 2010-02-04 07:49:19 - cd /src TB --- 2010-02-04 07:49:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 4 07:49:19 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_soc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_sm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_library.c /src/sys/dev/isp/isp_library.c: In function 'isp_clear_commands': /src/sys/dev/isp/isp_library.c:653: error: 'ispsoftc_t' has no member named 'isp_tgt_xflist' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-04 07:54:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-04 07:54:05 - ERROR: failed to build lint kernel TB --- 2010-02-04 07:54:05 - 2820.80 user 570.02 system 3532.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 08:47:03 2010 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 432951065670 for ; Thu, 4 Feb 2010 08:47:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id BF51C8FC0C for ; Thu, 4 Feb 2010 08:47:02 +0000 (UTC) Received: by fxm24 with SMTP id 24so487411fxm.3 for ; Thu, 04 Feb 2010 00:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+5TWNzJEFLH2vTzTG9iJ6ziT29hSGYcIIDZG0qZGyj0=; b=Nd16qW/xj2mnVWiAyhh/XlSJGSvoNDK28OU+FvzgVgqFLz0/C5CXfROWjrJps1h9gH jZsS5c2UwEkz86kPH2rK+b26LoouUo9zaiNaWY4Egf43pzGgJ8ev4ZP3/jkz/gTY6OFO lcco0T1vLMAcLgh0Hs21iQPWDHaja2epUSZw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=jnlAXR6THUVzgVDyeibjS51jKLL9FgbWa2/msPOENGgQxGCY81KUyq0Wnb5j3xRtbL Oi7H4OAxOzJUAEm4QeN2UC1bmKOuEeppP2jbAAR1fqwfLp1njwoeRaiPtrY6ydeMqZw2 fGB2s/irHS6htKpYvD8ddyYltZneaouK/76PM= Received: by 10.223.164.156 with SMTP id e28mr799291fay.27.1265273221701; Thu, 04 Feb 2010 00:47:01 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm3602032fxm.1.2010.02.04.00.47.00 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 00:47:01 -0800 (PST) Sender: Alexander Motin Message-ID: <4B6A8981.5090200@FreeBSD.org> Date: Thu, 04 Feb 2010 10:46:57 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marcel Moolenaar References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> <4B69F782.5050108@FreeBSD.org> <800D6F19-6286-4ECB-84D8-F9E37F529552@mac.com> In-Reply-To: <800D6F19-6286-4ECB-84D8-F9E37F529552@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Thu, 04 Feb 2010 08:47:03 -0000 Marcel Moolenaar wrote: > On Feb 3, 2010, at 2:24 PM, Alexander Motin wrote: > >> Do you receive message like "tagged openings now %d" in verbose log? It >> should be there if queue size was adjusted. > > No, that's the problem and it has always been the problem: the > queue never gets adjusted, because when the "adjust openings" > request is sent up with, say, 120 openings, there are already > 121 or more requests queued. This prevents the queue from > being adjusted (XPT fails, doesn't propagate an error down but > expects any interested drivers to try again in case of a > failure)... I don't think you are right here. That message should appear always, independently from result of resize. The only reason why it may not show, is if resize wasn't tried at all due to false result of INQ_DATA_TQ_ENABLED(&dev->inq_data). In other cases number of openings should be adjusted, independently from number of running requests (queue shrinking may be delayed). -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 10:31:02 2010 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 4B2911065670 for ; Thu, 4 Feb 2010 10:31:02 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id AE1FB8FC13 for ; Thu, 4 Feb 2010 10:31:01 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so525711eye.9 for ; Thu, 04 Feb 2010 02:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=977IEYVX1c6kxslPZamoMHzmz85nue56qxnQDHePBJQ=; b=UrWV3mP6HBnYZOJZ9waCQEBtiPXWwh5XUVMH5nluAg9yxntQp4lQIodu6civ6RjQQV l7hqNjg3bLK5/S8M4suTForZGxNvX0CP1Uad1ee0Cw0tDLTWvS0Hgr3jx2MQd4WHgYac Ne6xpn02ZB0uIbeqTZjCtftqByNmoNbNHOOEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Fq9i81D3+5ChlRju/YUMTyvMXMvh4WGTjacEtX+NGqLjZ3MyICudVloF+J1KSPTOhJ /BJ8U8DLnRKxLHg7SB28DebIX2aouk6bCOsd8ZPDLT7ycgv+qvv2XgY35o8574rFDjIn PgGd3mS2eBiuRshUowQ35FCaWNotmilHe6+gI= MIME-Version: 1.0 Received: by 10.216.87.75 with SMTP id x53mr140862wee.144.1265279460637; Thu, 04 Feb 2010 02:31:00 -0800 (PST) In-Reply-To: <4B6970F8.2030807@FreeBSD.org> References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> Date: Thu, 4 Feb 2010 11:31:00 +0100 Message-ID: <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> From: Lucius Windschuh To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] 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, 04 Feb 2010 10:31:02 -0000 Hi Gabor, is there any chance that the BSD-licensed bc will get readline support or that you add a switch in math/gnubc to re-enable readline support? This i a huge enhancement if you use bc interactively. I know that libreadline is GPL-licensed. But maybe, there is an alternative. Regards Lucius From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 13:23:21 2010 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 6CE6A106568F for ; Thu, 4 Feb 2010 13:23:21 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 2417F8FC30 for ; Thu, 4 Feb 2010 13:23:20 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 0825314DA535; Thu, 4 Feb 2010 14:23:20 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CIhaIEzzIZ98; Thu, 4 Feb 2010 14:23:10 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 5A16B14DA51A; Thu, 4 Feb 2010 14:23:10 +0100 (CET) Message-ID: <4B6ACA37.3060807@FreeBSD.org> Date: Thu, 04 Feb 2010 14:23:03 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Lucius Windschuh References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> In-Reply-To: <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] 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, 04 Feb 2010 13:23:21 -0000 El 2010. 02. 04. 11:31, Lucius Windschuh escribió: > Hi Gabor, > is there any chance that the BSD-licensed bc will get readline support > or that you add a switch in math/gnubc to re-enable readline support? > This i a huge enhancement if you use bc interactively. > I know that libreadline is GPL-licensed. But maybe, there is an alternative. > Hi Lucius, I've just committed a change to compile math/gnubc with libedit. It gives you the same and it is part of the base system. When I have sorted out some of my another TODOs, I'll check how complicated it would be to add libedit support to base bc. Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 16:07:31 2010 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 BDAE8106568F; Thu, 4 Feb 2010 16:07:31 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB418FC16; Thu, 4 Feb 2010 16:07:31 +0000 (UTC) Received: by pxi13 with SMTP id 13so273268pxi.3 for ; Thu, 04 Feb 2010 08:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=T5kroBw0NWCe763jRyC0gYDrTw+yE3dTYypMm7NJiac=; b=u+xNJLc5n6ueF3OZsx84HBClp2k53rvLezVpkgjiQNQI6IHUbJMnY/Xg7L3BuSA7TS 0FngNd1YItWz27Zqt1gvLbrSgyX1vkPyT0/TwKaNZgPmtaY0jQ+vsvbCxdE6McXpqGmv ZxZkP83nzdl8aF252Bldm1NlH2o46jtOnBl+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M6MNFYsjUywvVuVLdTB0rSBVfeDwYS9CSYYjXLTYY3VSXikQBe/nXQA3H9rN1SnaKN h4iz8uuTyAW4WSeQ2XFZksY5t+JdYeRbEleLNQB5QfrYXw8j4DGRW7UfcCdBKvLaZ6pS j/jV6QHD3l2Ht6wplJjPiwv+vcNKkeQRNZTrE= MIME-Version: 1.0 Received: by 10.114.252.3 with SMTP id z3mr860959wah.54.1265299650369; Thu, 04 Feb 2010 08:07:30 -0800 (PST) In-Reply-To: <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> Date: Thu, 4 Feb 2010 08:07:30 -0800 Message-ID: From: Xin LI To: Lucius Windschuh Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Gabor Kovesdan Subject: Re: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] 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, 04 Feb 2010 16:07:31 -0000 Hi, Lucius, On Thu, Feb 4, 2010 at 2:31 AM, Lucius Windschuh wrote: > Hi Gabor, > is there any chance that the BSD-licensed bc will get readline support > or that you add a switch in math/gnubc to re-enable readline support? > This i a huge enhancement if you use bc interactively. > I know that libreadline is GPL-licensed. But maybe, there is an alternative. Try this patch: http://pastebin.com/m3f92c202 Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 16:17:20 2010 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 C4F7810656A3 for ; Thu, 4 Feb 2010 16:17:20 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from smtp125.rog.mail.re2.yahoo.com (smtp125.rog.mail.re2.yahoo.com [206.190.53.30]) by mx1.freebsd.org (Postfix) with SMTP id 7718D8FC1A for ; Thu, 4 Feb 2010 16:17:20 +0000 (UTC) Received: (qmail 97606 invoked from network); 4 Feb 2010 16:17:19 -0000 Received: from CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com (gtodd@99.246.61.82 with login) by smtp125.rog.mail.re2.yahoo.com with SMTP; 04 Feb 2010 08:17:19 -0800 PST X-Yahoo-SMTP: nTCfdR6swBBGLC_L2D5qGu5iTT2NdwV8DpHvzb.tTA-- X-YMail-OSG: JKU12pQVM1mNhvvQDQf9GSkW3kBoO95nqJ06gzQxoGWzn2UxrTqIexH8XdUPv9eBNw-- X-Yahoo-Newman-Property: ymail-3 Received: from wawanesa.iciti.ca (wawanesa.iciti.ca [192.168.2.4]) by wawanesa.iciti.ca (Postfix) with ESMTP id 4A3CA36; Thu, 4 Feb 2010 11:17:16 -0500 (EST) Message-ID: <4B6AF30B.4040204@bellanet.org> Date: Thu, 04 Feb 2010 11:17:15 -0500 From: Graham Todd User-Agent: Thunderbird 2.0.0.21 (X11/20090511) MIME-Version: 1.0 To: Gabor Kovesdan , FreeBSD current References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> <4B6ACA37.3060807@FreeBSD.org> In-Reply-To: <4B6ACA37.3060807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: HEADSUP: BSDL bc/dc in head 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, 04 Feb 2010 16:17:20 -0000 Gabor Kovesdan wrote: > El 2010. 02. 04. 11:31, Lucius Windschuh escribió: >> Hi Gabor, >> is there any chance that the BSD-licensed bc will get readline support >> or that you add a switch in math/gnubc to re-enable readline support? >> This i a huge enhancement if you use bc interactively. >> I know that libreadline is GPL-licensed. But maybe, there is an >> alternative. >> > Hi Lucius, > > I've just committed a change to compile math/gnubc with libedit. It > gives you the same and it is part of the base system. When I have sorted > out some of my another TODOs, I'll check how complicated it would be to > add libedit support to base bc. Hi, sorry to be OT. If libedit can be swapped for libreadline in the BSDL bc is it possible to swap them elsewhere? Of course kgdb gdb et al. will always be linked against libreadline but there were a few other tools people seemed surprised to find linked against readline. Under /usr/[s]bin: ntpdc, ntpq, kadmin, ktutil and under /sbin/: gvinum (?!). See this thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-February/002877.html The gvinum code seems like it would be more work but perhaps for someone familiar with libedit/libreadline issues ntpdc ntpq would be "low hanging fruit". A while back I was frequently building heimdal 1.1 from source, somehow linking against libedit (I assumed this was correct since I had not noticed the base heimdal tools were linked against libreadline). Everything worked fine with -ledit instead of -lreadline as far as I could tell. Under 8.0 heimdal in base has changed but it is still linked against readline even though the line editing prompt for kadmin seems fairly basic and libedit seems to work (BTW does ktutil even provide a line editing prompt?). There's probably good reasons for this but *perhaps* for kadmin/ktutil the fruit is not low hanging but already in the basket :) cheers, From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 16:49:25 2010 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 71F671065670; Thu, 4 Feb 2010 16:49:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 59BE98FC0C; Thu, 4 Feb 2010 16:49:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXB003SRTE1XA00@asmtp027.mac.com>; Thu, 04 Feb 2010 08:49:14 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002040138 From: Marcel Moolenaar In-reply-to: <4B6A8981.5090200@FreeBSD.org> Date: Thu, 04 Feb 2010 08:49:12 -0800 Message-id: References: <4B68A18E.1030500@FreeBSD.org> <305C4541-4245-45C9-9FCC-9C6AF4E47DD6@mac.com> <4B68A812.40103@FreeBSD.org> <971A22CA-B14A-4CBC-8D6D-FEB3A4EA2425@mac.com> <4B68B7AC.8050908@FreeBSD.org> <4B69F782.5050108@FreeBSD.org> <800D6F19-6286-4ECB-84D8-F9E37F529552@mac.com> <4B6A8981.5090200@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1077) Cc: "current@freebsd.org mailing list" Subject: Re: CAM verbosity (xpt_release_devq(0): requested 1 > present 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: Thu, 04 Feb 2010 16:49:25 -0000 On Feb 4, 2010, at 12:46 AM, Alexander Motin wrote: > Marcel Moolenaar wrote: >> On Feb 3, 2010, at 2:24 PM, Alexander Motin wrote: >> >>> Do you receive message like "tagged openings now %d" in verbose log? It >>> should be there if queue size was adjusted. >> >> No, that's the problem and it has always been the problem: the >> queue never gets adjusted, because when the "adjust openings" >> request is sent up with, say, 120 openings, there are already >> 121 or more requests queued. This prevents the queue from >> being adjusted (XPT fails, doesn't propagate an error down but >> expects any interested drivers to try again in case of a >> failure)... > > I don't think you are right here. Ok :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 16:51:33 2010 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 9DAE9106568B; Thu, 4 Feb 2010 16:51:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 2FC8C8FC1A; Thu, 4 Feb 2010 16:51:33 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o14GpWhb040196; Thu, 4 Feb 2010 08:51:32 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o14GpWW2040195; Thu, 4 Feb 2010 08:51:32 -0800 (PST) (envelope-from david) Date: Thu, 4 Feb 2010 08:51:32 -0800 From: David Wolfskill To: Alexander Motin Message-ID: <20100204165132.GL32250@bunrab.catwhisker.org> References: <20100203144037.GA32250@bunrab.catwhisker.org> <4B69B4F6.1090608@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j3olVFx0FsM75XyV" Content-Disposition: inline In-Reply-To: <4B69B4F6.1090608@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD-Current Subject: Re: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed 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, 04 Feb 2010 16:51:33 -0000 --j3olVFx0FsM75XyV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 03, 2010 at 07:40:06PM +0200, Alexander Motin wrote: > ... > That was my change r203420. `sysctl kern.cam.power_down=3D0` should > disable new behavior. It can be a bug of aac driver. Is it repeatable > each time at the same place? >=20 > > Tried the same experiment with the laptop; didn't get the above failure, > > but am seeing many (as in "hundreds") of > >=20 > > atapi_poll called! > > atapi_poll called! >=20 > This looks like atapicam misfeature. I'll look on it. Upgrade to r203485 appears to have resolved the issues on both platforms -- thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --j3olVFx0FsM75XyV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktq+xEACgkQmprOCmdXAD2LYgCZAS6Vcr7vuVGmlhv4MEIRpBWy lQgAn0aMbYHzDBx1N+Zn4VXmnK3g1+PY =CEZq -----END PGP SIGNATURE----- --j3olVFx0FsM75XyV-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 17:52:41 2010 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 A08B2106566B; Thu, 4 Feb 2010 17:52:41 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3898FC0A; Thu, 4 Feb 2010 17:52:40 +0000 (UTC) Received: by fxm25 with SMTP id 25so779848fxm.34 for ; Thu, 04 Feb 2010 09:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=o4IVjcwZ5KnIIRJCX+i/lS5QMugjs6zn1xTgBWOpKx0=; b=dumv27fncpPc4u30mO0I2vyp+xqsGK9FlIq3Elhr0CBZQWnZ2vBq5PH4milFdN4HRR PnRuXgQE40Ta9BkB6WzRFpAJ+fmqmlz67E9q5Zl5yBNaAxuv3PuD74D5NMkarfk+Ee4i T9dHInpE2X90QUoX9gRjkPYL8D9iUKPCYYVKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EIZruv6RnjGaIwWUUbZzPGXpGPJCn3IR0iHBAF5ncO0G5ttBTIiYP5P9M4diPywN0p dnWHHeoKRd6J8BsY7Ky/egYIaPbBxGlu6yB+6ss0XkydIeAr7PrsMEfOzSALIcCQZAWy +RBXQirGddKL3LDU0NBRLlQh7wmBHaufkh36M= MIME-Version: 1.0 Received: by 10.216.89.209 with SMTP id c59mr767951wef.181.1265305958850; Thu, 04 Feb 2010 09:52:38 -0800 (PST) In-Reply-To: References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> Date: Thu, 4 Feb 2010 18:52:38 +0100 Message-ID: <90a5caac1002040952i43dc3512ue483d2af5d997d26@mail.gmail.com> From: Lucius Windschuh To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , Gabor Kovesdan Subject: Re: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] 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, 04 Feb 2010 17:52:41 -0000 2010/2/4 Xin LI : > Hi, Lucius, > > On Thu, Feb 4, 2010 at 2:31 AM, Lucius Windschuh > wrote: >> Hi Gabor, >> is there any chance that the BSD-licensed bc will get readline support >> or that you add a switch in math/gnubc to re-enable readline support? >> This i a huge enhancement if you use bc interactively. >> I know that libreadline is GPL-licensed. But maybe, there is an alternative. > > Try this patch: > > http://pastebin.com/m3f92c202 Thanks. :-D That's what I missed. And I didn't know about libedit. I really wondered if there was no alternative to GNU readline (as I need a command line parser in some other projects). Lucius BTW: Pastebin converted the line endings to DOS format, which I find a bit strange. From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 18:00:07 2010 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 A6306106566B for ; Thu, 4 Feb 2010 18:00:07 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id CFBF48FC16 for ; Thu, 4 Feb 2010 18:00:06 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id A5356A67278; Fri, 5 Feb 2010 02:00:05 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id V0jh4eyoIUuz; Fri, 5 Feb 2010 01:59:55 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 93722A6725F; Fri, 5 Feb 2010 01:59:54 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type; b=W9SezRY/2NyyCzBWFjjBFVHfIE7kYwjW9W/I46Hn1xeRqspb0EdBJeJsQnNbknOLj NpMBxNDRVOMpiEnJ6PZYg== Message-ID: <4B6B0B16.4070503@delphij.net> Date: Thu, 04 Feb 2010 09:59:50 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> <90a5caac1002040952i43dc3512ue483d2af5d997d26@mail.gmail.com> In-Reply-To: <90a5caac1002040952i43dc3512ue483d2af5d997d26@mail.gmail.com> X-Enigmail-Version: 1.0 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------090908010605000406020707" Subject: Re: HEADSUP: BSDL bc/dc in head [Was: svn commit: r202719 - in head: . gnu/usr.bin usr.bin usr.bin/bc usr.bin/bc/USD.doc usr.bin/dc usr.bin/dc/USD.doc] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 18:00:07 -0000 This is a multi-part message in MIME format. --------------090908010605000406020707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/02/04 09:52, Lucius Windschuh wrote: > 2010/2/4 Xin LI : >> Hi, Lucius, >> >> On Thu, Feb 4, 2010 at 2:31 AM, Lucius Windschuh >> wrote: >>> Hi Gabor, >>> is there any chance that the BSD-licensed bc will get readline support >>> or that you add a switch in math/gnubc to re-enable readline support? >>> This i a huge enhancement if you use bc interactively. >>> I know that libreadline is GPL-licensed. But maybe, there is an alternative. >> >> Try this patch: >> >> http://pastebin.com/m3f92c202 > > Thanks. :-D That's what I missed. > And I didn't know about libedit. I really wondered if there was no > alternative to GNU readline (as I need a command line parser in some > other projects). libedit has provided most functionality that GNU readline provided under a BSD license. (We may want to update it to a newer snapshot from NetBSD anyways). > Lucius > > BTW: Pastebin converted the line endings to DOS format, which I find a > bit strange. Em... That's weird, maybe I should have uploaded the patch instead of pasting it? - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLawsWAAoJEATO+BI/yjfBM1YIAJ1H58m0Kbh+AhFB5pm+pxLG M0MilVACBDbKmINmR9RRuF8N9x3gEIdYgO41UC69ggUlMDN9b9sZk7dbN09tVKRr 2O58kHrW1MHWgdgv85ayRyBCC3oGs0PKqPwzHLyj9lYd6w7P5YAhiVAvArjdzvJM +lftPKZOdY+0iP7ACGOmcpFlCN23sF+AdcyJA281z41iOcwNXztHgqZIgZSGUyI6 HWFyeeGaJuAOWhSP0uhnpkoUkvMDAggAPRAfdi8DXPioWbn5GB/PkOjsC54TmINC GSwCqpDeW2W6+GfxMlhh8nT5Z0zLXvta5KrOUszUq8hKnJSgV+ickwmpxkYaW/k= =42x1 -----END PGP SIGNATURE----- --------------090908010605000406020707 Content-Type: text/plain; name="bc-libedit.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bc-libedit.diff" SW5kZXg6IHVzci5iaW4vYmMvYmMueQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL2JjL2Jj LnkJKHJldmlzaW9uIDIwMzQ5NykKKysrIHVzci5iaW4vYmMvYmMueQkod29ya2luZyBjb3B5 KQpAQCAtNDAsNiArNDAsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8 ZXJyLmg+CiAjaW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxnZXRvcHQuaD4KKyNpbmNs dWRlIDxoaXN0ZWRpdC5oPgogI2luY2x1ZGUgPGxpbWl0cy5oPgogI2luY2x1ZGUgPHNlYXJj aC5oPgogI2luY2x1ZGUgPHNpZ25hbC5oPgpAQCAtMTEwNiw2ICsxMTA3LDEzIEBAIHNpZ2No bGQoaW50IHNpZ25vKQogCX0KIH0KIAorc3RhdGljIGNvbnN0IGNoYXIgKgorZHVtbXlfcHJv bXB0KHZvaWQpCit7CisKKyAgICAgICAgcmV0dXJuICgiIik7Cit9CisKIGludAogbWFpbihp bnQgYXJnYywgY2hhciAqYXJndltdKQogewpAQCAtMTE3Myw2ICsxMTgxLDE2IEBAIG1haW4o aW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKIAkJCWR1cChwWzFdKTsKIAkJCWNsb3NlKHBbMF0p OwogCQkJY2xvc2UocFsxXSk7CisJCQlpZiAoaW50ZXJhY3RpdmUpIHsKKwkJCQllbCA9IGVs X2luaXQoImJjIiwgc3RkaW4sIHN0ZGVyciwgc3RkZXJyKTsKKwkJCQloaXN0ID0gaGlzdG9y eV9pbml0KCk7CisJCQkJaGlzdG9yeShoaXN0LCAmaGUsIEhfU0VUU0laRSwgMTAwKTsKKwkJ CQllbF9zZXQoZWwsIEVMX0hJU1QsIGhpc3RvcnksIGhpc3QpOworCQkJCWVsX3NldChlbCwg RUxfRURJVE9SLCAiZW1hY3MiKTsKKwkJCQllbF9zZXQoZWwsIEVMX1NJR05BTCwgMSk7CisJ CQkJZWxfc2V0KGVsLCBFTF9QUk9NUFQsIGR1bW15X3Byb21wdCk7CisJCQkJZWxfc291cmNl KGVsLCBOVUxMKTsKKwkJCX0KIAkJfSBlbHNlIHsKIAkJCWNsb3NlKFNURElOX0ZJTEVOTyk7 CiAJCQlkdXAocFswXSk7CkluZGV4OiB1c3IuYmluL2JjL2V4dGVybi5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHVzci5iaW4vYmMvZXh0ZXJuLmgJKHJldmlzaW9uIDIwMzQ5NykKKysrIHVzci5i aW4vYmMvZXh0ZXJuLmgJKHdvcmtpbmcgY29weSkKQEAgLTM1LDQgKzM1LDggQEAgZXh0ZXJu IGludAkJIHNhcmdjOwogZXh0ZXJuIGNvbnN0IGNoYXIJKipzYXJndjsKIGV4dGVybiBjb25z dCBjaGFyCSpmaWxlbmFtZTsKIGV4dGVybiBjaGFyCQkqY21kZXhwcjsKLWJvb2wJCQkgaW50 ZXJhY3RpdmU7CitleHRlcm4gYm9vbAkJIGludGVyYWN0aXZlOworZXh0ZXJuIEVkaXRMaW5l CQkqZWw7CitleHRlcm4gSGlzdG9yeQkJKmhpc3Q7CitleHRlcm4gSGlzdEV2ZW50CSBoZTsK KwpJbmRleDogdXNyLmJpbi9iYy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmlu L2JjL01ha2VmaWxlCShyZXZpc2lvbiAyMDM0OTcpCisrKyB1c3IuYmluL2JjL01ha2VmaWxl CSh3b3JraW5nIGNvcHkpCkBAIC01LDYgKzUsOSBAQCBQUk9HPQliYwogU1JDUz0JYmMueSBz Y2FuLmwKIENGTEFHUys9IC1JLiAtSSR7LkNVUkRJUn0KIAorRFBBREQ9CSR7TElCRURJVH0g JHtMSUJURVJNQ0FQfQorTERBREQ9CS1sZWRpdCAtbHRlcm1jYXAKKwogRklMRVMrPQliYy5s aWJyYXJ5CiBGSUxFU0RJUj0ke1NIQVJFRElSfS9taXNjCiAKSW5kZXg6IHVzci5iaW4vYmMv c2Nhbi5sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5iaW4vYmMvc2Nhbi5sCShyZXZpc2lvbiAy MDM0OTcpCisrKyB1c3IuYmluL2JjL3NjYW4ubAkod29ya2luZyBjb3B5KQpAQCAtMjIsNiAr MjIsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxlcnIuaD4KICNp bmNsdWRlIDxlcnJuby5oPgorI2luY2x1ZGUgPGhpc3RlZGl0Lmg+CiAjaW5jbHVkZSA8c2ln bmFsLmg+CiAjaW5jbHVkZSA8c3RkYm9vbC5oPgogI2luY2x1ZGUgPHN0cmluZy5oPgpAQCAt MzMsMTMgKzM0LDIyIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAogaW50CQkgbGluZW5v OwogCitib29sCQkgaW50ZXJhY3RpdmU7CitIaXN0RXZlbnQJIGhlOworRWRpdExpbmUJKmVs OworSGlzdG9yeQkJKmhpc3Q7CisKIHN0YXRpYyBjaGFyCSpzdHJidWYgPSBOVUxMOwogc3Rh dGljIHNpemVfdAkgc3RyYnVmX3N6ID0gMTsKIHN0YXRpYyBib29sCSBkb3Rfc2VlbjsKIAog c3RhdGljIHZvaWQJIGluaXRfc3RyYnVmKHZvaWQpOwogc3RhdGljIHZvaWQJIGFkZF9zdHIo Y29uc3QgY2hhciAqKTsKK3N0YXRpYyBpbnQJIGJjX3l5aW5wdXQoY2hhciAqLCBpbnQpOwog CisjdW5kZWYgWVlfSU5QVVQKKyNkZWZpbmUgWVlfSU5QVVQoYnVmLHJldHZhbCxtYXgpIFwK KwkocmV0dmFsID0gYmNfeXlpbnB1dChidWYsIG1heCkpCiAlfQogCiAlb3B0aW9uIGFsd2F5 cy1pbnRlcmFjdGl2ZQpAQCAtMjg2LDMgKzI5NiwzMiBAQCB5eXdyYXAodm9pZCkKIAl9CiAJ cmV0dXJuICgxKTsKIH0KKworc3RhdGljIGludAorYmNfeXlpbnB1dChjaGFyICpidWYsIGlu dCBtYXhsZW4pCit7CisJaW50IG51bTsKKwlpZiAoaW50ZXJhY3RpdmUpIHsKKwkJY29uc3Qg Y2hhciAqYnA7CisKKwkJaWYgKChicCA9IGVsX2dldHMoZWwsICZudW0pKSA9PSBOVUxMIHx8 IG51bSA9PSAwKQorCQkJcmV0dXJuICgwKTsKKwkJaWYgKG51bSA+IG1heGxlbikgeworCQkJ ZWxfcHVzaChlbCwgKGNoYXIgKikodWludHB0cl90KShicCkgKyBtYXhsZW4pOworCQkJbnVt ID0gbWF4bGVuOworCQl9CisJCW1lbWNweShidWYsIGJwLCBudW0pOworCQloaXN0b3J5KGhp c3QsICZoZSwgSF9FTlRFUiwgYnApOworCX0gZWxzZSB7CisJCWludCBjID0gJyonOworCQlm b3IgKG51bSA9IDA7IG51bSA8IG1heGxlbiAmJgorCQkgICAgKGMgPSBnZXRjKHl5aW4pKSAh PSBFT0YgJiYgYyAhPSAnXG4nOyArK251bSkKKwkJCWJ1ZltudW1dID0gKGNoYXIpIGM7CisJ CWlmIChjID09ICdcbicpCisJCQlidWZbbnVtKytdID0gKGNoYXIpIGM7CisJCWlmIChjID09 IEVPRiAmJiBmZXJyb3IoeXlpbikpCisJCQlZWV9GQVRBTF9FUlJPUiggImlucHV0IGluIGZs ZXggc2Nhbm5lciBmYWlsZWQiICk7CisJfQorCXJldHVybiAobnVtKTsKK30KKwo= --------------090908010605000406020707-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 22:44:35 2010 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 49663106566B for ; Thu, 4 Feb 2010 22:44:35 +0000 (UTC) (envelope-from pgollucci@p6m7g8.com) Received: from EXHUB015-4.exch015.msoutlookonline.net (exhub015-4.exch015.msoutlookonline.net [207.5.72.96]) by mx1.freebsd.org (Postfix) with ESMTP id 38AA98FC23 for ; Thu, 4 Feb 2010 22:44:35 +0000 (UTC) Received: from philip.hq.rws (174.79.184.239) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 4 Feb 2010 14:34:33 -0800 Message-ID: <4B6B4B77.6010002@p6m7g8.com> Date: Thu, 4 Feb 2010 22:34:31 +0000 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20091208) MIME-Version: 1.0 To: current@Freebsd.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Apache Infrastructure - Private Private , developers@FreeBSD.org Subject: LSI SAS 9200-8e SGL 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, 04 Feb 2010 22:44:35 -0000 Hi, The ASF recently purchased one of these PCIe cards to use with an external array. Apparently they are currently unsupported on both stable/7 and stable/8. Can a developer confirm this, and if so we may be willing to pay a bounty to get supported added. Feel free to drop the cross post, but please keep the infra-private CC. At least the following PR seems relevant http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134520&cat= Thanks. -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From owner-freebsd-current@FreeBSD.ORG Thu Feb 4 23:13:50 2010 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 1C3D0106568B for ; Thu, 4 Feb 2010 23:13:50 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id D38CE8FC1C for ; Thu, 4 Feb 2010 23:13:49 +0000 (UTC) Received: from [10.8.0.2] (remotevpn [10.8.0.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o14Mp4vn059180 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 4 Feb 2010 14:51:05 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B6B4F58.9090707@feral.com> Date: Thu, 04 Feb 2010 14:51:04 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc11 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Philip M. Gollucci" References: <4B6B4B77.6010002@p6m7g8.com> In-Reply-To: <4B6B4B77.6010002@p6m7g8.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [10.8.0.1]); Thu, 04 Feb 2010 14:51:05 -0800 (PST) X-Mailman-Approved-At: Thu, 04 Feb 2010 23:24:30 +0000 Cc: current@FreeBSD.org, developers@FreeBSD.org Subject: Re: LSI SAS 9200-8e SGL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@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: Thu, 04 Feb 2010 23:13:50 -0000 On 02/04/2010 02:34 PM, Philip M. Gollucci wrote: > Hi, > > The ASF recently purchased one of these PCIe cards to use with an > external array. Apparently they are currently unsupported on both > stable/7 and stable/8. > > Can a developer confirm this, and if so we may be willing to pay a > bounty to get supported added. > > Feel free to drop the cross post, but please keep the infra-private CC. > > At least the following PR seems relevant > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134520&cat= > > Thanks. > > Per your subject line, I believe that this is the mpt2 SAS2 device? If so, both another developer and I have prototype and incomplete drivers. You should contact us both off list to talk about how to move forward. PR/134520 is about a 1078 that isn't being attached by mpt(4)- different problem. From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 01:33:10 2010 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 8E39E1065679 for ; Fri, 5 Feb 2010 01:33:10 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 59E7E8FC1C for ; Fri, 5 Feb 2010 01:33:10 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so352250qwd.7 for ; Thu, 04 Feb 2010 17:33:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.63.170 with SMTP id b42mr642297qai.39.1265331806728; Thu, 04 Feb 2010 17:03:26 -0800 (PST) X-Originating-IP: [128.95.133.55] Date: Thu, 4 Feb 2010 17:03:26 -0800 Message-ID: From: Rob Farmer To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 01:33:10 -0000 Hi, I'm running current (r203336) with mail/ssmtp from ports installed instead of sendmail. Whenever I try to send email, I get an error that libutil.so.8 is not available. # periodic daily /libexec/ld-elf.so.1: Shared object "libutil.so.8" not found, required by "sendmail" # ldd /usr/sbin/sendmail /usr/sbin/sendmail: libutil.so.8 => not found (0x0) libc.so.7 => /lib/libc.so.7 (0x800646000) I'm not sure if this is a problem with mailwrapper in the base system or the ssmtp port - any pointers? Thanks, -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 02:02:35 2010 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 CBB8D106566B for ; Fri, 5 Feb 2010 02:02:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7468FC14 for ; Fri, 5 Feb 2010 02:02:35 +0000 (UTC) Received: by bwz3 with SMTP id 3so2647226bwz.13 for ; Thu, 04 Feb 2010 18:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=1gNnC9UgCFTT2YYz5s5pSFGJwJD8nSFyr7JxvQSr/Yc=; b=TD+K2ZS9I3BNHAqtBTCrG/WQ3U2q4MXcmaBUhdopsWwN40PskDC2IcgOICTZlORMNL P/Lj/3woGRm25/yhiQy17jstPnhkKuVxJAdoIPjpsUdYK39yNjR/4r/d/a1NO6eg8Gkk PF1jTCF9HQwmIyNYSEe/3LwgI5rhBhpvYQvkY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=WOLDrarM3jnOuiM9g3S1Uk8D/4OVH1KHNQDqwcSG0RiqjUGqOb8uCcndYzS8Zxqu5T j92G4EIP8XtJlgRFP4gyvegyeX80a4j4s5p/+/o8xspSlrjJ4MnbjlpovBYV2zNceu1n 55/4/YtyQpOQbB7mMUi2TyB9VnYPt0FMdkdTI= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.204.151.216 with SMTP id d24mr1307599bkw.1.1265335354272; Thu, 04 Feb 2010 18:02:34 -0800 (PST) In-Reply-To: References: Date: Thu, 4 Feb 2010 21:02:34 -0500 X-Google-Sender-Auth: 5444cadf3af0a59a Message-ID: From: Justin Hibbits To: Rob Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 02:02:36 -0000 On Thu, Feb 4, 2010 at 8:03 PM, Rob Farmer wrote: > Hi, > > I'm running current (r203336) with mail/ssmtp from ports installed > instead of sendmail. Whenever I try to send email, I get an error that > libutil.so.8 is not available. > > # periodic daily > /libexec/ld-elf.so.1: Shared object "libutil.so.8" not found, required > by "sendmail" > > # ldd /usr/sbin/sendmail > /usr/sbin/sendmail: > libutil.so.8 => not found (0x0) > libc.so.7 => /lib/libc.so.7 (0x800646000) > > I'm not sure if this is a problem with mailwrapper in the base system > or the ssmtp port - any pointers? > > Thanks, > -- > Rob Farmer > _______________________________________________ > 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" > libutil's version was bumped to 9 with the removal of utmp, so if you did a make delete-old after your most recent upgrade you'll have lost libutil.so.8. Recompiling mail/ssmtp will make it link against the newer library. From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 02:13:26 2010 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 85EBC106566B for ; Fri, 5 Feb 2010 02:13:26 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 25E938FC14 for ; Fri, 5 Feb 2010 02:13:25 +0000 (UTC) Received: by fxm26 with SMTP id 26so3327061fxm.33 for ; Thu, 04 Feb 2010 18:13:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.80.32 with SMTP id h32mr1293272mul.59.1265334117918; Thu, 04 Feb 2010 17:41:57 -0800 (PST) In-Reply-To: References: Date: Thu, 4 Feb 2010 20:41:57 -0500 Message-ID: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> From: Michael Proto To: Rob Farmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 02:13:26 -0000 On Thu, Feb 4, 2010 at 8:03 PM, Rob Farmer wrote= : > Hi, > > I'm running current (r203336) with mail/ssmtp from ports installed > instead of sendmail. Whenever I try to send email, I get an error that > libutil.so.8 is not available. > > # periodic daily > /libexec/ld-elf.so.1: Shared object "libutil.so.8" not found, required > by "sendmail" > > # ldd /usr/sbin/sendmail > /usr/sbin/sendmail: > =A0 =A0 =A0 =A0libutil.so.8 =3D> not found (0x0) > =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x800646000) > > I'm not sure if this is a problem with mailwrapper in the base system > or the ssmtp port - any pointers? > > Thanks, > -- > Rob Farmer > _______________________________________________ > 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= " > Would appear to be a problem with your base system, as both mailwrapper and /usr/libexec/sendmail/sendmail both use libutil.so.8: minibsd8-dev:root/ # ldd /usr/sbin/mailwrapper /usr/sbin/mailwrapper: libutil.so.8 =3D> /lib/libutil.so.8 (0x28083000) libc.so.7 =3D> /lib/libc.so.7 (0x28090000) Try reinstalling libutil from /usr/src/lib/libutil perhaps? -Proto From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 02:34:53 2010 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 4948E106566B; Fri, 5 Feb 2010 02:34:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 012398FC15; Fri, 5 Feb 2010 02:34:52 +0000 (UTC) Received: by pzk40 with SMTP id 40so3561421pzk.7 for ; Thu, 04 Feb 2010 18:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vICBUzy0SGR489vSncM7S3u/3VdBwOd8EQQAVQUXPH8=; b=EwZarmrnA2D3O+NkXjaH13JqOVcBymqhoy0YxzIAdbtsAjFOoAAQxmm997r0yHtrQD 28uSFy4mc+qH2oi9Nu3N7h+tvLv2+18e2qQd2ChbSjVQDtADNxC4ziuMu0EpYNpgIYDd 1jbTv5KAShAEwUiaU0IfCBGXtVVOB0vh1p9wA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=IH0WuzoGl+TcjyEDpNuavpXm1QDbP4kYOpwpXrQVBmRZs2BQHhTZTthulEQ1llbxuA k2KakfAVRcyKLXLqNVRHSvCcU5I6jOPgC1toNFWPGfP78IM+3M8Up9I+S9e2yZSS9SNF LQVxar5goh8ElqCvaBUy0mvdgKhUwcQ9FOPQk= MIME-Version: 1.0 Sender: yanegomi@gmail.com Received: by 10.114.215.8 with SMTP id n8mr1280179wag.212.1265335419802; Thu, 04 Feb 2010 18:03:39 -0800 (PST) Date: Thu, 4 Feb 2010 18:03:39 -0800 X-Google-Sender-Auth: c984cf42aed8849b Message-ID: <364299f41002041803m60604979n1f2534e8d5e20af0@mail.gmail.com> From: Garrett Cooper To: trhodes@freebsd.org Content-Type: multipart/mixed; boundary=0016e64b970e381515047ed0dc7b Cc: current@freebsd.org Subject: Draft script for identifying [and someday documenting] tunables 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, 05 Feb 2010 02:34:53 -0000 --0016e64b970e381515047ed0dc7b Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, and other CURRENT folks, One of the items that needs to be fixed up on the documentation page from what I've seen is that the kernel sysctl and tunables information needs to be properly updated because it's either the description is missing, out-of-date, or the sysctl OID or tunable has been removed, etc. I came up with this [relatively] simple script for parsing tunables -- took a crack at trying to get sysctl support in as well, but hit a brick wall because the method for walking over the source tree is fairly basic. What should be done to catch everything in an automated manner is that there need to be some preprocessor defines plugged into the tunable and sysctl macros so that it prints out the proper description for the properties under inspection. Anyhow, if someone can propose a way to do that quickly and cleanly, I'll write up a more standardized proposal with basic code that can get plugged into the headers, so it punts out this info for the script, which will produce an automated mapping of what tunables are used, and the complete sysctl MIB. Thanks! -Garrett #!/usr/bin/env python """ Traverse a source tree to produce a list of FreeBSD sysctls and tunables for documentation purposes. Copyright (c) 1992-2010 Cisco Systems, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. """ # NOTE: this is done in python because it's more flexible than sed, awk, etc. # # XXX (gcooper): # 1. FreeBSD kernel tunables should be defined in an easy-to-understand # self-documenting method as they aren't today (you can grab the information # from the sysctl description, but it's messy parsing the description if it's # not in the same file or the immediate area around the tunable definition); # hence the description parsing is disabled. # 2. This data should be piped via subprocess through cpp(1) to look at the # tunable data, probably. # import optparse import os import re PARSE_SYSCTLS, PARSE_TUNABLES = 1, 2 SYSCTL_RE = re.compile('^\s*SYSCTL_[A-Z_]+\s*\("(.+)", .+, "(.+)"\)') TUNABLE_RE = re.compile('^\s*TUNABLE_[A-Z]+\s*\("([a-z\.]+)", .+\)') class KernelProperty(object): """ A generic class for Sysctl and Tunable objects """ def __init__ (self, name, **kwargs): """ Tunable objects constructor. name - tunable name; required. description - tunable description; optional. file - file where the info was spotted; optional. line - line where the tunable was defined; optional. XXX (gcooper): description is hardwired to None -- make this a requirement when self-documenting tunable info is completed... """ if not name: raise ValueError('name must be defined to a non-zero length string') for i in [ 'description', 'file', 'line' ]: setattr(self, i, kwargs.get(i)) #if not description: # raise ValueError('description must be defined to a non-zero ' # 'length string') self.name = name def __str__ (self): """ `Prints' out the KernelProperty object in stringized form. The format is as follows: 1. name 2. file:line name 3. name = "description" 4. file:line name = "description" The format printed out all depends on the data provided by parse_kernel_objects(...). """ # Provide the file / line info. # pylint: disable-msg=E1101 if self.file and self.line: # pylint: disable-msg=E1101 prefix = '%s:%d: ' % (self.file, self.line) else: prefix = '' # Omit the description. # pylint: disable-msg=E1101 if self.description: # pylint: disable-msg=E1101 suffix = ' = "%s"' % (self.description,) else: suffix = '' # NOTE (gcooper): if either prefix or suffix is empty, there will be # nasty heading / trailing whitespace. Hence, I used + concatenation # instead of ' '.join([..]), because this is considerably cheaper to # do than '%s%s%s' (and far less braindead)... return prefix + self.name + suffix class Sysctl(KernelProperty): """ A class corresponding to a kernel sysctl OID property. """ class Tunable(KernelProperty): """ A class corresponding to a kernel tunable object. """ def main(): """ Main function of course. """ parser = optparse.OptionParser() parser.add_option('-d', '--srcdir', dest='srcdir', default='/usr/src/sys', help=('source directory to look for sysctls and ' 'tunables in')) # # XXX (gcooper): this is more difficult to do as the descriptions # themselves span multiple lines. Needless to say, it's a Orlando Bloom-ing # parsing mess... # #parser.add_option('-s', '--sysctl', dest='parse_sysctls', default=False, # action='store_true', # help='look for sysctls OIDs') parser.add_option('-t', '--tunable', dest='parse_tunables', default=False, action='store_true', help='look for tunables') parser.add_option('-v', '--verbose', dest='verbose', default=False, action='store_true', help='include file/line results for tunables.') opts, __ = parser.parse_args() kknobs = 0 # XXX (garrcoop): sysctl parsing's a pain -- so it's disabled... # See above comment. kknobs = PARSE_TUNABLES # #if opts.parse_sysctls: # kknobs |= PARSE_SYSCTLS #if opts.parse_tunables: # kknobs |= PARSE_TUNABLES # #if not kknobs: # kknobs = PARSE_SYSCTLS sysctls, tunables = comb_tree_for_kernel_objects(opts.srcdir, kernel_knobs=kknobs, verbose_info=opts.verbose,) if sysctls: print '\n'.join([ 'Sysctls:' ] + map(str, sysctls)) if tunables: print '\n'.join([ 'Tunables:' ] + map(str, tunables)) def comb_tree_for_kernel_objects(srcdir, kernel_knobs, verbose_info=False): """ Comb a tree looking for kernel tunables in files under srcdir. - Returns a list of Tunable objects found in srcdir. - The file and line number the tunable was found on will be saved when verbose_info is set to True. See the Tunable class for more details. """ sysctls = [] tunables = [] # Doing this makes relpath considerably simpler and cleaner than doing it # inside the loop. os.chdir(srcdir) for root, __, files in os.walk(srcdir): for _file in files: _file = os.path.relpath(os.path.join(root, _file)) _sysctls, _tunables = parse_kernel_objects(_file, kernel_knobs, verbose_info) sysctls.extend(_sysctls) tunables.extend(_tunables) return sysctls, tunables def parse_kernel_objects(_file, kernel_knobs, verbose_info=False): """ Comb a tree looking for kernel tunables. - Returns a tuple of lists containing Sysctl and Tunable objects found in _file. - The file and line number the tunable was found on will be saved when verbose_info is set to True. See the KernelProperty class for more details. """ kwargs = { } sysctls = [] tunables = [] parse_sysctls = kernel_knobs & PARSE_SYSCTLS parse_tunables = kernel_knobs & PARSE_TUNABLES if not (parse_sysctls or parse_tunables): # Needs to be an inclusive or of PARSE_SYSCTLS, PARSE_TUNABLES, or a # combination of the two knobs. raise ValueError('invalid value for kernel_knobs: %s' % str(kernel_knobs)) if verbose_info: kwargs['file'] = _file fd = open(_file, 'r') try: lines = fd.readlines() finally: fd.close() kwargs['line'] = 0 for line in lines: kwargs['line'] += 1 if parse_tunables: match = TUNABLE_RE.match(line) else: match = None if match: tunables.append(Tunable(match.group(1), **kwargs)) elif parse_sysctls: match = SYSCTL_RE.match(line) if match: sysctls.append(Sysctl(match.group(1), description=match.group(2), **kwargs)) return sysctls, tunables if __name__ == '__main__': main() --0016e64b970e381515047ed0dc7b Content-Type: application/octet-stream; name="find_freebsd_kernel_properties.py" Content-Disposition: attachment; filename="find_freebsd_kernel_properties.py" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g5ac0vbr0 IyEvdXNyL2Jpbi9lbnYgcHl0aG9uCiIiIgoKVHJhdmVyc2UgYSBzb3VyY2UgdHJlZSB0byBwcm9k dWNlIGEgbGlzdCBvZiBGcmVlQlNEIHN5c2N0bHMgYW5kIHR1bmFibGVzCmZvciBkb2N1bWVudGF0 aW9uIHB1cnBvc2VzLgoKQ29weXJpZ2h0IChjKSAxOTkyLTIwMTAgQ2lzY28gU3lzdGVtcywgSW5j LiBBbGwgcmlnaHRzIHJlc2VydmVkLgoKUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Cm1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucwphcmUgbWV0OgoxLiBS ZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHly aWdodAogICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n IGRpc2NsYWltZXIuCjIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CiAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KClRI SVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBg QVMgSVMnJyBBTkQKQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCklNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFC SUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCkFSRSBESVNDTEFJTUVE LiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxF CkZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMCkRBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCk9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVT RSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQpIT1dFVkVSIENB VVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1Qs IFNUUklDVApMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVS V0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCk9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKU1VDSCBEQU1BR0UuCgoiIiIK CiMgTk9URTogdGhpcyBpcyBkb25lIGluIHB5dGhvbiBiZWNhdXNlIGl0J3MgbW9yZSBmbGV4aWJs ZSB0aGFuIHNlZCwgYXdrLCBldGMuCiMKIyBYWFggKGdjb29wZXIpOgojIDEuIEZyZWVCU0Qga2Vy bmVsIHR1bmFibGVzIHNob3VsZCBiZSBkZWZpbmVkIGluIGFuIGVhc3ktdG8tdW5kZXJzdGFuZAoj IHNlbGYtZG9jdW1lbnRpbmcgbWV0aG9kIGFzIHRoZXkgYXJlbid0IHRvZGF5ICh5b3UgY2FuIGdy YWIgdGhlIGluZm9ybWF0aW9uCiMgZnJvbSB0aGUgc3lzY3RsIGRlc2NyaXB0aW9uLCBidXQgaXQn cyBtZXNzeSBwYXJzaW5nIHRoZSBkZXNjcmlwdGlvbiBpZiBpdCdzCiMgbm90IGluIHRoZSBzYW1l IGZpbGUgb3IgdGhlIGltbWVkaWF0ZSBhcmVhIGFyb3VuZCB0aGUgdHVuYWJsZSBkZWZpbml0aW9u KTsKIyBoZW5jZSB0aGUgZGVzY3JpcHRpb24gcGFyc2luZyBpcyBkaXNhYmxlZC4KIyAyLiBUaGlz IGRhdGEgc2hvdWxkIGJlIHBpcGVkIHZpYSBzdWJwcm9jZXNzIHRocm91Z2ggY3BwKDEpIHRvIGxv b2sgYXQgdGhlCiMgdHVuYWJsZSBkYXRhLCBwcm9iYWJseS4KIwoKaW1wb3J0IG9wdHBhcnNlCmlt cG9ydCBvcwppbXBvcnQgcmUKClBBUlNFX1NZU0NUTFMsIFBBUlNFX1RVTkFCTEVTID0gMSwgMgpT WVNDVExfUkUgPSByZS5jb21waWxlKCdeXHMqU1lTQ1RMX1tBLVpfXStccypcKCIoLispIiwgLiss ICIoLispIlwpJykKVFVOQUJMRV9SRSA9IHJlLmNvbXBpbGUoJ15ccypUVU5BQkxFX1tBLVpdK1xz KlwoIihbYS16XC5dKykiLCAuK1wpJykKCmNsYXNzIEtlcm5lbFByb3BlcnR5KG9iamVjdCk6CiAg ICAiIiIgQSBnZW5lcmljIGNsYXNzIGZvciBTeXNjdGwgYW5kIFR1bmFibGUgb2JqZWN0cyAiIiIK CiAgICBkZWYgX19pbml0X18gKHNlbGYsIG5hbWUsICoqa3dhcmdzKToKICAgICAgICAiIiIgVHVu YWJsZSBvYmplY3RzIGNvbnN0cnVjdG9yLgoKICAgICAgICBuYW1lIC0gdHVuYWJsZSBuYW1lOyBy ZXF1aXJlZC4KICAgICAgICBkZXNjcmlwdGlvbiAtIHR1bmFibGUgZGVzY3JpcHRpb247IG9wdGlv bmFsLgogICAgICAgIGZpbGUgLSBmaWxlIHdoZXJlIHRoZSBpbmZvIHdhcyBzcG90dGVkOyBvcHRp b25hbC4KICAgICAgICBsaW5lIC0gbGluZSB3aGVyZSB0aGUgdHVuYWJsZSB3YXMgZGVmaW5lZDsg b3B0aW9uYWwuCgogICAgICAgIFhYWCAoZ2Nvb3Blcik6IGRlc2NyaXB0aW9uIGlzIGhhcmR3aXJl ZCB0byBOb25lIC0tIG1ha2UgdGhpcyBhCiAgICAgICAgcmVxdWlyZW1lbnQgd2hlbiBzZWxmLWRv Y3VtZW50aW5nIHR1bmFibGUgaW5mbyBpcyBjb21wbGV0ZWQuLi4KICAgICAgICAiIiIKICAgICAg ICBpZiBub3QgbmFtZToKICAgICAgICAgICAgcmFpc2UgVmFsdWVFcnJvcignbmFtZSBtdXN0IGJl IGRlZmluZWQgdG8gYSBub24temVybyBsZW5ndGggc3RyaW5nJykKCiAgICAgICAgZm9yIGkgaW4g WyAnZGVzY3JpcHRpb24nLCAnZmlsZScsICdsaW5lJyBdOgogICAgICAgICAgICBzZXRhdHRyKHNl bGYsIGksIGt3YXJncy5nZXQoaSkpCgogICAgICAgICNpZiBub3QgZGVzY3JpcHRpb246CiAgICAg ICAgIyAgICByYWlzZSBWYWx1ZUVycm9yKCdkZXNjcmlwdGlvbiBtdXN0IGJlIGRlZmluZWQgdG8g YSBub24temVybyAnCiAgICAgICAgIyAgICAgICAgICAgICAgICAgICAgICdsZW5ndGggc3RyaW5n JykKICAgICAgICBzZWxmLm5hbWUgPSBuYW1lCgogICAgZGVmIF9fc3RyX18gKHNlbGYpOgogICAg ICAgICIiIiBgUHJpbnRzJyBvdXQgdGhlIEtlcm5lbFByb3BlcnR5IG9iamVjdCBpbiBzdHJpbmdp emVkIGZvcm0uCgogICAgICAgIFRoZSBmb3JtYXQgaXMgYXMgZm9sbG93czoKCiAgICAgICAgMS4g bmFtZQogICAgICAgIDIuIGZpbGU6bGluZSBuYW1lCiAgICAgICAgMy4gbmFtZSA9ICJkZXNjcmlw dGlvbiIKICAgICAgICA0LiBmaWxlOmxpbmUgbmFtZSA9ICJkZXNjcmlwdGlvbiIKCiAgICAgICAg VGhlIGZvcm1hdCBwcmludGVkIG91dCBhbGwgZGVwZW5kcyBvbiB0aGUgZGF0YSBwcm92aWRlZCBi eSAKICAgICAgICBwYXJzZV9rZXJuZWxfb2JqZWN0cyguLi4pLgoKICAgICAgICAiIiIKCiAgICAg ICAgIyBQcm92aWRlIHRoZSBmaWxlIC8gbGluZSBpbmZvLgogICAgICAgICMgcHlsaW50OiBkaXNh YmxlLW1zZz1FMTEwMQogICAgICAgIGlmIHNlbGYuZmlsZSBhbmQgc2VsZi5saW5lOgogICAgICAg ICAgICAjIHB5bGludDogZGlzYWJsZS1tc2c9RTExMDEKICAgICAgICAgICAgcHJlZml4ID0gJyVz OiVkOiAnICUgKHNlbGYuZmlsZSwgc2VsZi5saW5lKQogICAgICAgIGVsc2U6CiAgICAgICAgICAg IHByZWZpeCA9ICcnCgogICAgICAgICMgT21pdCB0aGUgZGVzY3JpcHRpb24uCiAgICAgICAgIyBw eWxpbnQ6IGRpc2FibGUtbXNnPUUxMTAxCiAgICAgICAgaWYgc2VsZi5kZXNjcmlwdGlvbjoKICAg ICAgICAgICAgIyBweWxpbnQ6IGRpc2FibGUtbXNnPUUxMTAxCiAgICAgICAgICAgIHN1ZmZpeCA9 ICcgPSAiJXMiJyAlIChzZWxmLmRlc2NyaXB0aW9uLCkKICAgICAgICBlbHNlOgogICAgICAgICAg ICBzdWZmaXggPSAnJwoKICAgICAgICAjIE5PVEUgKGdjb29wZXIpOiBpZiBlaXRoZXIgcHJlZml4 IG9yIHN1ZmZpeCBpcyBlbXB0eSwgdGhlcmUgd2lsbCBiZQogICAgICAgICMgbmFzdHkgaGVhZGlu ZyAvIHRyYWlsaW5nIHdoaXRlc3BhY2UuIEhlbmNlLCBJIHVzZWQgKyBjb25jYXRlbmF0aW9uCiAg ICAgICAgIyBpbnN0ZWFkIG9mICcgJy5qb2luKFsuLl0pLCBiZWNhdXNlIHRoaXMgaXMgY29uc2lk ZXJhYmx5IGNoZWFwZXIgdG8KICAgICAgICAjIGRvIHRoYW4gJyVzJXMlcycgKGFuZCBmYXIgbGVz cyBicmFpbmRlYWQpLi4uCiAgICAgICAgcmV0dXJuIHByZWZpeCArIHNlbGYubmFtZSArIHN1ZmZp eAoKY2xhc3MgU3lzY3RsKEtlcm5lbFByb3BlcnR5KToKICAgICIiIiBBIGNsYXNzIGNvcnJlc3Bv bmRpbmcgdG8gYSBrZXJuZWwgc3lzY3RsIE9JRCBwcm9wZXJ0eS4KICAgICIiIgoKY2xhc3MgVHVu YWJsZShLZXJuZWxQcm9wZXJ0eSk6CiAgICAiIiIgQSBjbGFzcyBjb3JyZXNwb25kaW5nIHRvIGEg a2VybmVsIHR1bmFibGUgb2JqZWN0LgogICAgIiIiCgpkZWYgbWFpbigpOgogICAgIiIiIE1haW4g ZnVuY3Rpb24gb2YgY291cnNlLiAiIiIKCiAgICBwYXJzZXIgPSBvcHRwYXJzZS5PcHRpb25QYXJz ZXIoKQoKICAgIHBhcnNlci5hZGRfb3B0aW9uKCctZCcsICctLXNyY2RpcicsIGRlc3Q9J3NyY2Rp cicsIGRlZmF1bHQ9Jy91c3Ivc3JjL3N5cycsCiAgICAgICAgICAgICAgICAgICAgICBoZWxwPSgn c291cmNlIGRpcmVjdG9yeSB0byBsb29rIGZvciBzeXNjdGxzIGFuZCAnCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAndHVuYWJsZXMgaW4nKSkKCiAgICAjCiAgICAjIFhYWCAoZ2Nvb3Blcik6 IHRoaXMgaXMgbW9yZSBkaWZmaWN1bHQgdG8gZG8gYXMgdGhlIGRlc2NyaXB0aW9ucwogICAgIyB0 aGVtc2VsdmVzIHNwYW4gbXVsdGlwbGUgbGluZXMuIE5lZWRsZXNzIHRvIHNheSwgaXQncyBhIE9y bGFuZG8gQmxvb20taW5nCiAgICAjIHBhcnNpbmcgbWVzcy4uLgogICAgIwogICAgI3BhcnNlci5h ZGRfb3B0aW9uKCctcycsICctLXN5c2N0bCcsIGRlc3Q9J3BhcnNlX3N5c2N0bHMnLCBkZWZhdWx0 PUZhbHNlLAogICAgIyAgICAgICAgICAgICAgICAgIGFjdGlvbj0nc3RvcmVfdHJ1ZScsCiAgICAj ICAgICAgICAgICAgICAgICAgaGVscD0nbG9vayBmb3Igc3lzY3RscyBPSURzJykKCiAgICBwYXJz ZXIuYWRkX29wdGlvbignLXQnLCAnLS10dW5hYmxlJywgZGVzdD0ncGFyc2VfdHVuYWJsZXMnLCBk ZWZhdWx0PUZhbHNlLAogICAgICAgICAgICAgICAgICAgICAgYWN0aW9uPSdzdG9yZV90cnVlJywK ICAgICAgICAgICAgICAgICAgICAgIGhlbHA9J2xvb2sgZm9yIHR1bmFibGVzJykKCiAgICBwYXJz ZXIuYWRkX29wdGlvbignLXYnLCAnLS12ZXJib3NlJywgZGVzdD0ndmVyYm9zZScsIGRlZmF1bHQ9 RmFsc2UsCiAgICAgICAgICAgICAgICAgICAgICBhY3Rpb249J3N0b3JlX3RydWUnLAogICAgICAg ICAgICAgICAgICAgICAgaGVscD0naW5jbHVkZSBmaWxlL2xpbmUgcmVzdWx0cyBmb3IgdHVuYWJs ZXMuJykKCiAgICBvcHRzLCBfXyA9IHBhcnNlci5wYXJzZV9hcmdzKCkKCiAgICBra25vYnMgPSAw CgogICAgIyBYWFggKGdhcnJjb29wKTogc3lzY3RsIHBhcnNpbmcncyBhIHBhaW4gLS0gc28gaXQn cyBkaXNhYmxlZC4uLgogICAgIyBTZWUgYWJvdmUgY29tbWVudC4KICAgIGtrbm9icyA9IFBBUlNF X1RVTkFCTEVTCiAgICAjCiAgICAjaWYgb3B0cy5wYXJzZV9zeXNjdGxzOgogICAgIyAgICBra25v YnMgfD0gUEFSU0VfU1lTQ1RMUwogICAgI2lmIG9wdHMucGFyc2VfdHVuYWJsZXM6CiAgICAjICAg IGtrbm9icyB8PSBQQVJTRV9UVU5BQkxFUwogICAgIwogICAgI2lmIG5vdCBra25vYnM6CiAgICAj ICAgIGtrbm9icyA9IFBBUlNFX1NZU0NUTFMKICAgIAogCiAgICBzeXNjdGxzLCB0dW5hYmxlcyA9 IGNvbWJfdHJlZV9mb3Jfa2VybmVsX29iamVjdHMob3B0cy5zcmNkaXIsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAga2VybmVsX2tub2JzPWtrbm9i cywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2 ZXJib3NlX2luZm89b3B0cy52ZXJib3NlLCkKCiAgICBpZiBzeXNjdGxzOgogICAgICAgIHByaW50 ICdcbicuam9pbihbICdTeXNjdGxzOicgXSArIG1hcChzdHIsIHN5c2N0bHMpKQoKICAgIGlmIHR1 bmFibGVzOgogICAgICAgIHByaW50ICdcbicuam9pbihbICdUdW5hYmxlczonIF0gKyBtYXAoc3Ry LCB0dW5hYmxlcykpCgpkZWYgY29tYl90cmVlX2Zvcl9rZXJuZWxfb2JqZWN0cyhzcmNkaXIsIGtl cm5lbF9rbm9icywgdmVyYm9zZV9pbmZvPUZhbHNlKToKICAgICIiIiBDb21iIGEgdHJlZSBsb29r aW5nIGZvciBrZXJuZWwgdHVuYWJsZXMgaW4gZmlsZXMgdW5kZXIgc3JjZGlyLgoKICAgIC0gUmV0 dXJucyBhIGxpc3Qgb2YgVHVuYWJsZSBvYmplY3RzIGZvdW5kIGluIHNyY2Rpci4KICAgIC0gVGhl IGZpbGUgYW5kIGxpbmUgbnVtYmVyIHRoZSB0dW5hYmxlIHdhcyBmb3VuZCBvbiB3aWxsIGJlIHNh dmVkIHdoZW4KICAgICAgdmVyYm9zZV9pbmZvIGlzIHNldCB0byBUcnVlLiBTZWUgdGhlIFR1bmFi bGUgY2xhc3MgZm9yIG1vcmUKICAgICAgZGV0YWlscy4KICAgICIiIgoKICAgIHN5c2N0bHMgPSBb XQogICAgdHVuYWJsZXMgPSBbXQoKICAgICMgRG9pbmcgdGhpcyBtYWtlcyByZWxwYXRoIGNvbnNp ZGVyYWJseSBzaW1wbGVyIGFuZCBjbGVhbmVyIHRoYW4gZG9pbmcgaXQKICAgICMgaW5zaWRlIHRo ZSBsb29wLgogICAgb3MuY2hkaXIoc3JjZGlyKQoKICAgIGZvciByb290LCBfXywgZmlsZXMgaW4g b3Mud2FsayhzcmNkaXIpOgoKICAgICAgICBmb3IgX2ZpbGUgaW4gZmlsZXM6CgogICAgICAgICAg ICBfZmlsZSA9IG9zLnBhdGgucmVscGF0aChvcy5wYXRoLmpvaW4ocm9vdCwgX2ZpbGUpKQogICAg ICAgICAgICBfc3lzY3RscywgX3R1bmFibGVzID0gcGFyc2Vfa2VybmVsX29iamVjdHMoX2ZpbGUs IGtlcm5lbF9rbm9icywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHZlcmJvc2VfaW5mbykKICAgICAgICAgICAgc3lzY3Rscy5leHRlbmQoX3N5 c2N0bHMpCiAgICAgICAgICAgIHR1bmFibGVzLmV4dGVuZChfdHVuYWJsZXMpCgogICAgcmV0dXJu IHN5c2N0bHMsIHR1bmFibGVzCgpkZWYgcGFyc2Vfa2VybmVsX29iamVjdHMoX2ZpbGUsIGtlcm5l bF9rbm9icywgdmVyYm9zZV9pbmZvPUZhbHNlKToKICAgICIiIiBDb21iIGEgdHJlZSBsb29raW5n IGZvciBrZXJuZWwgdHVuYWJsZXMuCgogICAgLSBSZXR1cm5zIGEgdHVwbGUgb2YgbGlzdHMgY29u dGFpbmluZyBTeXNjdGwgYW5kIFR1bmFibGUgb2JqZWN0cwogICAgICBmb3VuZCBpbiBfZmlsZS4K ICAgIC0gVGhlIGZpbGUgYW5kIGxpbmUgbnVtYmVyIHRoZSB0dW5hYmxlIHdhcyBmb3VuZCBvbiB3 aWxsIGJlIHNhdmVkIHdoZW4KICAgICAgdmVyYm9zZV9pbmZvIGlzIHNldCB0byBUcnVlLiBTZWUg dGhlIEtlcm5lbFByb3BlcnR5IGNsYXNzIGZvciBtb3JlCiAgICAgIGRldGFpbHMuCiAgICAiIiIK CiAgICBrd2FyZ3MgPSB7IH0KICAgIHN5c2N0bHMgPSBbXQogICAgdHVuYWJsZXMgPSBbXQoKICAg IHBhcnNlX3N5c2N0bHMgPSBrZXJuZWxfa25vYnMgJiBQQVJTRV9TWVNDVExTCiAgICBwYXJzZV90 dW5hYmxlcyA9IGtlcm5lbF9rbm9icyAmIFBBUlNFX1RVTkFCTEVTCgogICAgaWYgbm90IChwYXJz ZV9zeXNjdGxzIG9yIHBhcnNlX3R1bmFibGVzKToKICAgICAgICAjIE5lZWRzIHRvIGJlIGFuIGlu Y2x1c2l2ZSBvciBvZiBQQVJTRV9TWVNDVExTLCBQQVJTRV9UVU5BQkxFUywgb3IgYQogICAgICAg ICMgY29tYmluYXRpb24gb2YgdGhlIHR3byBrbm9icy4KICAgICAgICByYWlzZSBWYWx1ZUVycm9y KCdpbnZhbGlkIHZhbHVlIGZvciBrZXJuZWxfa25vYnM6ICVzJwogICAgICAgICAgICAgICAgICAg ICAgICAgJSBzdHIoa2VybmVsX2tub2JzKSkKCiAgICBpZiB2ZXJib3NlX2luZm86CiAgICAgICAg a3dhcmdzWydmaWxlJ10gPSBfZmlsZQoKICAgIGZkID0gb3BlbihfZmlsZSwgJ3InKQogICAgdHJ5 OgogICAgICAgIGxpbmVzID0gZmQucmVhZGxpbmVzKCkKICAgIGZpbmFsbHk6CiAgICAgICAgZmQu Y2xvc2UoKQoKICAgIGt3YXJnc1snbGluZSddID0gMAoKICAgIGZvciBsaW5lIGluIGxpbmVzOgoK ICAgICAgICBrd2FyZ3NbJ2xpbmUnXSArPSAxIAoKICAgICAgICBpZiBwYXJzZV90dW5hYmxlczoK ICAgICAgICAgICAgbWF0Y2ggPSBUVU5BQkxFX1JFLm1hdGNoKGxpbmUpCiAgICAgICAgZWxzZToK ICAgICAgICAgICAgbWF0Y2ggPSBOb25lCgogICAgICAgIGlmIG1hdGNoOgogICAgICAgICAgICB0 dW5hYmxlcy5hcHBlbmQoVHVuYWJsZShtYXRjaC5ncm91cCgxKSwgKiprd2FyZ3MpKQogICAgICAg IGVsaWYgcGFyc2Vfc3lzY3RsczoKICAgICAgICAgICAgbWF0Y2ggPSBTWVNDVExfUkUubWF0Y2go bGluZSkKICAgICAgICAgICAgaWYgbWF0Y2g6CiAgICAgICAgICAgICAgICBzeXNjdGxzLmFwcGVu ZChTeXNjdGwobWF0Y2guZ3JvdXAoMSksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgZGVzY3JpcHRpb249bWF0Y2guZ3JvdXAoMiksICoqa3dhcmdzKSkKCiAgICByZXR1cm4g c3lzY3RscywgdHVuYWJsZXMKCmlmIF9fbmFtZV9fID09ICdfX21haW5fXyc6CiAgICBtYWluKCkK --0016e64b970e381515047ed0dc7b-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 04:30:36 2010 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 7847E106566C for ; Fri, 5 Feb 2010 04:30:36 +0000 (UTC) (envelope-from prvs=6452eb843=MROSSI@groupwise.swin.edu.au) Received: from ip1-in.cc.swin.edu.au (ip1-in.cc.swin.edu.au [136.186.0.41]) by mx1.freebsd.org (Postfix) with ESMTP id 127308FC19 for ; Fri, 5 Feb 2010 04:30:35 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,409,1262523600"; d="scan'208,217";a="7941180" Received: from unknown (HELO groupwise.swin.edu.au) ([136.186.0.250]) by ip1-out.cc.swin.edu.au with ESMTP; 05 Feb 2010 15:19:48 +1100 Received: from smtp-MTA by groupwise.swin.edu.au with Novell_GroupWise; Fri, 05 Feb 2010 15:19:47 +1100 Message-Id: <4B6C37110200007B0000DFDA@groupwise.swin.edu.au> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 05 Feb 2010 15:19:45 +1100 From: "Mattia Rossi" To: Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 05 Feb 2010 05:39:19 +0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: HEADS UP: gone. All welcome . 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, 05 Feb 2010 04:30:36 -0000 Is somebody fixing x11/gnome-libs? It's not working since quite some time: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20100118203854/gn= ome-libs-1.4.2_13.log Mat Mattia Rossi Research and Development Engineer Centre for Advanced Internet Architectures Faculty of Information and Communication Technologies Swinburne University of Technology http://caia.swin.edu.au=20 >>> Doug Barton 01/19/10 7:54 AM >>> On 01/18/10 12:52, Erwin Lansing wrote: > On Mon, Jan 18, 2010 at 12:29:24PM -0800, Doug Barton wrote: >> Out of curiosity, was there ever an experimental pointyhat run done for >> these changes? If there was not one previously, can we do one ASAP? >> > Already started. Awesome, you guys rock! :) Doug --=20 Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 06:19:00 2010 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 83FDF1065672 for ; Fri, 5 Feb 2010 06:19:00 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4C28F8FC08 for ; Fri, 5 Feb 2010 06:19:00 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so391857qwd.7 for ; Thu, 04 Feb 2010 22:18:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.94.197 with SMTP id a5mr746330qan.5.1265350739598; Thu, 04 Feb 2010 22:18:59 -0800 (PST) X-Originating-IP: [128.95.133.162] In-Reply-To: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> References: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> Date: Thu, 4 Feb 2010 22:18:59 -0800 Message-ID: From: Rob Farmer To: Michael Proto Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 06:19:00 -0000 On Thu, Feb 4, 2010 at 5:41 PM, Michael Proto wrote: > On Thu, Feb 4, 2010 at 8:03 PM, Rob Farmer wro= te: >> Hi, >> >> I'm running current (r203336) with mail/ssmtp from ports installed >> instead of sendmail. Whenever I try to send email, I get an error that >> libutil.so.8 is not available. >> >> # periodic daily >> /libexec/ld-elf.so.1: Shared object "libutil.so.8" not found, required >> by "sendmail" >> >> # ldd /usr/sbin/sendmail >> /usr/sbin/sendmail: >> =A0 =A0 =A0 =A0libutil.so.8 =3D> not found (0x0) >> =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x800646000) >> >> I'm not sure if this is a problem with mailwrapper in the base system >> or the ssmtp port - any pointers? >> >> Thanks, >> -- >> Rob Farmer >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > > Would appear to be a problem with your base system, as both > mailwrapper and /usr/libexec/sendmail/sendmail both use libutil.so.8: > > minibsd8-dev:root/ # ldd /usr/sbin/mailwrapper > /usr/sbin/mailwrapper: > =A0 =A0 =A0 =A0libutil.so.8 =3D> /lib/libutil.so.8 (0x28083000) > =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x28090000) > > Try reinstalling libutil from /usr/src/lib/libutil perhaps? The strange thing is that I have libutil.9 and I've tried rebuilding ssmtp and world and nothing is working... I was just wondering if other people were seeing similar problems or if there's something messed up on my system. Would seem to be my system - I'll have to look around a bit more :( --=20 Rob Farmer > > > -Proto > From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 06:40:50 2010 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 A6AB6106568F for ; Fri, 5 Feb 2010 06:40:50 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6B0538FC16 for ; Fri, 5 Feb 2010 06:40:50 +0000 (UTC) Received: by qyk28 with SMTP id 28so1638180qyk.25 for ; Thu, 04 Feb 2010 22:40:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.72.94 with SMTP id l30mr733295qaj.273.1265352049543; Thu, 04 Feb 2010 22:40:49 -0800 (PST) X-Originating-IP: [128.95.102.68] In-Reply-To: References: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> Date: Thu, 4 Feb 2010 22:40:49 -0800 Message-ID: From: Rob Farmer To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michael Proto , current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 06:40:50 -0000 On Thu, Feb 4, 2010 at 10:27 PM, Xin LI wrote: > Hi, > > On Thu, Feb 4, 2010 at 10:18 PM, Rob Farmer wr= ote: >>>> # ldd /usr/sbin/sendmail >>>> /usr/sbin/sendmail: >>>> =A0 =A0 =A0 =A0libutil.so.8 =3D> not found (0x0) >>>> =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x800646000) >>>> >>>> I'm not sure if this is a problem with mailwrapper in the base system >>>> or the ssmtp port - any pointers? > [...] >>> minibsd8-dev:root/ # ldd /usr/sbin/mailwrapper >>> /usr/sbin/mailwrapper: >>> =A0 =A0 =A0 =A0libutil.so.8 =3D> /lib/libutil.so.8 (0x28083000) >>> =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x28090000) >>> >>> Try reinstalling libutil from /usr/src/lib/libutil perhaps? >> >> The strange thing is that I have libutil.9 and I've tried rebuilding >> ssmtp and world and nothing is working... I was just wondering if >> other people were seeing similar problems or if there's something >> messed up on my system. Would seem to be my system - I'll have to look >> around a bit more :( > > Try: > > rm /etc/make.conf Found it - in src.conf I have WITHOUT_MAIL=3Dtrue and that seems to prevent mailwrapper from building at all. However, it seems this option is a little buggy - shouldn't the old version have been deleted when I did make delete-old? That would have made the problem more obvious. --=20 Rob Farmer > cd /usr/src/usr.bin/mailwrapper > make cleandir > make cleandir obj depend all > sudo make install > > -- > Xin LI http://www.delphij.net > From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 06:50:25 2010 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 332A0106566B for ; Fri, 5 Feb 2010 06:50:25 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id 097DE8FC25 for ; Fri, 5 Feb 2010 06:50:24 +0000 (UTC) Received: by pzk14 with SMTP id 14so172270pzk.3 for ; Thu, 04 Feb 2010 22:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wGMT/2qlk1CCLlTlVGUV2wGzrosPOyDmOL4qnahRkLg=; b=IyLRAC5fTeR3wklRggi8xySo1HDU1B00XhJbbJZxoiGng4vkd0S3vikQacRpbWUqXF b5uY0QI43emwbj5J6uVHsugOqNof+p0mT42xLlEpkdJ/J6RQibOT7eTsYJtVyv9EQwH0 hhXj1otuHMKKHtak/MgWo7v/0NVzE+Ud0ckU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KoZ7Nk+DGCsAlV6iwIeARR6qYkE89tJUEeXKw30pvh5wYT8hu3hIW4fMyTEkEIB2HR +tjMAlT5ki49RAKBmodHOmpuKI6zG+Rre4vW9gKdedozcBIq9tMnvJ0ogX8LoIoj7Qzn 0ExWcg/oIpivj0LZnWOBMvWA2SZIfbfDldrZs= MIME-Version: 1.0 Received: by 10.114.188.23 with SMTP id l23mr1484571waf.40.1265351253560; Thu, 04 Feb 2010 22:27:33 -0800 (PST) In-Reply-To: References: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> Date: Thu, 4 Feb 2010 22:27:33 -0800 Message-ID: From: Xin LI To: Rob Farmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Proto , current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 06:50:25 -0000 Hi, On Thu, Feb 4, 2010 at 10:18 PM, Rob Farmer wrot= e: >>> # ldd /usr/sbin/sendmail >>> /usr/sbin/sendmail: >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0libutil.so.8 =3D> not found (0x0) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7 (0x800646000) >>> >>> I'm not sure if this is a problem with mailwrapper in the base system >>> or the ssmtp port - any pointers? [...] >> minibsd8-dev:root/ # ldd /usr/sbin/mailwrapper >> /usr/sbin/mailwrapper: >> =C2=A0 =C2=A0 =C2=A0 =C2=A0libutil.so.8 =3D> /lib/libutil.so.8 (0x280830= 00) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7 (0x28090000) >> >> Try reinstalling libutil from /usr/src/lib/libutil perhaps? > > The strange thing is that I have libutil.9 and I've tried rebuilding > ssmtp and world and nothing is working... I was just wondering if > other people were seeing similar problems or if there's something > messed up on my system. Would seem to be my system - I'll have to look > around a bit more :( Try: rm /etc/make.conf cd /usr/src/usr.bin/mailwrapper make cleandir make cleandir obj depend all sudo make install --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 06:51:55 2010 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 9EE7A106566B for ; Fri, 5 Feb 2010 06:51:55 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 7448E8FC13 for ; Fri, 5 Feb 2010 06:51:55 +0000 (UTC) Received: by pxi13 with SMTP id 13so739965pxi.3 for ; Thu, 04 Feb 2010 22:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Iun087i0niMByx8m+RnQ5kYIzLFrDMziyfMwDGsVwBM=; b=ElyPTjBl18dZxLtsCkzwvyoLOFWojm9zBIG+HXi1LTwk1RwqM0mMJQXb/w2V2icj+h 3wtaDEY0aDBmzP2qhmMfKWZRYujJciJRHPH5zD3Bm0KyUbr9WOMlgJu8fIzquJdMDXx4 fdrUTOepplrm5KgXraovbPHM2jccVuNGlh4HQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NxVMQcOmwcbi7F+RG71TJxjBaMoGHTMVlwNR54uYgc3wCmcfiAgQN9C+6+z+ZF5/2a 015lI1nnMkToKh9B5yiT4HjDzrBIfm7gC/+hw4CIwtQuhBSnwCPvSnSgkZDuzSIXwDMa uC6lLCE+mBILDSBm1xOEwOweXkB7vyWbCZ0o8= MIME-Version: 1.0 Received: by 10.115.98.2 with SMTP id a2mr1486920wam.150.1265352710492; Thu, 04 Feb 2010 22:51:50 -0800 (PST) In-Reply-To: References: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> Date: Thu, 4 Feb 2010 22:51:50 -0800 Message-ID: From: Xin LI To: Rob Farmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Proto , current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 06:51:55 -0000 On Thu, Feb 4, 2010 at 10:40 PM, Rob Farmer wrot= e: > On Thu, Feb 4, 2010 at 10:27 PM, Xin LI wrote: >> Hi, >> >> On Thu, Feb 4, 2010 at 10:18 PM, Rob Farmer w= rote: >>>>> # ldd /usr/sbin/sendmail >>>>> /usr/sbin/sendmail: >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0libutil.so.8 =3D> not found (0x0) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7 (0x800646000= ) >>>>> >>>>> I'm not sure if this is a problem with mailwrapper in the base system >>>>> or the ssmtp port - any pointers? >> [...] >>>> minibsd8-dev:root/ # ldd /usr/sbin/mailwrapper >>>> /usr/sbin/mailwrapper: >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0libutil.so.8 =3D> /lib/libutil.so.8 (0x2808= 3000) >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7 (0x28090000) >>>> >>>> Try reinstalling libutil from /usr/src/lib/libutil perhaps? >>> >>> The strange thing is that I have libutil.9 and I've tried rebuilding >>> ssmtp and world and nothing is working... I was just wondering if >>> other people were seeing similar problems or if there's something >>> messed up on my system. Would seem to be my system - I'll have to look >>> around a bit more :( >> >> Try: >> >> rm /etc/make.conf > > Found it - in src.conf I have WITHOUT_MAIL=3Dtrue and that seems to > prevent mailwrapper from building at all. However, it seems this > option is a little buggy - shouldn't the old version have been deleted > when I did make delete-old? That would have made the problem more > obvious. I agree, this is a bug... Could you please file a PR so it wouldn't be forgotten? If nobody works on it I'll create a patch when I have time. For those who have interest, the corresponding file is src/tools/build/mk/OptionalObsoleteFiles.inc. Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 07:00:49 2010 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 15CC5106568D for ; Fri, 5 Feb 2010 07:00:49 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id CE1008FC21 for ; Fri, 5 Feb 2010 07:00:48 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so396445qwd.7 for ; Thu, 04 Feb 2010 23:00:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.63.170 with SMTP id b42mr766862qai.39.1265353247516; Thu, 04 Feb 2010 23:00:47 -0800 (PST) X-Originating-IP: [128.95.102.68] In-Reply-To: References: <1de79841002041741q6b57b6e5s4f78542f8a1b892@mail.gmail.com> Date: Thu, 4 Feb 2010 23:00:47 -0800 Message-ID: From: Rob Farmer To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michael Proto , current@freebsd.org Subject: Re: "libutil.so.8" not found, required by "sendmail" 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, 05 Feb 2010 07:00:49 -0000 On Thu, Feb 4, 2010 at 10:51 PM, Xin LI wrote: > On Thu, Feb 4, 2010 at 10:40 PM, Rob Farmer wr= ote: >> On Thu, Feb 4, 2010 at 10:27 PM, Xin LI wrote: >>> Hi, >>> >>> On Thu, Feb 4, 2010 at 10:18 PM, Rob Farmer = wrote: >>>>>> # ldd /usr/sbin/sendmail >>>>>> /usr/sbin/sendmail: >>>>>> =A0 =A0 =A0 =A0libutil.so.8 =3D> not found (0x0) >>>>>> =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x800646000) >>>>>> >>>>>> I'm not sure if this is a problem with mailwrapper in the base syste= m >>>>>> or the ssmtp port - any pointers? >>> [...] >>>>> minibsd8-dev:root/ # ldd /usr/sbin/mailwrapper >>>>> /usr/sbin/mailwrapper: >>>>> =A0 =A0 =A0 =A0libutil.so.8 =3D> /lib/libutil.so.8 (0x28083000) >>>>> =A0 =A0 =A0 =A0libc.so.7 =3D> /lib/libc.so.7 (0x28090000) >>>>> >>>>> Try reinstalling libutil from /usr/src/lib/libutil perhaps? >>>> >>>> The strange thing is that I have libutil.9 and I've tried rebuilding >>>> ssmtp and world and nothing is working... I was just wondering if >>>> other people were seeing similar problems or if there's something >>>> messed up on my system. Would seem to be my system - I'll have to look >>>> around a bit more :( >>> >>> Try: >>> >>> rm /etc/make.conf >> >> Found it - in src.conf I have WITHOUT_MAIL=3Dtrue and that seems to >> prevent mailwrapper from building at all. However, it seems this >> option is a little buggy - shouldn't the old version have been deleted >> when I did make delete-old? That would have made the problem more >> obvious. > > I agree, this is a bug... > > Could you please file a PR so it wouldn't be forgotten? =A0If nobody > works on it I'll create a patch when I have time. > > For those who have interest, the corresponding file is > src/tools/build/mk/OptionalObsoleteFiles.inc. I've filed PR #143571. I looked at making a patch but I'm not sure what to do with /usr/sbin/sendmail - it is a symlink to mailwrapper. I'm not sure if it should be outright deleted if building without mailwrapper or if something more complex should be done to point it to the actual sendmail binary. --=20 Rob Farmer > > Cheers, > -- > Xin LI http://www.delphij.net > From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 12:45:55 2010 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 2DB021065676 for ; Fri, 5 Feb 2010 12:45:55 +0000 (UTC) (envelope-from kwm@rainbow-runner.nl) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB6F8FC1F for ; Fri, 5 Feb 2010 12:45:54 +0000 (UTC) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20100205123017.PALV27688.viefep19-int.chello.at@edge05.upcmail.net>; Fri, 5 Feb 2010 13:30:17 +0100 Received: from [192.168.0.105] ([80.56.73.45]) by edge05.upcmail.net with edge id eCWE1d05V0ydU7k05CWF1P; Fri, 05 Feb 2010 13:30:17 +0100 X-SourceIP: 80.56.73.45 From: Koop Mast To: Mattia Rossi In-Reply-To: <4B6C37110200007B0000DFDA@groupwise.swin.edu.au> References: <4B6C37110200007B0000DFDA@groupwise.swin.edu.au> Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Feb 2010 13:30:25 +0100 Message-ID: <1265373025.72297.1.camel@headache.rainbow-runner.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . 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, 05 Feb 2010 12:45:55 -0000 On Fri, 2010-02-05 at 15:19 +1100, Mattia Rossi wrote: > Is somebody fixing x11/gnome-libs? It's not working since quite some time: > > http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20100118203854/gnome-libs-1.4.2_13.log Should be fixed now, thanks -Koop > Mat > > Mattia Rossi > Research and Development Engineer > Centre for Advanced Internet Architectures > Faculty of Information and Communication Technologies > Swinburne University of Technology > http://caia.swin.edu.au > >>> Doug Barton 01/19/10 7:54 AM >>> > On 01/18/10 12:52, Erwin Lansing wrote: > > On Mon, Jan 18, 2010 at 12:29:24PM -0800, Doug Barton wrote: > >> Out of curiosity, was there ever an experimental pointyhat run done for > >> these changes? If there was not one previously, can we do one ASAP? > >> > > Already started. > > Awesome, you guys rock! :) > > > Doug > From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 14:47:06 2010 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 DCB9A1065697 for ; Fri, 5 Feb 2010 14:47:05 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE6B8FC23 for ; Fri, 5 Feb 2010 14:47:04 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o15El30i057687 for ; Fri, 5 Feb 2010 16:47:03 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B6C2F62.8070404@eng.auth.gr> Date: Fri, 05 Feb 2010 16:46:58 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kerberized NFSv3 incorrect behavior 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, 05 Feb 2010 14:47:06 -0000 Dear all, I sent this same email to freebsd-stable list as well, but I maybe had to sent it to -CURRENT since NFSv4 under fbsd is still experimental, and hence under development (and thus nvsv3-gssapi as well -I assumed-). If my assumption is wrong, please excuse me and discard this email. I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My configuration is based on http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is to share filesystems securely with gssapi support. Everything works fine, until I try to kdestroy my tickets or kinit to some other user, where the system insists to think that I am the user that initially obtained their ticket. To be more extensive, my story is as follows: nfs server: /etc/rc.conf: rpcbind_enable="YES" mountd_flags="-e" nfs_server_enable="YES" nfs_client_enable="YES" gssd_enable="YES" and the kernel is compiled with: options KGSSAPI device crypto my /etc/exports contains: /exports -alldirs -sec=krb5 nfs client: /etc/rc.conf: rpcbind_enable="YES" nfs_client_enable="YES" gssd_enable="YES" on both client and server the /etc/krb5.conf contains: [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com kpasswd_server = kdc.example.com } [domain_realm] kdc.example.com = EXAMPLE.COM .kdc.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM and both client and server have the correct entries about each other (and themselves) in their /etc/hosts, so heimdal works just fine. Both client and server have their respective keytabs stored in /etc/krb5.keytab, and I use two users in my example (that both exist in both systems with the same uid,gid): mamalos and testakis. So, when I mount the exported filesystem on the client giving: # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt # mount /dev/da0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) server.example.com:/exports on /mnt (nfs) and try to access the share: # ls /mnt ls: mnt: Permission denied I get the error I am expecting, since root does not have any kerberos tickets assigned, yet. Let's see what happens when I kinit as mamalos: # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: mamalos@EXAMPLE.COM Issued Expires Principal Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@EXAMPLE.COM # ls -la /mnt/ total 8 drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ # touch /mnt/mamalos/myfile # ls -la /mnt/mamalos/myfile rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile Which is the exact behavior that is expected. Now when I kdestroy: # kdestroy # klist klist: No ticket file: /tmp/krb5cc_0 # touch /mnt/mamalos/myfilethatshouldnotbe # ls -la /mnt/mamalos/myfilethatshouldnotbe -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 /mnt/mamalos/myfilethatshouldnotbe And I can do everything in that share as if I were still mamalos, even though I kdestroyed my kerberos ticket. The same thing will happen even if I kinit to testakis after that. klist shows testakis' ticket this time, but I am not allowed to access (rwx) tetakis' files/folders, and I still have full control over mamalos' files and folders. In order to be able to do something as testakis, I have to unmount the share and remount it while having obtained testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). I am not an NFS expert, but I suppose that this behavior is not the one to be expected, except if I am missing some fundamental information about kerberized NFS that explains it. Even so, it would be quite unwise to behave so, since even if the users kdestroys their tickets (or if the ticket has expired), they will still have all permissions as when they obtained their ticket. Thank you all in advance, looking forward to an answer, kind regards, mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 14:59:43 2010 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 35D11106566C; Fri, 5 Feb 2010 14:59:43 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id B20168FC1E; Fri, 5 Feb 2010 14:59:42 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o15Exf2i098509; Fri, 5 Feb 2010 16:59:41 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B6C3258.7050607@eng.auth.gr> Date: Fri, 05 Feb 2010 16:59:36 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Kerberized NFSv3 incorrect behavior (revisited) 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, 05 Feb 2010 14:59:43 -0000 What's more, if I obtain (as root for example) a ticket for user mamalos and kdestroy it, and then login as user root in a new terminal, the root user in the new terminal has still all privileges of mamalos in the share. Klist, of course, shows no tickets. This could be also a security threat, in case different kerberos principals (users in this setup) use a shared machine account to logon, and then access their resources by kiniting to their respective principals. I assume that this must have to do with kernel's KGSSAPI support, which "forgets" to delete or renew its kerberos' cache. Thank you all, again, for your time. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 20:08:12 2010 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 8A70C1065670; Fri, 5 Feb 2010 20:08:12 +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 296498FC26; Fri, 5 Feb 2010 20:08:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPcIbEuDaFvK/2dsb2JhbADKNggBBo1BglYIAYFzBA X-IronPort-AV: E=Sophos;i="4.49,415,1262581200"; d="scan'208";a="64417998" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2010 15:08:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 25E40109C26B; Fri, 5 Feb 2010 15:08:11 -0500 (EST) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVUf6wXzg2T5; Fri, 5 Feb 2010 15:08:10 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 8CDB1109C274; Fri, 5 Feb 2010 15:08:10 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o15KJJF18935; Fri, 5 Feb 2010 15:19:19 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Feb 2010 15:19:19 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6C3258.7050607@eng.auth.gr> Message-ID: References: <4B6C3258.7050607@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior (revisited) 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, 05 Feb 2010 20:08:12 -0000 On Fri, 5 Feb 2010, George Mamalakis wrote: > shows no tickets. This could be also a security threat, in case different > kerberos principals (users in this setup) use a shared machine account to > logon, and then access their resources by kiniting to their respective > principals. > The kernel only knows the effective uid and the current gssd assumes that there will be "one" user principal with a TGT in /tmp/krb5cc_N (where 'N' is that uid#). Having multiple principals sharing the same login/uid (which I'm guessing is what you refer to as a "shared machine account", isn't going to work. I suppose that the gssd could do a "uid"->"username"->"principal name" mapping and then use that "principal name", but it is still going to be unique (ie only one) per uid. rick From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 20:16:00 2010 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 471391065692; Fri, 5 Feb 2010 20:16:00 +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 DACF88FC16; Fri, 5 Feb 2010 20:15:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIsLbEuDaFvJ/2dsb2JhbADXeYRSBA X-IronPort-AV: E=Sophos;i="4.49,415,1262581200"; d="scan'208";a="64418903" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2010 15:15:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id F185DFB809A; Fri, 5 Feb 2010 15:15:55 -0500 (EST) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjDbRehmTmJW; Fri, 5 Feb 2010 15:15:55 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 2D3F9FB80A3; Fri, 5 Feb 2010 15:15:55 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o15KR4m19591; Fri, 5 Feb 2010 15:27:04 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Feb 2010 15:27:04 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6C3258.7050607@eng.auth.gr> Message-ID: References: <4B6C3258.7050607@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior (revisited) 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, 05 Feb 2010 20:16:00 -0000 On Fri, 5 Feb 2010, George Mamalakis wrote: > > I assume that this must have to do with kernel's KGSSAPI support, which > "forgets" to delete or renew its kerberos' cache. > Oops, missed this on the last reply. It is actually a cache of "handles" for RPCSEC_GSS credentials allocated by the server (one per uid). It is normally the server that decides to expire them (they no longer really have anything to do with Kerberos, except that they were acquired via a Kerberos ticket and it uses the session key created by Kerberos). As noted before, I believe that kdestroy should somehow invalidate these handles (it's an RPC to the NFS server + flushing the cached entry in the client). A quick and dirty hack that has kdestroy do a system call to do this could be implemented fairly easily. A key management subsystem (aka key ring) that deals with all types of authentication and not just Kerberos would be much more work. rick From owner-freebsd-current@FreeBSD.ORG Sat Feb 6 10:11:53 2010 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 D65A7106566C for ; Sat, 6 Feb 2010 10:11:53 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from outgoing.holservices.gr (outgoing.holservices.gr [62.38.2.44]) by mx1.freebsd.org (Postfix) with SMTP id 03FCD8FC13 for ; Sat, 6 Feb 2010 10:11:52 +0000 (UTC) Received: (qmail 4287 invoked from network); 6 Feb 2010 09:36:20 -0000 Received: from unknown (HELO deliver.mail.dc.hol.net) (192.168.20.70) by arete.mail.dc.hol.net with SMTP; 6 Feb 2010 09:36:20 -0000 Received: from auth-smtp.hol.gr (takeit01.mail.dc.hol.net [192.168.20.71]) by deliver.hol.gr (8.12.11/8.11.6) with ESMTP id o169j565000991 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified OK); Sat, 6 Feb 2010 11:45:05 +0200 Received: from [192.168.2.2] (ppp089210136134.dsl.hol.gr [89.210.136.134]) by auth-smtp.hol.gr (8.13.1/8.13.1) with ESMTP id o169j4ts026030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Feb 2010 11:45:05 +0200 Message-ID: <4B6D3A18.2030304@eng.auth.gr> Date: Sat, 06 Feb 2010 11:44:56 +0200 From: George Mamalakis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Rick Macklem References: <4B6BE7A2.6000402@eng.auth.gr> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/10362/Sat Feb 6 09:14:06 2010 on takeit01.mail.dc.hol.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior 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, 06 Feb 2010 10:11:53 -0000 Rick Macklem wrote: > > > On Fri, 5 Feb 2010, George Mamalakis wrote: > >> Dear all, >> >> I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My >> configuration is based on >> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My >> goal is to share filesystems securely through kerberos >> authentication. Everything works fine, until I try to kdestroy my >> tickets or kinit to some other user, where the system insists to >> think that I am the user that initially obtained their ticket. To be >> more extensive, my story is as follows: >> > [good stuff snipped] >> >> >> and both client and server have the correct entries about each other >> (and themselves) in their /etc/hosts, so heimdal works just fine. >> >> Both client and server have their respective keytabs stored in >> /etc/krb5.keytab, and I use two users in my example (that both exist >> in both systems with the same uid,gid): mamalos and testakis. >> > > Unless you have applied the experimental patch, a keytab entry is > meaningless in the client. Without that, it was assumed that "root" > would never "kinit" as anyone. Basically, it was assumed that "root" > would only do the mount and a user, like "mamalos" or "testakis" > would be logged in and kinit'd as that user. > > The short answer is that any principal with TGT in the credentials > cache for uid==N will be used to authenticate that user. Once > authenticated, that "handle" for the user can be used until it > expires (up to the server, but usually set to when the TGT that > it found in the credential cache is due to expire). > >> So, when I mount the exported filesystem on the client giving: >> >> # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt >> # mount >> /dev/da0s1a on / (ufs, local, soft-updates) >> devfs on /dev (devfs, local, multilabel) >> server.example.com:/exports on /mnt (nfs) >> >> and try to access the share: >> # ls /mnt >> ls: mnt: Permission denied >> >> I get the error I am expecting, since root does not have any kerberos >> tickets assigned, yet. Let's see what happens when I kinit as mamalos: > > Yep, as expected. >> # klist >> Credentials cache: FILE:/tmp/krb5cc_0 >> Principal: mamalos@EXAMPLE.COM >> >> Issued Expires Principal >> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@EXAMPLE.COM >> # ls -la /mnt/ >> total 8 >> drwxr-xr-x 4 root wheel - 512 4 Feb 19:03 ./ >> drwxr-xr-x 21 root wheel - 512 3 Feb 11:27 ../ >> drwx------ 2 mamalos wheel - 512 5 Feb 11:11 mamalos/ >> drwx------ 2 testakis wheel - 512 4 Feb 19:06 testakis/ >> # touch /mnt/mamalos/myfile >> # ls -la /mnt/mamalos/myfile >> rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:22 /mnt/mamalos/myfile >> >> Which is the exact behavior that is expected. Now when I kdestroy: >> # kdestroy >> # klist >> klist: No ticket file: /tmp/krb5cc_0 >> # touch /mnt/mamalos/myfilethatshouldnotbe >> # ls -la /mnt/mamalos/myfilethatshouldnotbe >> -rw-r--r-- 1 mamalos wheel - 0 5 Feb 11:24 >> /mnt/mamalos/myfilethatshouldnotbe >> > > Yes, this is a "bug/limitation" in the current implementation. I believe > that "kdestroy" should do some sort of system call to inform the NFS > client that "credentials for uid==N" should be invalidated. This is not > implemented in FreeBSD8 (or Linux for that matter, last I checked). > I don't know if dfr@ was planning on doing this and whether or not he > thinks it is appropriate to do so? > > Without that implemented, the "handle" continues to work until the > server expires it, normally when the TGT for "mamalos" would have > expired if you hadn't kdestroy'd it. > >> And I can do everything in that share as if I were still mamalos, >> even though I kdestroyed my kerberos ticket. The same thing will >> happen even if I kinit to testakis after that. klist shows testakis' >> ticket this time, but I am not allowed to access (rwx) tetakis' >> files/folders, and I still have full control over mamalos' files and >> folders. >> >> In order to be able to do something as testakis, I have to unmount >> the share and remount it while having testakis' ticket (or having no >> ticket at all, and giving kinit testakis after mounting the share). >> > > Actually, logging in as "testakis" should allow that user to access the > mount as "testakis" once kinit'd as "testakis". The trick is that the > credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the > uid assigned to "testakis"). Same would apply to "mamalos" if that > user were logged in with a non-0 uid. > >> I am not an NFS expert, but I suppose that this behavior is not the >> one to be expected, except if I am missing some fundamental >> information about kerberized NFS that explains it. Even so, it would >> be quite unwise to behave so, since even if the users kdestroys their >> tickets, they have still all permissions as when they obtained their >> ticket. >> > > Yes, as noted above, I believe that "kdestroy" should get rid of the > Kerberized NFS "handles" for the corresponding "uid". It's on my > "to discuss with dfr and maybe do" list, but unfortunately not near > the top of it. (I'd also like to come up with a good way to do > initiator credentials from a keytab entry. The experimental patch > is considered unacceptable for FreeBSD-current etc.) > > Hope that clarifies things, rick > > _______________________________________________ > 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" > Rick, thank you for all your answers. I am planning on setting up the computer labs of my department using kerberized nfsv3 (since v4 seems to be "more" experimental) with a FreeBSD nfs server and Linux nfs clients. I was wondering "how stable" such an implementation would be; meaning that I wouldn't want to end up with an unstsable setup when receiving requests from 50-60 simultaneous clients, because that would be my everyday scenario. Thanks again for all your explanations (you covered me fully) and for your understanding of my remarks. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-current@FreeBSD.ORG Sat Feb 6 12:54:10 2010 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 517551065679 for ; Sat, 6 Feb 2010 12:54:10 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 06D6E8FC17 for ; Sat, 6 Feb 2010 12:54:09 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id C1A8614DA57E for ; Sat, 6 Feb 2010 13:54:07 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WphmxhEZTsct for ; Sat, 6 Feb 2010 13:53:58 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 10D2214DA56A for ; Sat, 6 Feb 2010 13:53:57 +0100 (CET) Message-ID: <4B6D6663.4070905@FreeBSD.org> Date: Sat, 06 Feb 2010 13:53:55 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4B57780F.4070907@FreeBSD.org> <4B6970F8.2030807@FreeBSD.org> <90a5caac1002040231i13c2b47mc733947a767d3488@mail.gmail.com> <4B6ACA37.3060807@FreeBSD.org> <4B6AF30B.4040204@bellanet.org> In-Reply-To: <4B6AF30B.4040204@bellanet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: HEADSUP: BSDL bc/dc in head 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, 06 Feb 2010 12:54:10 -0000 El 2010. 02. 04. 17:17, Graham Todd escribió: > Hi, sorry to be OT. If libedit can be swapped for libreadline in the BSDL > bc is it possible to swap them elsewhere? Of course kgdb gdb et al. will > always be linked against libreadline but there were a few other tools > people seemed surprised to find linked against readline. Under > /usr/[s]bin: ntpdc, ntpq, kadmin, ktutil and under /sbin/: gvinum (?!). > > See this thread: > http://lists.freebsd.org/pipermail/freebsd-current/2009-February/002877.html > > The gvinum code seems like it would be more work but perhaps for someone > familiar with libedit/libreadline issues ntpdc ntpq would be "low hanging > fruit". > > A while back I was frequently building heimdal 1.1 from source, somehow > linking against libedit (I assumed this was correct since I had not > noticed the base heimdal tools were linked against libreadline). > Everything worked fine with -ledit instead of -lreadline as far as I could > tell. Under 8.0 heimdal in base has changed but it is still linked against > readline even though the line editing prompt for kadmin seems fairly basic > and libedit seems to work (BTW does ktutil even provide a line editing > prompt?). There's probably good reasons for this but *perhaps* for > kadmin/ktutil the fruit is not low hanging but already in the basket :) > Probably, the problem is just nobody has taken care of these yet. I'd be interested later if noone solves these before. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org