From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 00:05:31 2008 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 94C9816A417 for ; Sun, 17 Feb 2008 00:05:31 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 41DE313C45B for ; Sun, 17 Feb 2008 00:05:31 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (p54A7C757.dip.t-dialin.net [84.167.199.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id A0D8C405478; Sun, 17 Feb 2008 01:05:29 +0100 (CET) Message-ID: <47B77A3C.7040504@bsdforen.de> Date: Sun, 17 Feb 2008 01:05:16 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <47B69A0A.9030309@web.de> <1203167719.821.91.camel@RabbitsDen> In-Reply-To: <1203167719.821.91.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: remaining problems with RELENG_7 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, 17 Feb 2008 00:05:31 -0000 Alexandre "Sunny" Kovalenko wrote: > On Sat, 2008-02-16 at 09:08 +0100, Dominic Fandrey wrote: >> There are 2 problems bugging me some time now, in RELENG_7. The first one is >> a regression: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=119973 >> The snd_maestro Module only works properly after reloading it. Very strange. >> >> >> The other one might be a bug in Xorg or not. X entirely freezes when using >> /dev/sysmouse as mouse device. Only when the mouse moves, does X react to >> anything. Only the CTRL-ALT-FN events or CTRL-ALT-BACKSPACE have any effect >> after moving the mouse. It's entirely unusuable this way. This problem >> existed on my Thinkpad before it burst into flame and it also exists on my >> new HP notebook. >> It also used to exist on my desktop, but it disappeared a couple of months ago. >> >> Without moused dynamically plugging in mouses using USB is not possible. So >> for notebook users this is very annoying. > > Seems to be working fine here: ThinkPad X60, RELENG_7 as of late night > (EST) February 15th, xorg-server-1.4_4,1, xf86-input-mouse-1.2.3. > > RabbitsDen# grep mouse xorg.conf > Driver "mouse" > Option "Device" "/dev/sysmouse" > RabbitsDen# > > I am using built-in stick and Logitech VX Revolution mouse. > > If you'd like to compare anything else, please, let me know. Synaptics Touchpad and a Logitech Mouse with a name that cannot be deciphered any more. When I'm at home I also use a Razer Boomslang 2000. It seems my original post was sent through the wrong Account. From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 02:26:51 2008 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 4542216A419 for ; Sun, 17 Feb 2008 02:26:51 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 1226E13C44B for ; Sun, 17 Feb 2008 02:26:50 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 18266 invoked from network); 17 Feb 2008 02:26:50 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Feb 2008 02:26:50 -0000 Message-ID: <47B79A48.1030406@chuckr.org> Date: Sat, 16 Feb 2008 21:22:00 -0500 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Alexander Leidinger References: <47B20739.1050602@chuckr.org> <20080216121241.450ff175@deskjail> In-Reply-To: <20080216121241.450ff175@deskjail> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: about usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 02:26:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Leidinger wrote: > Quoting Chuck Robey (Tue, 12 Feb 2008 15:53:13 -0500): > >> But, I guess there's been a lot of coding in usb, because the state of usb >> docs is, well, mostly missing in action. I found about a conf file in /etc >> called usbd.conf, but I would guess that's a goner too (although this is a >> recently installed machine, so it shouldn't be too chock full of ancient >> memorabilia. > > cd /usr/src > make check-old > make delete-old > make delte-old-libs (make sure you don't need them anymore) > >> The handbook, both the regular version AND the developer version, treat usb >> only from the direction of masss storage. Once I get to the point of >> understanding this data dump I have (and that won't bee all that long) I >> need more into about how to architecturally amke this work. Questions >> like, does this item need to operate alone, or along with my current >> trackball? If I write a device driver for this, what kind of interface >> should I present at /dev? If I get this done, will I just enter some > > You could ask hps@FreeBSD.org, he is working on a new USB stack in > perforce. > > Bye, > Alexander. > Are you sure you got that name right? finger hps@freebsd.org comes back "no such user". I'm sorry to hear that I need now to learn yet another vcs, but I have to admit that if I must, well, Perforce is probably the best candidate for being a good tool. I just really dislike using a non-free tool for a free project (yes, I know there's a loophole for the FreeBSD project). I am still having a miserable time trying to figure out the HID spec, and Kai Wang deserves being nominated for Sainthood, for putting up with my horde of stupid questions. If anyone knows of a HID device which has a published [HID report in hex, Parsed output, and comments on how it got from one to the other] I would give nearly anything for such a thing (anything I happen to have, which doesn't happen to include cash right now). Kai Wang's krepdump gives you the hexdump and parsed output of any device in your system that gets plugged in, which is 2/3 of what I need, and anyone who hasn't seen that tool, who does usb programming, is missing a great tool. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHt5pIz62J6PPcoOkRAjrlAKCRs23A2Ql3JX8NzEz4Ei/fwnTb2QCfQYvN RkrzaoSuetczmKpdsAeV3s0= =lD7S -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 04:32:09 2008 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 204FC16A41A for ; Sun, 17 Feb 2008 04:32:09 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from mail02.kgt.co.jp (dmz02.kgt.co.jp [210.141.246.82]) by mx1.freebsd.org (Postfix) with ESMTP id B381813C459 for ; Sun, 17 Feb 2008 04:32:08 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from navgw.tt.kgt.co.jp (unknown [210.141.246.71]) by mail02.kgt.co.jp (Postfix) with ESMTP id 06A5D3C3D7BA for ; Sun, 17 Feb 2008 13:18:02 +0900 (JST) Received: from localhost (posh.tt.kgt.co.jp [192.168.15.51]) by navgw.tt.kgt.co.jp (Postfix) with ESMTP id B05C647711 for ; Sun, 17 Feb 2008 13:18:01 +0900 (JST) Date: Sun, 17 Feb 2008 13:16:00 +0900 (JST) Message-Id: <20080217.131600.57967065.haro@kgt.co.jp> To: freebsd-current@freebsd.org From: haro@kgt.co.jp X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 7 LOR with resent -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: Sun, 17 Feb 2008 04:32:09 -0000 Hi all, As I've seen few reports regarding new LORs with resent -current, I checked my notebook and found 7 LOR in one session. ;-) Some are old well known, but mostly are fairly new. This is from -current of few days old. Regards, Haro NO.1-------------------------------------------------------------------------- lock order reversal: 1st 0xc3764e28 devfs (devfs) @ kern/vfs_subr.c:2061 2nd 0xc3858214 devfsmount (devfsmount) @ fs/devfs/devfs_vnops.c:201 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,db28cbbc,c05cdcce,c07eeb62,c3858214,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c3858214,c07e03db,c07e03db,c07e0425,...) at kdb_backtrace+0x29 witness_checkorder(c3858214,9,c07e041c,c9,c7,...) at witness_checkorder+0x6de _sx_xlock(c3858214,0,c07e041c,c9,c3858214,...) at _sx_xlock+0x7d devfs_allocv(c3855e80,c385e000,db28cc28,c34c5cc0,c07f4876,...) at devfs_allocv+0x144 devfs_root(c385e000,2,c08d1b18,c34c5cc0,ca,...) at devfs_root+0x51 set_rootvnode(c08d1b00,0,c07f486d,5ed,c060a6c0,...) at set_rootvnode+0x2b vfs_mountroot(c087fb10,4,c07e47f4,260,c34c7cb0,...) at vfs_mountroot+0x356 start_init(0,db28cd38,c07e60e3,30c,c34c3ab0,...) at start_init+0x65 fork_exit(c055db20,0,db28cd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdb28cd70, ebp = 0 --- NO.2-------------------------------------------------------------------------- lock order reversal: 1st 0xc37649e8 ufs (ufs) @ kern/vfs_subr.c:2061 2nd 0xc385e000 vfslock (vfslock) @ kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,db28c9dc,c05cdcce,c07eeb62,c385e000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c385e000,c07f4967,c07f4967,c07f4eff,...) at kdb_backtrace+0x29 witness_checkorder(c385e000,1,c07f4ef6,16c,db28ca1c,...) at witness_checkorder+0x6de _lockmgr(c385e000,2001,c385e030,c07f4ef6,16c,...) at _lockmgr+0x1e5 vfs_busy(c385e000,0,0,c34c5cc0,db28cb50,...) at vfs_busy+0x198 lookup(db28cb3c,c07f461f,c6,bf,c34ae12c,...) at lookup+0x7b4 namei(db28cb3c,c34c5d54,c083e3c4,c07f4876,c385e030,...) at namei+0x34b kern_unlink(c34c5cc0,c07f4c98,1,628,0,...) at kern_unlink+0x40 vfs_mountroot_try(c07f4e52,c07e3520,c07de539,1,c060a6c0,...) at vfs_mountroot_try+0x480 vfs_mountroot(c087fb10,4,c07e47f4,260,c34c7cb0,...) at vfs_mountroot+0x418 start_init(0,db28cd38,c07e60e3,30c,c34c3ab0,...) at start_init+0x65 fork_exit(c055db20,0,db28cd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdb28cd70, ebp = 0 --- NO.3-------------------------------------------------------------------------- lock order reversal: 1st 0xc34c9044 user map (user map) @ vm/vm_map.c:3111 2nd 0xc37647c8 ufs (ufs) @ kern/vfs_subr.c:2061 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,db28c9d0,c05cdcce,c07eeb62,c37647c8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c37647c8,c07e3db7,c07e3db7,c07f4eff,...) at kdb_backtrace+0x29 witness_checkorder(c37647c8,1,c07f4ef6,80d,db28ca04,...) at witness_checkorder+0x6de _lockmgr(c37647c8,3041,c37647f8,c07f4ef6,80d,...) at _lockmgr+0x1e5 ffs_lock(db28ca78,c0586f2d,c088acf4,3041,c3764770,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0852740,db28ca78,c07e351e,3,c37647f8,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c3764770,3041,c07f4ef6,80d,0,...) at _vn_lock+0xf2 vget(c3764770,3041,c34c5cc0,4a9,c1060600,...) at vget+0x109 vnode_pager_lock(c1060480,0,c0808039,127,db28cbe8,...) at vnode_pager_lock+0x1ad vm_fault(c34c9000,80d3000,2,8,80d3800,...) at vm_fault+0x1df trap_pfault(5,0,c081452a,2c8,c34c3ab0,...) at trap_pfault+0x118 trap(db28cd38) at trap+0x267 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- NO.4-------------------------------------------------------------------------- lock order reversal: 1st 0xc38b0d18 msdosfs (msdosfs) @ kern/vfs_subr.c:2061 2nd 0xc385d7d4 vfslock (vfslock) @ kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,de991a24,c05cdcce,c07eeb62,c385d7d4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c385d7d4,c07f4967,c07f4967,c07f4eff,...) at kdb_backtrace+0x29 witness_checkorder(c385d7d4,1,c07f4ef6,16c,de991a64,...) at witness_checkorder+0x6de _lockmgr(c385d7d4,2001,c385d804,c07f4ef6,16c,...) at _lockmgr+0x1e5 vfs_busy(c385d7d4,10,0,c3882220,8,...) at vfs_busy+0x198 vfs_donmount(810e080,c,de991c70,c394f280,810b6a0,...) at vfs_donmount+0xdb5 nmount(c3882220,de991cfc,c,c07ef80c,c083a150,...) at nmount+0xb2 syscall(de991d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280d6f1b, esp = 0xbfbfe95c, ebp = 0xbfbfedb8 --- NO.5-------------------------------------------------------------------------- lock order reversal: 1st 0xc392daf8 pseudofs (pseudofs) @ kern/vfs_subr.c:2061 2nd 0xc385d000 vfslock (vfslock) @ kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,de991a24,c05cdcce,c07eeb62,c385d000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c385d000,c07f4967,c07f4967,c07f4eff,...) at kdb_backtrace+0x29 witness_checkorder(c385d000,1,c07f4ef6,16c,de991a64,...) at witness_checkorder+0x6de _lockmgr(c385d000,2001,c385d030,c07f4ef6,16c,...) at _lockmgr+0x1e5 vfs_busy(c385d000,10,0,c3882220,8,...) at vfs_busy+0x198 vfs_donmount(810e080,c,de991c70,c394fa80,810bc28,...) at vfs_donmount+0xdb5 nmount(c3882220,de991cfc,c,c07ef80c,c083a150,...) at nmount+0xb2 syscall(de991d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280d6f1b, esp = 0xbfbfe95c, ebp = 0xbfbfedb8 --- NO.6-------------------------------------------------------------------------- lock order reversal: 1st 0xc35d100c ieee80211com (802.11 com lock) @ net80211/ieee80211_scan.c:524 2nd 0xc35d2418 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1907 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,dcbc6a48,c05cdcce,c07eeb62,c35d2418,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c35d2418,c35c4200,c09c3e3e,c09c382a,...) at kdb_backtrace+0x29 witness_checkorder(c35d2418,9,c09c382a,773,c0586f2d,...) at witness_checkorder+0x6de _mtx_lock_flags(c35d2418,0,c09c382a,773,c34c5660,...) at _mtx_lock_flags+0xbc iwi_start(c35b1400,c35d21c8,dcbc6b84,c06575d8,c35b1400,...) at iwi_start+0xae if_start(c35b1400,0,c07f9a94,184,dcbc6b68,...) at if_start+0x59 ieee80211_send_nulldata(c398e000,38,c07ee23f,6cf,c35d100c) at ieee80211_send_nulldata+0x1f8 ieee80211_sta_pwrsave(c35d1004,1,20c,c392f300,c356b000,...) at ieee80211_sta_pwrsave+0x212 scan_restart(c356b000,c35d1004,c07fa5c9,20c,0,...) at scan_restart+0x96 ieee80211_bg_scan(c35d1004,0,c07fa8fd,44f,c34c5660,...) at ieee80211_bg_scan+0x10f sta_age(c356b000,dcbc6c80,c0654377,c35d1004,dcbc6c64,...) at sta_age+0x345 ieee80211_scan_timeout(c35d1004,dcbc6c64,80246,c08802a4,dcbc6c80,...) at ieee80211_scan_timeout+0x1c ieee80211_node_timeout(c35d1004,0,c07eaca2,f4,16,...) at ieee80211_node_timeout+0x17 softclock(0,0,c07e6363,46f,c34c11e4,...) at softclock+0x25d ithread_loop(c34c2630,dcbc6d38,c07e60e3,30c,c34c3558,...) at ithread_loop+0x1b5 fork_exit(c05765d0,c34c2630,dcbc6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdcbc6d70, ebp = 0 --- NO.7-------------------------------------------------------------------------- lock order reversal: 1st 0xc456f168 ufs (ufs) @ kern/vfs_subr.c:2061 2nd 0xd290fa90 bufwait (bufwait) @ sys/buf.h:280 3rd 0xc3fea5a8 ufs (ufs) @ kern/vfs_subr.c:2061 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,deb4e4e0,c05cdcce,c07eeb7b,c3fea5a8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb7b,c3fea5a8,c07e3db7,c07e3db7,c07f4eff,...) at kdb_backtrace+0x29 witness_checkorder(c3fea5a8,9,c07f4ef6,80d,c088acf4,...) at witness_checkorder+0x6de _lockmgr(c3fea5a8,2002,c3fea5d8,c07f4ef6,80d,...) at _lockmgr+0x509 ffs_lock(deb4e588,c0586f2d,c088acf4,2002,c3fea550,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0852740,deb4e588,c07e351e,3,c3fea5d8,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c3fea550,2002,c07f4ef6,80d,0,...) at _vn_lock+0xf2 vget(c3fea550,2002,c4335440,50,0,...) at vget+0x109 vfs_hash_get(c385d538,b80f,2,c4335440,deb4e6e4,...) at vfs_hash_get+0xe3 ffs_vget(c385d538,b80f,2,deb4e6e4,c080656a,...) at ffs_vget+0x49 softdep_sync_metadata(c456f110,0,c0806561,12f,118,...) at softdep_sync_metadata+0x5b2 ffs_syncvnode(c456f110,1,c1074808,8d6,c0807810,...) at ffs_syncvnode+0x3e2 ffs_truncate(c456f110,200,0,880,c3c30b00,...) at ffs_truncate+0x5fa ufs_direnter(c456f110,c3fea550,deb4ea24,deb4ebcc,d286b484,...) at ufs_direnter+0x923 ufs_mkdir(deb4eb90,deb4eb90,0,deb4eb90,deb4eba4,...) at ufs_mkdir+0x8d8 VOP_MKDIR_APV(c0852740,deb4eb90,d3d,d3b,0,...) at VOP_MKDIR_APV+0xa5 kern_mkdir(c4335440,bfbfe3c5,0,1ff,deb4ed2c,...) at kern_mkdir+0x2b7 mkdir(c4335440,deb4ecfc,8,c07ef334,c0838aa0,...) at mkdir+0x29 syscall(deb4ed38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x28149aeb, esp = 0xbfbfe11c, ebp = 0xbfbfe1e8 --- NO.8-------------------------------------------------------------------------- lock order reversal: 1st 0xc385d000 vfslock (vfslock) @ kern/vfs_mount.c:1242 2nd 0xc392d9e8 syncer (syncer) @ kern/vfs_subr.c:2156 KDB: stack backtrace: db_trace_self_wrapper(c07ec741,db28cae8,c05cdcce,c07eeb62,c392d9e8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07eeb62,c392d9e8,c07f5777,c07f5777,c07f4eff,...) at kdb_backtrace+0x29 witness_checkorder(c392d9e8,9,c07f4ef6,86c,0,...) at witness_checkorder+0x6de _lockmgr(c392d9e8,2002,c392da18,c07f4ef6,86c,...) at _lockmgr+0x509 vop_stdlock(db28cb7c,c07f4eff,c05cd598,2002,c392d990,...) at vop_stdlock+0x39 VOP_LOCK1_APV(c0847c20,db28cb7c,84f,db28cb9c,c392da18,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c392d990,2002,c07f4ef6,86c,0,...) at _vn_lock+0xf2 vrele(c392d990,0,c07f486d,4f0,4da,...) at vrele+0x142 dounmount(c385d000,80000,c34c5cc0,d28626ac,0,...) at dounmount+0x372 vfs_unmountall(c080b007,0,c07e98ff,127,0,...) at vfs_unmountall+0x4e boot(c087fb10,0,c07e98ff,ab,db28cd2c,...) at boot+0x44f reboot(c34c5cc0,db28ccfc,4,c07efc46,c0838308,...) at reboot+0x4b syscall(db28cd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- =----------------------------------------------------------------------- _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 06:31:27 2008 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 2A3FA16A46B for ; Sun, 17 Feb 2008 06:31:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0482313C442 for ; Sun, 17 Feb 2008 06:31:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2096329waf.3 for ; Sat, 16 Feb 2008 22:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=43Y+Vgzv/lPHtt359CweIuOW496A7MAe5LTHChfHcMo=; b=rpcXKkbcW5zVRw6+poVegrthrpZheB9nbNDnWJNBYhn8+oqKSFgq98iRYgIJ6qUdf+g/hXbIhl0tQhas2dTKgKBqzY6/rX4B88qqJkpXg4fEaiD57zGFXWl3YaD8fXHwW5drVWCYLpQWty6mxjcnHL/DW4S5w5H+7rI0oUhNBI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=exPR08HjjTUjk6opQVpiRzs5MOmXsDXK7HxUuOoxhVfhHUhSHCndh5MrIKKYPF3QvkD3Jrd2vYi2XcITT7BIr4dV6WPRzZLjcwOSIw395BKq8KTgHxMecsTQGyEE5EtHeYEdJp3cNNC3uH8IFVF3kQGjtitwamqYkJ+7wccDUEo= Received: by 10.142.141.21 with SMTP id o21mr3443881wfd.102.1203229886561; Sat, 16 Feb 2008 22:31:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 22sm14336522wfi.12.2008.02.16.22.31.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Feb 2008 22:31:25 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1H6VKo1011394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 15:31:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1H6VJl7011393; Sun, 17 Feb 2008 15:31:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 17 Feb 2008 15:31:19 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20080217063119.GA10866@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <200802051540.01916.freebsd-current@dino.sk> <20080211060915.GI2317@cdnetworks.co.kr> <200802161949.02217.freebsd-current@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802161949.02217.freebsd-current@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 06:31:27 -0000 On Sat, Feb 16, 2008 at 07:49:01PM +0100, Milan Obuch wrote: > On Monday 11 February 2008, Pyun YongHyeon wrote: > > On Tue, Feb 05, 2008 at 03:40:01PM +0100, Milan Obuch wrote: > > > On Monday 04 February 2008, Pyun YongHyeon wrote: > > [snip] > > > > > > > Hi, > > > > > > did anybody test Routerboard 44? It is quad network card, uses VT6105M > > > chips as network controller (Via) and PCI6152 as PCI-PCI bridge (PLX > > > Technology). With both stock if_vr and modified from site given above it > > > partially works - interfaces are created, ifconfig works, but even > > > pinging some host in local network (I achieve the effect with ping -f in > > > a minue or so) hangs system. Nothing on my console, nothing in system > > > log. Only hard powerdown restores system in functioning state. > > > > > > I tested it with stock vr driver in both 6 and 7 stable on both i386 and > > > amd64, and now with overhauled vr in 8 freshly cvsupped and two files > > > replaced on i386. > > > > > > If anybody has any idea or some patches I could test, I will. > > > > I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. > > Does this also happen on other network interface too? > > When the system hangs, would you break into DDB and show me > > the output of 'show alllocks' and 'ps'? > > > > I need some tests with another box. I was not able to break into DDB. > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did not > invoke DDB. I do not feel if_vr is culprit here, more probably PCI bus got > somehow locked, but I have no idea how could I test it currently. > Serial console may work better for this situation. In order to rule out vr(4) you may have to try another network card on your box. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 06:42:03 2008 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 DF8F016A473 for ; Sun, 17 Feb 2008 06:42:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id B9A7713C461 for ; Sun, 17 Feb 2008 06:42:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2100108waf.3 for ; Sat, 16 Feb 2008 22:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=659DAyZ+47DPDDtGa5X6thlb56myhLDU/Qw5Z4uTS8A=; b=nH+FrJx5Xomj08Z+q3FVYz/+7wompMJNdTLlePgkyECO3UkyFivMBKp8/exLFEr06KgCWPnZ9JYaE8fsotbNv3QJd/NNsZkrXks1gMDdjgaSLLmmvIE0jcsYO3otA9tHuZp2IHeE9CDamjKYt1Og2FkbC+xu+KFyOpYd0IHKINg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=UgshepMuFjyc75rkOV3nlMb5sJLxpa5Sp/ujjHDg+0VuJn1eAkihlWWmddnDzTL5t7AjlpzVmHk3LnSggVyjnx/AIg/5AY3u2ZarZ01AVuN7QZvo4LOKv07YK5KBENVi09VFtRI9dNim0+tRBW5qHH/tL1HA/AcRCT5M/ttqFPY= Received: by 10.142.241.10 with SMTP id o10mr3459795wfh.27.1203230522454; Sat, 16 Feb 2008 22:42:02 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 22sm14321711wfg.15.2008.02.16.22.42.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Feb 2008 22:42:01 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1H6fuTm011436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 15:41:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1H6ftmR011435; Sun, 17 Feb 2008 15:41:55 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 17 Feb 2008 15:41:55 +0900 From: Pyun YongHyeon To: Mike Tancsa Message-ID: <20080217064155.GB10866@cdnetworks.co.kr> References: <20071008061758.GF46694@cdnetworks.co.kr> <200802160638.m1G6cSX1088707@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802160638.m1G6cSX1088707@lava.sentex.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 06:42:04 -0000 On Sat, Feb 16, 2008 at 01:38:46AM -0500, Mike Tancsa wrote: > At 01:17 AM 10/8/2007, Pyun YongHyeon wrote: > >It seems that there had been several stability issues in vr(4). > >Here is mimimal patch that make vr(4) work reliably under heavy > >network loads. The patch does the following: > > - Always check writability of mbuf before padding and make a > > writable copy of the mbuf if mbuf is marked as read-only. > > - Before padding is done check remaining bytes such that it can > > safely extend buffer size of the mbuf. > > - Before padding always check the return value of m_defrag(9). > > - Zero out pad space to avoid leaking data. > > > >If you have vr(4) hardware please give it spin and let me know > >the result. > > Its been working quite well on 3 Soekris 5501 boards! It would be > great to see these fixes committed. > I'll commit it in a week. Thanks a lot for your time/testing! -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 06:51:24 2008 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 C85A316A41A for ; Sun, 17 Feb 2008 06:51:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id A401C13C45A for ; Sun, 17 Feb 2008 06:51:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2103279waf.3 for ; Sat, 16 Feb 2008 22:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=5IpZdcAY0Z+MHohRkwYp1vwlw2S3VOsj2ZzLjmR3ICQ=; b=GxsbrZaD8SkSS/HRUMz87TyFCb3zmHP9Mut0HVvN12cjtQenkzSS3EwkJSY7rgzGLSwBMn158G/RbbNhItkhKC1IALTh0qwsI/dxrtTQpmBUfjndyTW9o7qixWAgRsDDphMxwEqTHyuMW5WlRJCXEj6HQHdkY6zKHsWWBLXDZfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=rou109XE90IeVSb2jGLpocY94xqYmoek6NOkzH0H7fTlhWJ7XzhBlG7QTVJ/hTq7YhXm9P7X8H2+R7zTSa/x3RFJsT8zn3vlykYZwOqZOuE7eVFI+b83vbZxOG6f/2IuDewGkC/ydcMDdEfvpOKlZErzZ2gp+2+olAMUvqi9XOY= Received: by 10.142.131.18 with SMTP id e18mr3468914wfd.36.1203231084339; Sat, 16 Feb 2008 22:51:24 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm14366814wff.11.2008.02.16.22.51.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Feb 2008 22:51:23 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1H6pJkj011485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 15:51:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1H6pI9k011484; Sun, 17 Feb 2008 15:51:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 17 Feb 2008 15:51:18 +0900 From: Pyun YongHyeon To: Marcin Wisnicki Message-ID: <20080217065118.GA11464@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <200802041545.m14FjpVn014969@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 06:51:24 -0000 On Sun, Feb 10, 2008 at 03:59:16PM +0000, Marcin Wisnicki wrote: > On Mon, 04 Feb 2008 17:47:44 +0000, Marcin Wisnicki wrote: > > > I'm not 100% sure if this is all that is required for RELENG6, but it > > works wonderfully so far. > > > > Even fixed Rx errors I was seeing for some time and didn't have the time > > to investigate whether they were caused by some recent commit to releng6 > > (like the last mfc) or simply a hardware failure. > > > > Thank you Pyun YongHyeon! > > > >>From my dmesg: > > vr0: port 0xd800-0xd8ff mem > > 0xdffefd00-0xdffefdff irq 5 at device 18.0 on pci0 vr0: Quirks: 0x0 > > vr0: Revision: 0x74 > > miibus1: on vr0 > > ukphy0: on miibus1 ukphy0: > > 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet > > address: 42:00:e6:65:9b:11 vr0: [GIANT-LOCKED] > > > > Just noticed in dmesg after reboot: > > vr0: Tx underrun -- increasing Tx threshold(128 -> 256) > vr0: Tx underrun -- increasing Tx threshold(256 -> 512) > vr0: Tx underrun -- increasing Tx threshold(512 -> 1024) > vr0: Tx underrun -- using store and forward mode > vr0: Tx underrun -- > > at this moment I started copying files in and out using samba > and then last message started to repeat for some time with decreasing > frequency until finally: > > vr0: watchdog timeout > Since you're the only user that reported Tx underrun errors and watchdog timeouts, I'd like to know waht caused the error. If you can reliably reproduce the Tx underrun, would you change the vr(4) code as the following and test again? From:if_vr.c 689 /* Configure Tx FIFO threshold. */ 690 sc->vr_txthresh = VR_TXTHRESH_MIN; 691 if ((sc->vr_quirks & VR_Q_CSUM) != 0) { 692 ifp->if_hwassist = VR_CSUM_FEATURES; To: 689 /* Configure Tx FIFO threshold. */ 690 sc->vr_txthresh = VR_TXTHRESH_MIN; 691 if (sc->vr_revid < REV_ID_VT6105_A0) 692 sc->vr_txthresh = VR_TXTHRESH_MAX; 693 if ((sc->vr_quirks & VR_Q_CSUM) != 0) { 694 ifp->if_hwassist = VR_CSUM_FEATURES; > and no more errors were reported. > > Despite the errors in dmesg everything seems to work fine at all times > with samba tx performance of 9.5mb/s and rx of 8.5mb/s using Vista as a > client. > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 07:06:10 2008 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 CDF6316A418; Sun, 17 Feb 2008 07:06:10 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id A042B13C459; Sun, 17 Feb 2008 07:06:09 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) by aslan.scsiguy.com (8.14.2/8.14.2) with ESMTP id m1H6XOFU080706; Sat, 16 Feb 2008 23:33:25 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <47B7D534.7000204@scsiguy.com> Date: Sat, 16 Feb 2008 23:33:24 -0700 From: "Justin T. Gibbs" User-Agent: Thunderbird 2.0.0.9 (X11/20080113) MIME-Version: 1.0 To: Niki Denev References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> In-Reply-To: <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 07:06:10 -0000 Niki Denev wrote: > I was playing around with DTrace, tracing cam/xpt and the ahd driver and > found out that if i comment the following code : > > if ((spi3caps & SID_SPI_IUS) == 0) > spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : > > da0 at ahd0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > da0: Command Queueing Enabled > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) The aic79xx driver was not properly exporting its capabilities to CAM. This has been addressed as of version 1.30 of aic79xx_osm.c. Please let me know if you still have problems. > > Unfortunately I began seeing again the "Invalid sequencer interrupt" > messages that i was seeing before(with fbsd 6.2) with Seagate drives > on Adaptec at U320 speeds, and I prey that they are harmless (as they > used to be?) While I do not know their root cause, they do appear to be harmless. Do you happen to have your drives in a SES enclosure (on a backplane with a SES chip)? One user claimed this was only reproducible when a GEM318 SES chip was on the bus. -- Justin From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 08:57:30 2008 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 4B7AD16A41A for ; Sun, 17 Feb 2008 08:57:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0209413C4D9 for ; Sun, 17 Feb 2008 08:57:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 940C52844E; Sun, 17 Feb 2008 16:57:28 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id CF084EB51AF; Sun, 17 Feb 2008 16:57:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id go6OPnab0Psa; Sun, 17 Feb 2008 16:57:18 +0800 (CST) Received: from charlie.delphij.net (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 009CEEB515F; Sun, 17 Feb 2008 16:57:16 +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:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=GZRkn5ibsY7b/M3LEu47STswYPmr4LEmZnSl8fnvjPnDBPio4vdK5KMzzP9XXLax0 Wryvhei0GxP8bFKaBlXcg== Message-ID: <47B7F6E8.7090401@delphij.net> Date: Sun, 17 Feb 2008 00:57:12 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: "Justin T. Gibbs" References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> In-Reply-To: <47B7D534.7000204@scsiguy.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Niki Denev , "Gelsema, P \(Patrick\)" , JoaoBR , freebsd-current@freebsd.org Subject: Re: Adaptec AHD U320 operating as only U160 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: Sun, 17 Feb 2008 08:57:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Justin T. Gibbs wrote: > Niki Denev wrote: >> I was playing around with DTrace, tracing cam/xpt and the ahd driver and >> found out that if i comment the following code : >> >> if ((spi3caps & SID_SPI_IUS) == 0) >> spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; >> >> at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : >> >> da0 at ahd0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-3 device >> da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) >> da0: Command Queueing Enabled >> da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > The aic79xx driver was not properly exporting its capabilities to > CAM. This has been addressed as of version 1.30 of aic79xx_osm.c. > Please let me know if you still have problems. Seems worked for me. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHt/boi+vbBBjt66ARApOrAKCIk8xm+XlXecAOJOoNP1mYB4IrVgCfQ4H/ SQqo5Nae/MZ/IxQ+ErkXIdM= =tbaE -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 09:42:40 2008 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 4D3D116A417 for ; Sun, 17 Feb 2008 09:42:40 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 3E88C13C467 for ; Sun, 17 Feb 2008 09:42:39 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1042804rvb.43 for ; Sun, 17 Feb 2008 01:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=utlk01JZqH4+gUq530i+g6bpiWuFnhAjYtycQnyn8bA=; b=KhO4oY4yloLUHfabKE2ZiCD7aoqQ9ORNx0dlf4rIlC6qIvd9W7izMthLZCQEeXyUZh4Kcds9zCx2n9ebvBnvBPWE0bgA3AXJXwv5jQL9a32CbyTKFKzw4HUwlEpv9eBpScyYNX9CVhgFv5xAbPmvr7C/ghQmc3Yt8yHc7r29a7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Nj3Hr+HlMz5xHsZG3IwPFQoGmawh6BrxNcGtKitY69ooarANLVgOxsL8h0JdND0CyKuTECNO7WOriJa0ry7kanpDd0hYWqpI6Niv2dcgKqnEkrZ4AA9BkReS0Cwmkd1diRT5x2TCiAr4PbsWi0lq5ya8xH76mDqcyeFpUAHIvjw= Received: by 10.140.203.9 with SMTP id a9mr3011842rvg.288.1203241357519; Sun, 17 Feb 2008 01:42:37 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sun, 17 Feb 2008 01:42:37 -0800 (PST) Message-ID: <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> Date: Sun, 17 Feb 2008 11:42:37 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: "Justin T. Gibbs" In-Reply-To: <47B7D534.7000204@scsiguy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> X-Google-Sender-Auth: eed5cefecb72b838 Cc: freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 09:42:40 -0000 On Feb 17, 2008 8:33 AM, Justin T. Gibbs wrote: > Niki Denev wrote: > > I was playing around with DTrace, tracing cam/xpt and the ahd driver and > > found out that if i comment the following code : > > > > if ((spi3caps & SID_SPI_IUS) == 0) > > spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : > > > > da0 at ahd0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-3 device > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > da0: Command Queueing Enabled > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > The aic79xx driver was not properly exporting its capabilities to > CAM. This has been addressed as of version 1.30 of aic79xx_osm.c. > Please let me know if you still have problems. > With aic79xx_osm.c 1.30 all of my U320 drives are detected as such. Thanks! I'm only wondering why with the latest version "cpi->transport_version" is set to 2, and then set to 4 on the next line? Probably you left it there for readability? > > > > Unfortunately I began seeing again the "Invalid sequencer interrupt" > > messages that i was seeing before(with fbsd 6.2) with Seagate drives > > on Adaptec at U320 speeds, and I prey that they are harmless (as they > > used to be?) > > While I do not know their root cause, they do appear to be harmless. > Do you happen to have your drives in a SES enclosure (on a backplane > with a SES chip)? One user claimed this was only reproducible when > a GEM318 SES chip was on the bus. > > -- > Justin Nope, no SES enclosure, just plain 68pin scsi drives. I have now put version 1.30 of aic79xx_osm.c on two machines, One of them is running the Dtrace snapshot of 8.0-current with dual channel PCI-X Adaptec U320 controller (on a plain 32bit/33mhz pci slot) : ahd0@pci0:4:1:0: class=0x010000 card=0x00429005 chip=0x80129005 rev=0x03 hdr=0x00 vendor = 'Adaptec Inc' device = 'ASC-29320 Ultra320 SCSI Controller' class = mass storage subclass = SCSI ahd0: port 0xe000-0xe0ff,0xd800-0xd8ff mem 0xfeb9c000-0xfeb9dfff irq 17 at device 1.0 on pci4 ahd0: [ITHREAD] and has four Seagate 73G drives attached to it : da0 at ahd1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) da0: Command Queueing Enabled da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) on this machine i haven't seen "Invalid sequencer interrupt" messages yet. The other machine is running 7.0-PRERELEASE with Adaptec U320 on PCIe (actually it's still PCI/X with a PCIe bridge chip) : pcib4@pci0:3:0:0: class=0x060400 card=0x00000000 chip=0x811410b5 rev=0xbc hdr=0x01 vendor = 'PLX Technology Inc.' class = bridge subclass = PCI-PCI ahd0@pci0:4:4:0: class=0x010000 card=0x00459005 chip=0x80179005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'ASC-29320ALP Ultra320 SCSI Controller' class = mass storage subclass = SCSI and with four 36G Seagate drives (they are smaller but are newer revision than the ones in the first machine) : da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) da0: Command Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) On this machine, i'm seeing the sequencer messages during boot, which are somewhat lenghty and i'm putting them here : http://www.bg.freebsd.org/~ndenev/ahdinvseqintr.txt Then there are several messages like this one too : Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 --Niki From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 11:22:39 2008 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 CA84816A417 for ; Sun, 17 Feb 2008 11:22:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A54AE13C45D for ; Sun, 17 Feb 2008 11:22:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E5C5D46B45; Sun, 17 Feb 2008 06:22:38 -0500 (EST) Date: Sun, 17 Feb 2008 11:22:38 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Milan Obuch In-Reply-To: <200802161949.02217.freebsd-current@dino.sk> Message-ID: <20080217112104.X80805@fledge.watson.org> References: <20080204022334.GC27999@cdnetworks.co.kr> <200802051540.01916.freebsd-current@dino.sk> <20080211060915.GI2317@cdnetworks.co.kr> <200802161949.02217.freebsd-current@dino.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pyunyh@gmail.com, freebsd-current@freebsd.org Subject: Re: CFT: vr(4) 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, 17 Feb 2008 11:22:39 -0000 On Sat, 16 Feb 2008, Milan Obuch wrote: >> I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. Does >> this also happen on other network interface too? When the system hangs, >> would you break into DDB and show me the output of 'show alllocks' and >> 'ps'? > > I need some tests with another box. I was not able to break into DDB. > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did not > invoke DDB. I do not feel if_vr is culprit here, more probably PCI bus got > somehow locked, but I have no idea how could I test it currently. FYI, there are known issues with the effectiveness of syscons ctrl-alt-esc to get into the debugger -- if you haven't tried with a serial break on a serial console, you might want to do so. This is because syscons's interrupt handler acquires the Giant lock in an ithread, requiring a lot more things to be happy to succeed. In constrast, sio (and friends) use fast interrupt handlers and no Giant lock on the way to processing the break request. It may well be that a serial break doesn't get into DDB for you, but it's worth trying... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 10:51:24 2008 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 D3EA516A46B for ; Sun, 17 Feb 2008 10:51:24 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id A5F0113C447 for ; Sun, 17 Feb 2008 10:51:24 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: by shepard.synsport.net (Postfix, from userid 108) id A2E85435F9; Sun, 17 Feb 2008 04:51:23 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shepard X-Spam-Level: X-Spam-Status: No, score=-4.4 required=6.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from secure.synsport.net (unknown [208.69.230.150]) by shepard.synsport.net (Postfix) with ESMTP id B75204356E; Sun, 17 Feb 2008 04:51:21 -0600 (CST) Received: from 82.234.78.29 (SquirrelMail authenticated user marst2) by secure.synsport.net with HTTP; Sun, 17 Feb 2008 04:51:21 -0600 (CET) Message-ID: <59271.82.234.78.29.1203245481.squirrel@secure.synsport.net> In-Reply-To: <20080216210731.GA40417@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> Date: Sun, 17 Feb 2008 04:51:21 -0600 (CET) From: "John Marino" To: "Juergen Lock" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sun, 17 Feb 2008 12:21:27 +0000 Cc: MFL Commissioner , freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 17 Feb 2008 10:51:25 -0000 Hello Juergen, When I looked at the configuration of the GENERIC kernel of 7.0RC2, I noticed that DEBUG=-g and the KTRACE options were already enabled. So I configured sysctl to set minidump = 0 at boot time and also updated rc.conf to save kernel dumps. After rebooting, I invoked Qemu and experienced a panic. After the reboot, I realized that I needed the object files for kdbg to work, so I built the kernel (make buildkernel KERNCONF=GENERIC from the /usr/src directory) Then I ran kdbg on the vmcore.0 file and got this: (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff804778b9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80477cbd in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff80731914 in trap_fatal (frame=0xffffff00010e1680, eva=18446742974215611496) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff8073258f in trap (frame=0xffffffffab9dac70) at /usr/src/sys/amd64/amd64/trap.c:251 #6 0xffffffff8071828e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #7 0x000000000048ce1b in ?? () Previous frame inner to this frame (corrupt stack?) Does that mean anything to you? I have not tried DDB or KDB_UNATTENDED yet. I hope that I am helping you. Please let me know what else I can do. I have included the text that the kbdg showed following my signature, it looks like garbage to me -- I don't know why it's is spaced crazy like that. Regards, John draco-root# cd /usr/obj/usr/src/sys/GENERIC/ draco-root# kgdb kernel.debug /usr/local/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: <0>kke rn eFla ttarla pt rap 12 1w2i:t h inptaegrer ufpatusl td iwshaibllee din user m oFdaeta l ctpruaipd 1=2 :1 ; appiacg ei df a=u lt w0h1i lef aiunl tk evrinretlu amlo daed dcrpeusisd == 00x;4 8acpei1cb idf a=u lt c0o0d ef a u=l tu sveirr trueaald aidndsrtersusc t=i o0nx,0 pafgaeu lnto tc opdree s e=n ts uipnesrtvriuscotri orne apdo idnattear, =p a0gxe2 bn:o0tx p4r8ecsee1nbt stiancskt rpuocitnitoenr p o i n t e r == 00xx9223a:00:x0x7fffffffffffffff8b017c603 dffrca mes tpaocikn tpeori n t e r = 0 x 2=3 :00xx1800:08x1fdf4f9faff fcfoadbe9 dsae7gcm0e nftr a m=e bpaosien t0exr0 , l i m i t 0=x f0fxf1f0f:,0 xt2y0p ec o0dxe 1sbe g m e n=t D P=L b3a,s ep r0exs 41d,4 dl4odn4gd ,1 ,l idmeift3 20 x0,d 0g0rfafn, 1t yppreo c0exsds o r e=f lDaPgLs 2=, ipnrteesr r0u,p tl oennga b0l,e dd,e fr3e2s u1m,e ,g rIaOnP L0 = p0r occuersrseonrt epfrloacgess s= I=O P1L1 =( i0d lceu:r rcepnut1 )p rtorcaeps sn u m=b e1r0 3 9= (1q2e mu-sysptaenmi-cx:8 6p_a6g4e) ftarualpt n ucmpbueird == 112 Uptime: 11m5s Dumping 1983 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 1983MB (507568 pages) 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > OK, I guess you want to start here: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > and > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html > > And of course you want to build a debug kernel (makeoptions > DEBUG=-g), > building a kernel is explained here: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html > > I also had to put DDB into the kernel so that it gets built without > -fomit-frame-pointer (you probably want KDB_UNATTENDED then too, and > KDB_TRACE while you're at it.) > > Oh and I guess you want to disable minidumps also (sysctl > debug.minidump=0), > there's a race in there that might(!) cause not so useful dumps otherwise. > > Then when you have a dump, post a script(1) of a `bt' in kgdb, and we'll > see if it tells more than the backtraces I got... > > Thanx, > Juergen > From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 12:51:20 2008 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 CBF0C16A418 for ; Sun, 17 Feb 2008 12:51:20 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id A07E213C4DB for ; Sun, 17 Feb 2008 12:51:20 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: by shepard.synsport.net (Postfix, from userid 108) id 0D293435F9; Sun, 17 Feb 2008 06:51:20 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shepard X-Spam-Level: X-Spam-Status: No, score=-4.4 required=6.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from secure.synsport.net (unknown [208.69.230.150]) by shepard.synsport.net (Postfix) with ESMTP id 66CC74356E; Sun, 17 Feb 2008 06:51:18 -0600 (CST) Received: from 82.234.78.29 (SquirrelMail authenticated user marst2) by secure.synsport.net with HTTP; Sun, 17 Feb 2008 06:51:18 -0600 (CET) Message-ID: <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> In-Reply-To: <20080216210731.GA40417@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> Date: Sun, 17 Feb 2008 06:51:18 -0600 (CET) From: "John Marino" To: "Juergen Lock" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sun, 17 Feb 2008 13:17:28 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 17 Feb 2008 12:51:21 -0000 Hello Juergen, I decided to build a debug kernel as you suggested with DDB, KDB, KDB_TRACE, and KDB_UNATTENDED as you suggested. The first time the kernel panicked, I did not get a dump, but the system did save the second panic. The backtrace is about the same, but the initial information looks much better. I hope this helps, John draco-root# kgdb kernel.debug /usr/local/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: kernel tFraatpa l trap 12 wi1t2h: interpraugpet sf aduilsta bwlheidle i n Fkaetranle lt rmaopd e1 :c pupirdi v=i l1e;g eadp iicn sitdr u=c tion0 1f afualutl tw hviilret uianl kaedrdnreels sm o=d e0 xc0p ufiadu l=t 0;c oadpei c =i ds u=p e0r0v iisnosrt rruecatdi odna tpao,i nptaegre =n o0tx 2pfr3e0s:en0tx fifnfsftfrfufcft8i0o8n3 bpbocidn tsetra c=k 0pxo8i:n0txer f f f f f f f f=8 004x710b:a01x5f fsftfafcfk fpfoaibn9tde6r6 e 0 f r a m e =p o0ixn1t0e:r0 x f f f f f=f f0fxa1b09:d06xbcf0f fffrfafmfef 8p0o9i8n1tceer0 c o d e s e g=m e0nxt1 0=: 0bxase f0fxf0f,f flfifmaibt9 d06xc00,0 tcyopdee 0sxe0gm e nt == DbPaLs e0 ,0 xp0r,e sl i0m,i tl o0nxg f0f,f fdfe,f32 0, gran 0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffffffffffffd3 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffff00010e1680 stack pointer = 0x10:0xffffffffab9d64e0 frame pointer = 0x10:0xffffffff80a93640 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 999 (qemu-system-x86_64) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a trap_fatal() at trap_fatal+0x29f trap() at trap+0x242 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffff00010e1680, rsp = 0xffffffffab9d64e0, rbp = 0xffffffff80a93640 --- dmapbase() at 0xffffff00010e1680 Uptime: 29m47s Dumping 1983 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 1983MB (507568 pages) 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0xffffffff80486dd8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff80487237 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xffffffff8074857f in trap_fatal (frame=0xc, eva=Variable "eva" is not available.) at /usr/src/sys/amd64/amd64/trap.c:724 #4 0xffffffff80749272 in trap (frame=0xffffffffab9d6430) at /usr/src/sys/amd64/amd64/trap.c:251 #5 0xffffffff8072e60e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #6 0xffffffff8047ba90 in _thread_lock_flags (td=0xffffffffab9d66e0, opts=Variable "opts" is not available.) at /usr/src/sys/kern/kern_mutex.c:523 > > OK, I guess you want to start here: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > and > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html > > And of course you want to build a debug kernel (makeoptions > DEBUG=-g), > building a kernel is explained here: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html > > I also had to put DDB into the kernel so that it gets built without > -fomit-frame-pointer (you probably want KDB_UNATTENDED then too, and > KDB_TRACE while you're at it.) > > Oh and I guess you want to disable minidumps also (sysctl > debug.minidump=0), > there's a race in there that might(!) cause not so useful dumps otherwise. > > Then when you have a dump, post a script(1) of a `bt' in kgdb, and we'll > see if it tells more than the backtraces I got... > > Thanx, > Juergen > From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 13:58:48 2008 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 AF45916A417 for ; Sun, 17 Feb 2008 13:58:48 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2F67913C45A for ; Sun, 17 Feb 2008 13:58:42 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 17 Feb 2008 14:55:20 +0100 id 0002E010.47B83CC8.0000DC9E From: Milan Obuch To: freebsd-current@freebsd.org Date: Sun, 17 Feb 2008 14:58:26 +0100 User-Agent: KMail/1.9.7 References: <20080204022334.GC27999@cdnetworks.co.kr> <200802161949.02217.freebsd-current@dino.sk> <20080217112104.X80805@fledge.watson.org> In-Reply-To: <20080217112104.X80805@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802171458.26951.freebsd-current@dino.sk> Subject: Re: CFT: vr(4) 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, 17 Feb 2008 13:58:48 -0000 On Sunday 17 February 2008, Robert Watson wrote: > On Sat, 16 Feb 2008, Milan Obuch wrote: > >> I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. > >> Does this also happen on other network interface too? When the system > >> hangs, would you break into DDB and show me the output of 'show > >> alllocks' and 'ps'? > > > > I need some tests with another box. I was not able to break into DDB. > > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did > > not invoke DDB. I do not feel if_vr is culprit here, more probably PCI > > bus got somehow locked, but I have no idea how could I test it currently. > > FYI, there are known issues with the effectiveness of syscons ctrl-alt-esc > to get into the debugger -- if you haven't tried with a serial break on a > serial console, you might want to do so. This is because syscons's > interrupt handler acquires the Giant lock in an ithread, requiring a lot > more things to be happy to succeed. In constrast, sio (and friends) use > fast interrupt handlers and no Giant lock on the way to processing the > break request. It may well be that a serial break doesn't get into DDB for > you, but it's worth trying... > > Robert N M Watson > Computer Laboratory > University of Cambridge > You are right, after rebuilding kernel with BREAK_TO_DEBUGGER I am able to get requested data. BTW, I can't find just now what ALT_BREAK_TO_DEBUGGER means... After kldload if_vr, dhclient vr0 and ping -f in a minute system freezes. KDB: enter: Line break on console [thread pid 11 tid 100003 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> show alllocks db> ps pid ppid pgrp uid state wmesg wchan cmd 1231 936 1231 0 S+ nanslp 0xc07db764 ping 1230 1 1230 65 Ss select 0xc1d46868 dhclient 1174 1 1173 0 S+ select 0xc1d467e8 dhclient 936 924 936 0 S+ pause 0xc1cd130c csh 935 1 935 0 Ss+ ttyin 0xc18ca410 getty 934 1 934 0 Ss+ ttyin 0xc18ca810 getty 933 1 933 0 Ss+ ttyin 0xc18cac10 getty 932 1 932 0 Ss+ ttyin 0xc18cb010 getty 931 1 931 0 Ss+ ttyin 0xc18cb410 getty 930 1 930 0 Ss+ ttyin 0xc18cb810 getty 929 1 929 0 Ss+ ttyin 0xc18cbc10 getty 928 1 928 0 Ss+ ttyin 0xc18cc010 getty 927 1 927 0 Ss+ ttyin 0xc18cc410 getty 926 1 926 0 Ss+ ttyin 0xc18cc810 getty 925 1 925 0 Ss+ ttyin 0xc18ccc10 getty 924 1 924 0 Ss+ wait 0xc1bad804 login 882 1 882 0 Ss nanslp 0xc07db764 cron 876 1 876 25 Ss pause 0xc19b3864 sendmail 872 1 872 0 Ss select 0xc18c1828 sendmail 749 1 749 0 Ss select 0xc1900928 syslogd 703 1 703 0 Ss select 0xc18c1ea8 devd 369 1 369 65 Ss select 0xc19830a8 dhclient 349 1 30 0 S+ select 0xc18c17e8 dhclient 29 0 0 0 SL sdflush 0xc0835804 [softdepflush] 28 0 0 0 SL syncer 0xc07db58c [syncer] 27 0 0 0 SL vlruwt 0xc174eab0 [vnlru] 26 0 0 0 SL psleep 0xc082d1c4 [bufdaemon] 25 0 0 0 SL pgzero 0xc08363e0 [pagezero] 24 0 0 0 SL psleep 0xc0835ffc [vmdaemon] 23 0 0 0 SL psleep 0xc0835fc4 [pagedaemon] 22 0 0 0 SL - 0xc189e43c [fdc0] 21 0 0 0 SL - 0xc17c6000 [fw0_probe] 20 0 0 0 SL - 0xc17cdd00 [fw0_taskq] 19 0 0 0 SL usbevt 0xc1746210 [usb2] 18 0 0 0 SL usbevt 0xc1750210 [usb1] 17 0 0 0 SL usbtsk 0xc07d8ed4 [usbtask-dr] 16 0 0 0 SL usbtsk 0xc07d8ec0 [usbtask-hc] 15 0 0 0 SL usbevt 0xc1751210 [usb0] 14 0 0 0 SL ccb_scan 0xc07bee14 [xpt_thrd] 9 0 0 0 SL - 0xc1726780 [kqueue taskq] 8 0 0 0 SL - 0xc1726880 [acpi_task_2] 7 0 0 0 SL - 0xc1726880 [acpi_task_1] 6 0 0 0 SL - 0xc1726880 [acpi_task_0] 5 0 0 0 SL - 0xc1726b00 [thread taskq] 13 0 0 0 SL - 0xc07db594 [yarrow] 4 0 0 0 SL - 0xc07d95ec [g_down] 3 0 0 0 SL - 0xc07d95e8 [g_up] 2 0 0 0 SL - 0xc07d95e0 [g_event] 12 0 0 0 WL (threaded) intr 100077 I [irq16: re0 vr3] 100076 I [irq19: fwohci0 vr2] 100075 I [irq18: vr1] 100074 I [irq17: vr0] 100038 I [irq7: ppbus0 ppc0] 100037 I [irq12: psm0] 100036 I [irq1: atkbd0] 100035 I [swi0: sio] 100031 I [irq15: ata1] 100030 I [irq14: ata0] 100028 I [irq23: ehci0] 100026 I [irq22: ohci1+] 100022 I [irq21: ohci0] 100021 I [irq9: acpi0] 100020 I [swi5: +] 100019 I [swi2: cambio] 100013 I [swi6: task queue] 100012 I [swi6: Giant taskq] 100006 I [swi3: vm] 100005 I [swi4: clock sio] 100004 I [swi1: net] 11 0 0 0 RL CPU 0 [idle: cpu0] 1 0 1 0 SLs wait 0xc16baab0 [init] 10 0 0 0 SL audit_wo 0xc0835264 [audit] 0 0 0 0 WLs [swapper] db> After continue, I am able to break ping, but no more packet could be sent... 'sendto: no buffer space available' is all I get from ping now. Does this help in any way? Is there anything else I should test? Regards, Milan -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 14:17:41 2008 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 C62DF16A418 for ; Sun, 17 Feb 2008 14:17:41 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 64AB413C457 for ; Sun, 17 Feb 2008 14:17:41 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 17 Feb 2008 15:14:20 +0100 id 0002E00A.47B8413C.0000DDBA From: Milan Obuch To: freebsd-current@freebsd.org Date: Sun, 17 Feb 2008 15:17:26 +0100 User-Agent: KMail/1.9.7 References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> In-Reply-To: <200802171458.26951.freebsd-current@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802171517.26965.freebsd-current@dino.sk> Subject: Re: CFT: vr(4) 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, 17 Feb 2008 14:17:41 -0000 On Sunday 17 February 2008, Milan Obuch wrote: > On Sunday 17 February 2008, Robert Watson wrote: > > On Sat, 16 Feb 2008, Milan Obuch wrote: > > >> I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. > > >> Does this also happen on other network interface too? When the system > > >> hangs, would you break into DDB and show me the output of 'show > > >> alllocks' and 'ps'? > > > > > > I need some tests with another box. I was not able to break into DDB. > > > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did > > > not invoke DDB. I do not feel if_vr is culprit here, more probably PCI > > > bus got somehow locked, but I have no idea how could I test it > > > currently. > > > > FYI, there are known issues with the effectiveness of syscons > > ctrl-alt-esc to get into the debugger -- if you haven't tried with a > > serial break on a serial console, you might want to do so. This is > > because syscons's interrupt handler acquires the Giant lock in an > > ithread, requiring a lot more things to be happy to succeed. In > > constrast, sio (and friends) use fast interrupt handlers and no Giant > > lock on the way to processing the break request. It may well be that a > > serial break doesn't get into DDB for you, but it's worth trying... > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > You are right, after rebuilding kernel with BREAK_TO_DEBUGGER I am able to > get requested data. BTW, I can't find just now what ALT_BREAK_TO_DEBUGGER > means... > > After kldload if_vr, dhclient vr0 and ping -f in a minute > system freezes. > Correction... as I moved cable from on-board re0 to vr0, system remembered arp table entry and did not actually try to use vr0. Now I repeated it, but boot system with cable in vr0. This time it hangs right after ping <>, and break does not enter debugger... hard hang. I tried it twice, the same result... So no data to check, actually, only hard hang. Regards, Milan -- Address this mail is sent from is used only for this mailing list. Do not send any messages to it directly as a response, reply only to mailing list. For mail to me personally, use milan in address instead. From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 14:23:14 2008 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 2623A16A46B for ; Sun, 17 Feb 2008 14:23:14 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6FF4713C442 for ; Sun, 17 Feb 2008 14:23:13 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1095059rvb.43 for ; Sun, 17 Feb 2008 06:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=uM583Rvw6UXksOniqCnxSYLzSShVAKDetTAqEf2GDfM=; b=RZ/ADLHZACYMMRnOavjEQzMIO1NcPtRdDYpFBWNFB3Dr0IzQH0xJsmw0Le/E7tEKzIXdbhHgt/aaYPD4kP0dQoaIZfacjP/P/s4nWztHv9LRz3RjYDRfUfc5gQdsWOKZt0QXQShEamTyt7czK3DFfptDbt1VLUE77sGFt98INk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bfXRQP6SMiMgLge4ipFRPd0ICCqRtDF8NWCLEMy+V9c4Wzh6spdpn43LQNitw7eaWtZukcCaYyLGB9VSozp7UG55WGEcGzZhVRLuDm6lhXNTpnir5TkpHFGBHJcRmXr125hbYagBoyOB+/SbM+3rcsZ671AnN0rDVdDesZvi1SQ= Received: by 10.141.185.3 with SMTP id m3mr3151366rvp.133.1203258192360; Sun, 17 Feb 2008 06:23:12 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sun, 17 Feb 2008 06:23:12 -0800 (PST) Message-ID: <2e77fc10802170623k181c807dh52b13b01c121cd9f@mail.gmail.com> Date: Sun, 17 Feb 2008 14:23:12 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: "Justin T. Gibbs" In-Reply-To: <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> X-Google-Sender-Auth: 662d2b2e24d1ffb0 Cc: freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 14:23:14 -0000 On Feb 17, 2008 9:42 AM, Niki Denev wrote: > On Feb 17, 2008 8:33 AM, Justin T. Gibbs wrote: > > Niki Denev wrote: > > > I was playing around with DTrace, tracing cam/xpt and the ahd driver and > > > found out that if i comment the following code : > > > > > > if ((spi3caps & SID_SPI_IUS) == 0) > > > spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; > > > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : > > > > > > da0 at ahd0 bus 0 target 0 lun 0 > > > da0: Fixed Direct Access SCSI-3 device > > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > > da0: Command Queueing Enabled > > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > > > The aic79xx driver was not properly exporting its capabilities to > > CAM. This has been addressed as of version 1.30 of aic79xx_osm.c. > > Please let me know if you still have problems. > > > > With aic79xx_osm.c 1.30 all of my U320 drives are detected as such. Thanks! > I'm only wondering why with the latest version > "cpi->transport_version" is set to 2, and > then set to 4 on the next line? Probably you left it there for readability? > > > > > > > Unfortunately I began seeing again the "Invalid sequencer interrupt" > > > messages that i was seeing before(with fbsd 6.2) with Seagate drives > > > on Adaptec at U320 speeds, and I prey that they are harmless (as they > > > used to be?) > > > > While I do not know their root cause, they do appear to be harmless. > > Do you happen to have your drives in a SES enclosure (on a backplane > > with a SES chip)? One user claimed this was only reproducible when > > a GEM318 SES chip was on the bus. > > > > -- > > Justin > > Nope, no SES enclosure, just plain 68pin scsi drives. > I have now put version 1.30 of aic79xx_osm.c on two machines, > One of them is running the Dtrace snapshot of 8.0-current > with dual channel PCI-X Adaptec U320 controller (on a plain > 32bit/33mhz pci slot) : > > ahd0@pci0:4:1:0: class=0x010000 card=0x00429005 chip=0x80129005 > rev=0x03 hdr=0x00 > vendor = 'Adaptec Inc' > device = 'ASC-29320 Ultra320 SCSI Controller' > class = mass storage > subclass = SCSI > > ahd0: port > 0xe000-0xe0ff,0xd800-0xd8ff mem 0xfeb9c000-0xfeb9dfff irq 17 at device > 1.0 on pci4 > ahd0: [ITHREAD] > > and has four Seagate 73G drives attached to it : > da0 at ahd1 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > da0: Command Queueing Enabled > da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) > > on this machine i haven't seen "Invalid sequencer interrupt" messages yet. > > The other machine is running 7.0-PRERELEASE > with Adaptec U320 on PCIe (actually it's still PCI/X with a PCIe bridge chip) : > > pcib4@pci0:3:0:0: class=0x060400 card=0x00000000 chip=0x811410b5 > rev=0xbc hdr=0x01 > vendor = 'PLX Technology Inc.' > class = bridge > subclass = PCI-PCI > ahd0@pci0:4:4:0: class=0x010000 card=0x00459005 chip=0x80179005 > rev=0x10 hdr=0x00 > vendor = 'Adaptec Inc' > device = 'ASC-29320ALP Ultra320 SCSI Controller' > class = mass storage > subclass = SCSI > > and with four 36G Seagate drives (they are smaller but are newer > revision than the ones in the first machine) : > > da0 at ahd0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > da0: Command Queueing Enabled > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > On this machine, i'm seeing the sequencer messages during boot, > which are somewhat lenghty and i'm putting them here : > http://www.bg.freebsd.org/~ndenev/ahdinvseqintr.txt > > Then there are several messages like this one too : > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 > 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 > > --Niki > After some bonnie64 runs the first machine (8.0-CURRENT Dtrace snapshot with aic79xx_osm.c v1.30) spat out this : ahd1: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd1: Dumping Card State at program address 0x38 Mode 0x11 INTSTAT[0x0] SELOID[0x3] SELID[0x20] HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x10]:(SEQ_SWTMRTO) SAVED_MODE[0x11] DFFSTAT[0x31]:(CURRFIFO_1|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x26] KERNEL_QFREEZE_COUNT[0x26] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x8]:(AIPERR) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x1]:(LQOSTOP0) SCB Count = 512 CMDS_PENDING = 7 LASTSCB 0x18a CURRSCB 0x18a NEXTSCB 0xff80 qinstart = 42104 qinfifonext = 42104 QINFIFO: WAITING_TID_QUEUES: Pending list: 325 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 403 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 439 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 380 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 495 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 353 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 478 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] Total 7 Kernel Free SCB lists: Any Device: 354 394 389 398 433 444 412 378 340 467 468 377 430 428 511 385 333 417 364 407 425 447 381 362 476 379 489 500 331 393 479 373 441 450 471 344 456 336 361 342 466 402 436 339 482 330 345 355 443 383 384 399 335 463 404 507 496 386 369 390 470 337 465 388 356 372 484 328 459 422 481 472 367 338 427 423 351 485 410 492 448 418 363 411 329 326 461 457 327 376 343 400 480 508 395 415 488 451 358 440 368 352 323 341 332 405 509 505 445 477 365 437 469 462 497 357 453 446 442 406 416 483 502 464 334 506 431 474 424 503 350 366 324 458 434 455 348 493 449 504 452 435 370 498 510 359 490 501 414 346 429 382 420 392 401 421 371 473 426 413 391 438 487 387 491 374 499 454 397 486 432 408 349 475 375 396 460 494 409 419 360 347 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x8286, SCB 0x162 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd1: FIFO1 Free, LONGJMP == 0x829f, SCB 0x162 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x55 0x0 0x1 0x62 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd1: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x0] ahd1: REG0 == 0x160, SINDEX = 0x111, DINDEX = 0x108 ahd1: SCBPTR == 0x162, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x18a CDB 2a 0 3 80 8 c3 STACK: 0x25 0x140 0x140 0x286 0x286 0x286 0x286 0x36 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd1:0:1:0): SCB 478 - timed out (da1:ahd1:0:1:0): Queuing a BDR SCB ahd1: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd1: Dumping Card State at program address 0xf2 Mode 0x33 Card was paused INTSTAT[0x4]:(SEQINT) SELOID[0x1] SELID[0x20] HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x10]:(SEQ_SWTMRTO) SAVED_MODE[0x11] DFFSTAT[0x31]:(CURRFIFO_1|FIFO0FREE|FIFO1FREE) SCSISIGI[0x25]:(P_DATAOUT_DT|ACKI|BSYI) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x26] KERNEL_QFREEZE_COUNT[0x26] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x8]:(AIPERR) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED) LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x81]:(LQOSTOP0) SCB Count = 512 CMDS_PENDING = 7 LASTSCB 0x1de CURRSCB 0x1de NEXTSCB 0xff80 qinstart = 42105 qinfifonext = 42105 QINFIFO: WAITING_TID_QUEUES: Pending list: 325 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 403 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 439 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 380 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 495 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 353 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 478 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] Total 7 Kernel Free SCB lists: Any Device: 354 394 389 398 433 444 412 378 340 467 468 377 430 428 511 385 333 417 364 407 425 447 381 362 476 379 489 500 331 393 479 373 441 450 471 344 456 336 361 342 466 402 436 339 482 330 345 355 443 383 384 399 335 463 404 507 496 386 369 390 470 337 465 388 356 372 484 328 459 422 481 472 367 338 427 423 351 485 410 492 448 418 363 411 329 326 461 457 327 376 343 400 480 508 395 415 488 451 358 440 368 352 323 341 332 405 509 505 445 477 365 437 469 462 497 357 453 446 442 406 416 483 502 464 334 506 431 474 424 503 350 366 324 458 434 455 348 493 449 504 452 435 370 498 510 359 490 501 414 346 429 382 420 392 401 421 371 473 426 413 391 438 487 387 491 374 499 454 397 486 432 408 349 475 375 396 460 494 409 419 360 347 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x8286, SCB 0x162 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd1: FIFO1 Free, LONGJMP == 0x829f, SCB 0x162 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x55 0x0 0x1 0x62 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd1: LQISTATE = 0x1, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd1: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd1: REG0 == 0x18e, SINDEX = 0x133, DINDEX = 0x104 ahd1: SCBPTR == 0x1de, SCB_NEXT == 0xff80, SCB_NEXT2 == 0xffcd CDB 28 0 1 c4 8b ab STACK: 0x140 0x140 0x286 0x286 0x286 0x286 0x39 0x1 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd1:0:1:0): Task Management Func 0x1 Complete (da1:ahd1:0:1:0): no longer in timeout, status = 24b (da1:ahd1:0:1:0): SCB 353 - timed out (da1:ahd1:0:1:0): Queuing a BDR SCB ahd1: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd1: Dumping Card State at program address 0x16 Mode 0x33 INTSTAT[0x0] SELOID[0x1] SELID[0x20] HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x10]:(SEQ_SWTMRTO) SAVED_MODE[0x11] DFFSTAT[0x31]:(CURRFIFO_1|FIFO0FREE|FIFO1FREE) SCSISIGI[0x25]:(P_DATAOUT_DT|ACKI|BSYI) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x40]:(ENSELO) SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x26] KERNEL_QFREEZE_COUNT[0x26] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x8]:(AIPERR) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED) LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x81]:(LQOSTOP0) SCB Count = 512 CMDS_PENDING = 7 LASTSCB 0x161 CURRSCB 0x161 NEXTSCB 0xff80 qinstart = 42107 qinfifonext = 42107 QINFIFO: WAITING_TID_QUEUES: 1 ( 0x161 0x1de ) Pending list: 478 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 325 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 403 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 439 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 380 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 495 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] 353 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] Total 7 Kernel Free SCB lists: Any Device: 354 394 389 398 433 444 412 378 340 467 468 377 430 428 511 385 333 417 364 407 425 447 381 362 476 379 489 500 331 393 479 373 441 450 471 344 456 336 361 342 466 402 436 339 482 330 345 355 443 383 384 399 335 463 404 507 496 386 369 390 470 337 465 388 356 372 484 328 459 422 481 472 367 338 427 423 351 485 410 492 448 418 363 411 329 326 461 457 327 376 343 400 480 508 395 415 488 451 358 440 368 352 323 341 332 405 509 505 445 477 365 437 469 462 497 357 453 446 442 406 416 483 502 464 334 506 431 474 424 503 350 366 324 458 434 455 348 493 449 504 452 435 370 498 510 359 490 501 414 346 429 382 420 392 401 421 371 473 426 413 391 438 487 387 491 374 499 454 397 486 432 408 349 475 375 396 460 494 409 419 360 347 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd1: FIFO0 Free, LONGJMP == 0x8286, SCB 0x162 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd1: FIFO1 Free, LONGJMP == 0x829f, SCB 0x162 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x55 0x0 0x1 0x62 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd1: LQISTATE = 0x1, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd1: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd1: REG0 == 0x18e, SINDEX = 0x133, DINDEX = 0x104 ahd1: SCBPTR == 0x161, SCB_NEXT == 0x1de, SCB_NEXT2 == 0xffcd CDB 28 0 1 c4 8c 2b STACK: 0x140 0x140 0x286 0x286 0x286 0x286 0x39 0x1 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da1:ahd1:0:1:0): SCB 495 - timed out (da1:ahd1:0:1:0): Other SCB Timeout (da1:ahd1:0:1:0): Task Management Func 0x1 Complete (da1:ahd1:0:1:0): no longer in timeout, status = 24b --Niki From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 15:06:45 2008 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 D5C1316A418 for ; Sun, 17 Feb 2008 15:06:45 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD8F13C469 for ; Sun, 17 Feb 2008 15:06:45 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout3.freenet.de with esmtpa (Exim 4.69) (envelope-from ) id 1JQl6J-0006lA-RN; Sun, 17 Feb 2008 16:06:43 +0100 Received: from rb6e4.r.pppool.de ([89.54.182.228]:56668 helo=peedub.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #10) id 1JQl6J-0004J7-JU; Sun, 17 Feb 2008 16:06:43 +0100 Date: Sun, 17 Feb 2008 16:06:42 +0100 From: Gary Jennejohn To: "John Marino" Message-ID: <20080217160642.2ac9363e@peedub.jennejohn.org> In-Reply-To: <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Juergen Lock Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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: Sun, 17 Feb 2008 15:06:45 -0000 On Sun, 17 Feb 2008 06:51:18 -0600 (CET) "John Marino" wrote: > Unread portion of the kernel message buffer: > kernel > > tFraatpa l trap 12 wi1t2h: interpraugpet sf aduilsta bwlheidle > i > n > Fkaetranle lt rmaopd e1 > :c pupirdi v=i l1e;g eadp iicn sitdr u=c tion0 1f > afualutl tw hviilret uianl kaedrdnreels sm o=d e0 > xc0p > ufiadu l=t 0;c oadpei c =i ds u=p e0r0v > iisnosrt rruecatdi odna tpao,i nptaegre =n o0tx 2pfr3e0s:en0tx > fifnfsftfrfufcft8i0o8n3 bpbocidn > tsetra c=k 0pxo8i:n0txer f f f f f f f f=8 004x710b:a01x5f > fsftfafcfk fpfoaibn9tde6r6 e 0 > f r a m e =p o0ixn1t0e:r0 x f f f f f=f f0fxa1b09:d06xbcf0f > fffrfafmfef 8p0o9i8n1tceer0 > c o d e s e g=m e0nxt1 0=: 0bxase f0fxf0f,f flfifmaibt9 d06xc00,0 > tcyopdee 0sxe0gm > e nt == DbPaLs e0 ,0 xp0r,e sl i0m,i tl o0nxg f0f,f fdfe,f32 0, gran 0 > I can't help with your problem, but I suggest that you add options PRINTF_BUFR_SIZE=128 to your kernel config file to avoid the above corrupted output. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 15:36:45 2008 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 A37FB16A419; Sun, 17 Feb 2008 15:36:45 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 701CE13C461; Sun, 17 Feb 2008 15:36:45 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from [192.168.0.6] (tumnus.scsiguy.org [192.168.0.6]) (authenticated bits=0) by aslan.scsiguy.com (8.14.2/8.14.2) with ESMTP id m1HFaeGJ085890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 08:36:40 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <47B8547E.7080103@scsiguy.com> Date: Sun, 17 Feb 2008 08:36:30 -0700 From: "Justin T. Gibbs" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Niki Denev References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> In-Reply-To: <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 15:36:45 -0000 Niki Denev wrote: > > With aic79xx_osm.c 1.30 all of my U320 drives are detected as such. Thanks! > I'm only wondering why with the latest version > "cpi->transport_version" is set to 2, and > then set to 4 on the next line? Probably you left it there for readability? It was an oversight. It seems that this section of code came from the aic7xxx driver where, depending on controller model, the protocol version must be reported differently. I missed some of the duplication when trying to remove it in my last checkin. :-( Should be fixed now. > Nope, no SES enclosure, just plain 68pin scsi drives. > I have now put version 1.30 of aic79xx_osm.c on two machines, > One of them is running the Dtrace snapshot of 8.0-current > with dual channel PCI-X Adaptec U320 controller (on a plain > 32bit/33mhz pci slot) : > > ahd0@pci0:4:1:0: class=0x010000 card=0x00429005 chip=0x80129005 The error only occurs on rev B. controllers (0x10 reported in the PCI revision register). The machine not reporting the error has an A4 part. > Then there are several messages like this one too : > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 > 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 Invalid command opcode. CAM will usually report the command that failed. You don't see any other output? -- Justin From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 15:48:03 2008 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 6D9FA16A41A for ; Sun, 17 Feb 2008 15:48:03 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 47B8E13C447 for ; Sun, 17 Feb 2008 15:48:02 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1111860rvb.43 for ; Sun, 17 Feb 2008 07:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=46Q1IViVoQ1Rz+UPxN4bGu8DWXHTjUarC+yJ0YhQffE=; b=nNusgJz6dBFoulC5MDTFaKyW7FZSBZSM9SjecK04cGFbssnk4OEWutOFcOU7qeDy84f11kglJZvyq/xShT97BAZ6CHs75EGzAmKKCbjofYZwq8fb0enf6YVuRmaPW+XDicDZg0pmTJ/hmbwwpnYzpDN+XuJPxkL5V+wamwwprVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=atsK1csK7gIoZHeXw47PnmQbHg520LlkNrPyyen8iWMNAujbxtP5Q1Lf0tw25AMOyQEXNjBsgSgUCmxAWAZBMCprNID9zUMmB2LQp7brqeGIPuOCdYlu7T0gMZmReKZj6zT9NFDjkMeJbWuGs0jTOc0/wZtwfYB8FqmUWYXbs/Q= Received: by 10.141.172.6 with SMTP id z6mr3211644rvo.80.1203263281319; Sun, 17 Feb 2008 07:48:01 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sun, 17 Feb 2008 07:48:01 -0800 (PST) Message-ID: <2e77fc10802170748g757e569ejb079f849cf879668@mail.gmail.com> Date: Sun, 17 Feb 2008 15:48:01 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: "Justin T. Gibbs" In-Reply-To: <47B8547E.7080103@scsiguy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704182239.59842.gelsemap@superhero.nl> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> <47B8547E.7080103@scsiguy.com> X-Google-Sender-Auth: a0bcd0737db5c319 Cc: freebsd-current@freebsd.org Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 15:48:03 -0000 On Feb 17, 2008 3:36 PM, Justin T. Gibbs wrote: > Niki Denev wrote: > > > > With aic79xx_osm.c 1.30 all of my U320 drives are detected as such. Thanks! > > I'm only wondering why with the latest version > > "cpi->transport_version" is set to 2, and > > then set to 4 on the next line? Probably you left it there for readability? > > It was an oversight. It seems that this section of code came from the > aic7xxx driver where, depending on controller model, the protocol version > must be reported differently. I missed some of the duplication when trying > to remove it in my last checkin. :-( Should be fixed now. > > > Nope, no SES enclosure, just plain 68pin scsi drives. > > I have now put version 1.30 of aic79xx_osm.c on two machines, > > One of them is running the Dtrace snapshot of 8.0-current > > with dual channel PCI-X Adaptec U320 controller (on a plain > > 32bit/33mhz pci slot) : > > > > ahd0@pci0:4:1:0: class=0x010000 card=0x00429005 chip=0x80129005 > > The error only occurs on rev B. controllers (0x10 reported in the PCI > revision register). The machine not reporting the error has an A4 > part. > > > Then there are several messages like this one too : > > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 > > 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 > > Invalid command opcode. CAM will usually report the command that failed. > You don't see any other output? > > -- > Justin > > Sorry, I must have missed the full output : Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass0:ahd0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 ec 0 (pass0:ahd0:0:0:0): CAM Status: SCSI Status Error (pass0:ahd0:0:0:0): SCSI Status: Check Condition (pass0:ahd0:0:0:0): ILLEGAL REQUEST asc:20,0 (pass0:ahd0:0:0:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass0:ahd0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 a1 0 (pass0:ahd0:0:0:0): CAM Status: SCSI Status Error (pass0:ahd0:0:0:0): SCSI Status: Check Condition (pass0:ahd0:0:0:0): ILLEGAL REQUEST asc:20,0 (pass0:ahd0:0:0:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass1:ahd0:0:1:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 ec 0 (pass1:ahd0:0:1:0): CAM Status: SCSI Status Error (pass1:ahd0:0:1:0): SCSI Status: Check Condition (pass1:ahd0:0:1:0): ILLEGAL REQUEST asc:20,0 (pass1:ahd0:0:1:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass1:ahd0:0:1:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 a1 0 (pass1:ahd0:0:1:0): CAM Status: SCSI Status Error (pass1:ahd0:0:1:0): SCSI Status: Check Condition (pass1:ahd0:0:1:0): ILLEGAL REQUEST asc:20,0 (pass1:ahd0:0:1:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass2:ahd0:0:2:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 ec 0 (pass2:ahd0:0:2:0): CAM Status: SCSI Status Error (pass2:ahd0:0:2:0): SCSI Status: Check Condition (pass2:ahd0:0:2:0): ILLEGAL REQUEST asc:20,0 (pass2:ahd0:0:2:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass2:ahd0:0:2:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 a1 0 (pass2:ahd0:0:2:0): CAM Status: SCSI Status Error (pass2:ahd0:0:2:0): SCSI Status: Check Condition (pass2:ahd0:0:2:0): ILLEGAL REQUEST asc:20,0 (pass2:ahd0:0:2:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass3:ahd0:0:3:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 ec 0 (pass3:ahd0:0:3:0): CAM Status: SCSI Status Error (pass3:ahd0:0:3:0): SCSI Status: Check Condition (pass3:ahd0:0:3:0): ILLEGAL REQUEST asc:20,0 (pass3:ahd0:0:3:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 (pass3:ahd0:0:3:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 a1 0 (pass3:ahd0:0:3:0): CAM Status: SCSI Status Error (pass3:ahd0:0:3:0): SCSI Status: Check Condition (pass3:ahd0:0:3:0): ILLEGAL REQUEST asc:20,0 (pass3:ahd0:0:3:0): Invalid command operation code field replaceable unit: 2: Command byte 0 bit 7 is invalid This is printed right after smartd (from smartmontools) is started, and I think it's what it causes these messages. I guess they are harmless too? --Niki From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 15:52:25 2008 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 20A6E16A418; Sun, 17 Feb 2008 15:52:25 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id C97F413C459; Sun, 17 Feb 2008 15:52:24 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from [192.168.0.6] (tumnus.scsiguy.org [192.168.0.6]) (authenticated bits=0) by aslan.scsiguy.com (8.14.2/8.14.2) with ESMTP id m1HFqK6a089558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 08:52:21 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <47B8582A.3020402@scsiguy.com> Date: Sun, 17 Feb 2008 08:52:10 -0700 From: "Justin T. Gibbs" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Niki Denev References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> <2e77fc10802170623k181c807dh52b13b01c121cd9f@mail.gmail.com> In-Reply-To: <2e77fc10802170623k181c807dh52b13b01c121cd9f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 15:52:25 -0000 Niki Denev wrote: > After some bonnie64 runs the first machine (8.0-CURRENT Dtrace > snapshot with aic79xx_osm.c v1.30) spat out this : > > ahd1: Recovery Initiated - Card was not paused >>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< > ahd1: Dumping Card State at program address 0x38 Mode 0x11 ... > SAVED_MODE[0x11] DFFSTAT[0x31]:(CURRFIFO_1|FIFO0FREE|FIFO1FREE) > SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] > LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] According to the controller, the bus is idle. However... > Pending list: > 325 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > 403 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > 439 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > 380 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > 495 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > 353 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > 478 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > Total 7 we have 7 commands still pending on the drive at ID 1, and the drive hasn't provided status within the allowed timeout period. There were lots of problems early on with Seagate drives locking up like this when hit with more than 31 (I think that was the magic number) concurrent commands with WCE (write cache enable) set. It was supposedly fixed in later firmware releases. Do you have the latest firmware for your drives? You might be able to confirm this hypothesis by lowering the queued depth via camcontrol and/or disabling WCE. -- Justin From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 15:58:25 2008 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 C48F916A417 for ; Sun, 17 Feb 2008 15:58:25 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 94B4F13C467 for ; Sun, 17 Feb 2008 15:58:25 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from [192.168.0.6] (tumnus.scsiguy.org [192.168.0.6]) (authenticated bits=0) by aslan.scsiguy.com (8.14.2/8.14.2) with ESMTP id m1HFwM6e089601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 08:58:23 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <47B85995.8030804@scsiguy.com> Date: Sun, 17 Feb 2008 08:58:13 -0700 From: "Justin T. Gibbs" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Niki Denev References: <200704182239.59842.gelsemap@superhero.nl> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> <47B8547E.7080103@scsiguy.com> <2e77fc10802170748g757e569ejb079f849cf879668@mail.gmail.com> In-Reply-To: <2e77fc10802170748g757e569ejb079f849cf879668@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 15:58:25 -0000 Niki Denev wrote: > > Sorry, I must have missed the full output : > > Copied 18 bytes of sense data offset 12: 0x70 0x0 0x5 0x0 0x0 0x0 0x0 > 0xa 0x0 0x0 0x0 0x0 0x20 0x0 0x2 0xcf 0x0 0x0 > (pass0:ahd0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 > 0 0 0 0 ec 0 > (pass0:ahd0:0:0:0): CAM Status: SCSI Status Error > (pass0:ahd0:0:0:0): SCSI Status: Check Condition > (pass0:ahd0:0:0:0): ILLEGAL REQUEST asc:20,0 > (pass0:ahd0:0:0:0): Invalid command operation code field replaceable opcode 0x85 is ATA command pass-through. I'm not surprised that your drive rejects it. > This is printed right after smartd (from smartmontools) is started, > and I think it's what it causes these messages. > I guess they are harmless too? I'm not familiar with this opcode or why its being used (for quering ATA devices within an array with a SCSI front-end?), but its probably harmless too. -- Justin From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 16:02:01 2008 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 8C70C16A479 for ; Sun, 17 Feb 2008 16:02:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6146413C45A for ; Sun, 17 Feb 2008 16:02:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1114530rvb.43 for ; Sun, 17 Feb 2008 08:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8apGZCzsdFRmO33U7yiLqbQpTETiTu2VDAl2mTmoVsw=; b=VjWDHNITtjbOVd7hNpnD+uik4Vhe9S4sGGhr2V+/K1+pauIWsMTE5rmf9VHEfrPE3qLMzF6KOVOu+p6/jiH9P2VnwYiX4yNCJbOTQ+3HdHkjY8eTbu9MUbCgWAXJB57EJDBnniCwOouOmidCuk1jjngSr4jdKZLgEfniPpLSGYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=P7+PFzjvHq9bJE7eHuupPqVS5DFfngcQV0qu5RUaVC2AkOvHY4WNgPIaqbMK6TPsvtnNm0+x8RD7QhgpOvtTzSqJNlPG0fkqWxHGYPfqG0ldTkeoRlLsjMr8Yb1M31A1+L6JGer44fWmXlGTk2jHW69xQVpDzly/Cf4PE3WVGFk= Received: by 10.141.99.4 with SMTP id b4mr3195137rvm.208.1203264120502; Sun, 17 Feb 2008 08:02:00 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sun, 17 Feb 2008 08:02:00 -0800 (PST) Message-ID: <2e77fc10802170802w16fa5d6oe1e03b4660a7e85@mail.gmail.com> Date: Sun, 17 Feb 2008 16:02:00 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: "Justin T. Gibbs" In-Reply-To: <47B8582A.3020402@scsiguy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704182239.59842.gelsemap@superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2e77fc10802170142r51719253r682365fb7d274116@mail.gmail.com> <2e77fc10802170623k181c807dh52b13b01c121cd9f@mail.gmail.com> <47B8582A.3020402@scsiguy.com> X-Google-Sender-Auth: 380f04fa9beec116 Cc: freebsd-current@freebsd.org Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 16:02:01 -0000 On Feb 17, 2008 3:52 PM, Justin T. Gibbs wrote: > Niki Denev wrote: > > After some bonnie64 runs the first machine (8.0-CURRENT Dtrace > > snapshot with aic79xx_osm.c v1.30) spat out this : > > > > ahd1: Recovery Initiated - Card was not paused > >>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< > > ahd1: Dumping Card State at program address 0x38 Mode 0x11 > > ... > > > SAVED_MODE[0x11] DFFSTAT[0x31]:(CURRFIFO_1|FIFO0FREE|FIFO1FREE) > > SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] > > LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] > > According to the controller, the bus is idle. However... > > > Pending list: > > 325 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > 403 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > 439 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > 380 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > 495 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > 353 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > 478 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x17] > > Total 7 > > we have 7 commands still pending on the drive at ID 1, and the drive hasn't > provided status within the allowed timeout period. There were lots of > problems early on with Seagate drives locking up like this when hit with > more than 31 (I think that was the magic number) concurrent commands with > WCE (write cache enable) set. It was supposedly fixed in later firmware > releases. Do you have the latest firmware for your drives? No, they are with the default factory set firmware, probably years old, i will try to upgrade them. > You might be able to confirm this hypothesis by lowering the queued depth > via camcontrol and/or disabling WCE. I will definitely try this if I'm able to reproduce the error, because I'm seeng probably Dtrace related panic on this machine, that I'm trying to investigate. > -- > Justin > --Niki From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 16:33:18 2008 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 C7DF316A418 for ; Sun, 17 Feb 2008 16:33:18 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 6466A13C467 for ; Sun, 17 Feb 2008 16:33:18 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id m1HGXGss010921 (8.13.4/1.4); Sun, 17 Feb 2008 17:33:16 +0100 (MET) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id m1HGXGnd010918 (8.13.4/2.02); Sun, 17 Feb 2008 17:33:16 +0100 (MET) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 17 Feb 2008 17:33:16 +0100 (MET) From: Michiel Boland To: freebsd-current@freebsd.org In-Reply-To: <20080217160642.2ac9363e@peedub.jennejohn.org> Message-ID: References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217160642.2ac9363e@peedub.jennejohn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: PRINTF_BUFR_SIZE (Re: 7.0 RC2 kernel panic with Kqemu/AMD64) 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, 17 Feb 2008 16:33:18 -0000 On Sun, 17 Feb 2008, Gary Jennejohn wrote: [...] > I can't help with your problem, but I suggest that you add > options PRINTF_BUFR_SIZE=128 > to your kernel config file to avoid the above corrupted output. Any reason why this PRINTF_BUFR_SIZE option isn't in GENERIC on all platforms? At the moment it is set for sun4v only. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 16:40:07 2008 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 861DA16A41A for ; Sun, 17 Feb 2008 16:40:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (unknown [IPv6:2001:41c8:1:548a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 299B113C469 for ; Sun, 17 Feb 2008 16:40:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from [IPv6:2a01:348:10f:0:e182:aabd:b390:9889] (unknown [IPv6:2a01:348:10f:0:e182:aabd:b390:9889]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id D5C4B30162; Sun, 17 Feb 2008 16:40:04 +0000 (GMT) Message-ID: <47B8634D.4080506@cran.org.uk> Date: Sun, 17 Feb 2008 16:39:41 +0000 From: Bruce Cran User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michiel Boland References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217160642.2ac9363e@peedub.jennejohn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: PRINTF_BUFR_SIZE (Re: 7.0 RC2 kernel panic with Kqemu/AMD64) 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, 17 Feb 2008 16:40:07 -0000 Michiel Boland wrote: > On Sun, 17 Feb 2008, Gary Jennejohn wrote: > > [...] >> I can't help with your problem, but I suggest that you add >> options PRINTF_BUFR_SIZE=128 >> to your kernel config file to avoid the above corrupted output. > > Any reason why this PRINTF_BUFR_SIZE option isn't in GENERIC on all > platforms? At the moment it is set for sun4v only. > > Cheers > Michiel Because the interleaved output is a feature, not a bug. -- Bruce From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 16:47:34 2008 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 D6EB316A46C for ; Sun, 17 Feb 2008 16:47:34 +0000 (UTC) (envelope-from markus@FreeBSD.org) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mx1.freebsd.org (Postfix) with ESMTP id 206C513C4D9 for ; Sun, 17 Feb 2008 16:47:34 +0000 (UTC) (envelope-from markus@FreeBSD.org) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id E601527AC7F; Sun, 17 Feb 2008 16:42:30 +0100 (CET) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id D85D06BD71; Sun, 17 Feb 2008 16:42:30 +0100 (CET) Received: from galaxy.homeunix.org (dslb-084-061-000-159.pools.arcor-ip.net [84.61.0.159]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 8D81E30AC40; Sun, 17 Feb 2008 16:42:30 +0100 (CET) Received: from cheops.phoenix (cheops.phoenix [192.168.1.3]) by galaxy.homeunix.org (Postfix) with ESMTP id BB64A3F455; Sun, 17 Feb 2008 16:39:45 +0100 (CET) From: Markus Brueffer To: freebsd-current@freebsd.org Date: Sun, 17 Feb 2008 16:41:59 +0100 User-Agent: KMail/1.9.7 References: <47B20739.1050602@chuckr.org> <20080216121241.450ff175@deskjail> <47B79A48.1030406@chuckr.org> In-Reply-To: <47B79A48.1030406@chuckr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5572139.TovlfbE5Tt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802171642.04403.markus@FreeBSD.org> X-Virus-Scanned: ClamAV 0.92.1/5847/Sun Feb 17 12:26:12 2008 on mail-in-03.arcor-online.net X-Virus-Status: Clean Cc: Chuck Robey , Alexander Leidinger Subject: Re: about usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 16:47:34 -0000 --nextPart5572139.TovlfbE5Tt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 17. Februar 2008 03:22:00 schrieb Chuck Robey: > I am still having a miserable time trying to figure out the HID spec, and > Kai Wang deserves being nominated for Sainthood, for putting up with my > horde of stupid questions. If anyone knows of a HID device which has a > published [HID report in hex, Parsed output, and comments on how it got > from one to the other] I would give nearly anything for such a thing > (anything I happen to have, which doesn't happen to include cash right > now). This is the raw report descriptor of a very simple device: an Apple Mighty= =20 Mouse: 0x05 0x01 0x09 0x02 0xa1 0x01 0x05 0x09 0x19 0x01 0x29 0x04 0x15 0x00 0x25 0x01 0x95 0x04 0x75 0x01 0x81 0x02 0x95 0x01 0x75 0x04 0x81 0x01 0x05 0x01 0x09 0x01 0xa1 0x00 0x09 0x30 0x09 0x31 0x09 0x32 0x09 0x38 0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x04 0x81 0x06 0xc0 0x05 0xff 0x09 0xc0 0x75 0x08 0x95 0x01 0x81 0x02 0xc0 Decoding it works as follows: Let's look at the first byte 0x05. The binary representation is 00000101. Splitting this up as described in chapter 6.2.2.2 gives the following (in=20 binary representation): bTag=3D0000 bType=3D01 bSize=3D01 =46irst, as bTag is not 1111, we know that this is not a long item (see=20 6.2.2.3). So this must be a short item. bType tells us that this is a global item (6.2.2.2). Finally bSize specifie= s=20 the number of following bytes that belong to this item which is 1 in this=20 case. So, looking back at the raw descriptor we know now that the sequence= =20 0x05 0x01 forms one item. We also know that it is a short item and that it = is=20 a global item. What we don't know yet is, what global item this is. For thi= s,=20 we have to look at bTag again. As we know that this is a global item, we ta= ke=20 a look at chapter 6.2.2.7 "Global Items". It tells us that 0000 stands for= =20 Usage Page. Which usage page is meant is encoded in the data part of the=20 item, which is 0x01. From the HID Usage Tables document Chapter 3 we learn= =20 that 0x01 stands for "Generic Desktop Controls". This gives us the followin= g=20 for the first item: 0x05 0x01 USAGE_PAGE (Generic Desktop) Now the second item beginning with 0x09: Binary representation is 00001001.= =20 Splitting this up yields: bTag=3D0000 bType=3D10 bSize=3D01 Again this is a short item as bTag !=3D 1111. bType is a decimal 2 and chap= ter=20 6.2.2.2 tells us that this is a local item. Advancing to chapter=20 6.2.2.7 "Local Items" gives us the meaning for bTag, which is "Usage". As=20 bSize is 1, only the next byte in the report descriptor is considered for t= he=20 data of the item, so the usage is 0x02. Looking at the HID Usage Tables=20 document again, this time chapter 4, as we already learned that this usage= =20 belongs to the usage page Generic Desktop, we see that 0x02 is equivalent=20 to "Mouse". Now we have: 0x05 0x01 USAGE_PAGE (Generic Desktop) 0x09 0x02 USAGE (Mouse) Up to the next item which begins with 0xa1, binary 10100001: bTag=3D1010 bType=3D00 bSize=3D01 Again this is a short item as bTag !=3D 1111. bType is 0, which stands for = Main=20 Item, according to chapter 6.2.2.2. Looking at chapter 6.2.2.4, we learn th= at=20 the bTag of 1010 actually means "Collection". The data part of 1 byte (see= =20 bSize), which is in this case 0x01 tells us that this is an "Application=20 Collection". So, now we have: 0x05 0x01 USAGE_PAGE (Generic Desktop) 0x09 0x02 USAGE (Mouse) 0xa1 0x01 COLLECTION (Application) If you continue decoding it this way, you will finally get the following: 0x05 0x01 USAGE_PAGE (Generic Desktop) 0x09 0x02 USAGE (Mouse) 0xa1 0x01 COLLECTION (Application) 0x05 0x09 USAGE_PAGE (Button) 0x19 0x01 USAGE_MINIMUM (Button 1) 0x29 0x04 USAGE_MAXIMUM (Button 4) 0x15 0x00 LOGICAL_MINIMUM (0) 0x25 0x01 LOGICAL_MAXIMUM (1) 0x95 0x04 REPORT_COUNT (4) 0x75 0x01 REPORT_SIZE (1) 0x81 0x02 INPUT (Data, Var, Abs) 0x95 0x01 REPORT_COUNT (1) 0x75 0x04 REPORT_SIZE (4) 0x81 0x01 INPUT (Const, Var, Abs) 0x05 0x01 USAGE_PAGE (Generic Desktop) 0x09 0x01 USAGE (Pointer) 0xa1 0x00 COLLECTION (Physical) 0x09 0x30 USAGE (X) 0x09 0x31 USAGE (Y) 0x09 0x32 USAGE (Z) 0x09 0x38 USAGE (WHEEL) 0x15 0x81 LOGICAL_MINIMUM (0x81) 0x25 0x7f LOGICAL_MAXIMUM (0x7f) 0x75 0x08 REPORT_SIZE (8) 0x95 0x04 REPORT_COUNT (4) 0x81 0x06 INPUT (Data, Var, Rel) 0xc0 END COLLECTION 0x05 0xff USAGE_PAGE (0xff) 0x09 0xc0 USAGE (0xc0) 0x75 0x08 REPORT_SIZE (8) 0x95 0x01 REPORT_COUNT (1) 0x81 0x02 INPUT (Data, Var, Abs) 0xc0 To actually give meaning to the decoded descriptor, you have to learn how=20 local, global and main items relate to each other. Main items are actually= =20 the most important ones, as they directly correlate to physical controls of= =20 your device (apart from the collection items). Global and local items=20 describe the different main items, whereas local items only describe the ne= xt=20 main item. Global items instead keep their state accross main items until=20 they are specified again or are being overrriden by a local item. In this example we have several main items. Lets have a look at the first o= ne 0x05 0x01 USAGE_PAGE (Generic Desktop) 0x09 0x02 USAGE (Mouse) 0xa1 0x01 COLLECTION (Application) This is an application collection. Usage page and usage describe the contex= t=20 of the items that are within it, so we have: Collection page=3DGeneric_Desktop usage=3DMouse The next item is a bit more interresting. It's an input item: 0x05 0x09 USAGE_PAGE (Button) 0x19 0x01 USAGE_MINIMUM (Button 1) 0x29 0x04 USAGE_MAXIMUM (Button 4) 0x15 0x00 LOGICAL_MINIMUM (0) 0x25 0x01 LOGICAL_MAXIMUM (1) 0x95 0x04 REPORT_COUNT (4) 0x75 0x01 REPORT_SIZE (1) 0x81 0x02 INPUT (Data, Var, Abs) It actually describes 4 controls (report count). The meaning of these 4=20 controls is specified by the usage page and usage min/max. In this case=20 Button 1 - Button 4. Logical min/max are 0 and 1 and mean that the range of= =20 the data in the data stream, that is submitted by the device, is between 0= =20 and 1, which is actually only 0 and 1 in this case. Report size finally giv= es=20 the size in the data stream for each button state that is submitted by the= =20 device in number of bits. Now we have: Collection page=3DGeneric_Desktop usage=3DMouse Input size=3D1 count=3D1 page=3DButton usage=3DButton_1, logical range 0.= =2E1 Input size=3D1 count=3D1 page=3DButton usage=3DButton_2, logical range 0.= =2E1 Input size=3D1 count=3D1 page=3DButton usage=3DButton_3, logical range 0.= =2E1 Input size=3D1 count=3D1 page=3DButton usage=3DButton_4, logical range 0.= =2E1 The next input item is a const item, which is being used for padding in thi= s=20 case. It can be ignored. In the end we get the following: Collection page=3DGeneric_Desktop usage=3DMouse Input size=3D1 count=3D1 page=3DButton usage=3DButton_1, logical range 0.= =2E1 Input size=3D1 count=3D1 page=3DButton usage=3DButton_2, logical range 0.= =2E1 Input size=3D1 count=3D1 page=3DButton usage=3DButton_3, logical range 0.= =2E1 Input size=3D1 count=3D1 page=3DButton usage=3DButton_4, logical range 0.= =2E1 Input size=3D4 count=3D1 page=3D0x0000 usage=3D0x0000 Const, logical rang= e 0..1 Collection page=3DGeneric_Desktop usage=3DPointer Input size=3D8 count=3D1 page=3DGeneric_Desktop usage=3DX, logical range = =2D127..127 Input size=3D8 count=3D1 page=3DGeneric_Desktop usage=3DY, logical range = =2D127..127 Input size=3D8 count=3D1 page=3DGeneric_Desktop usage=3DZ, logical range = =2D127..127 Input size=3D8 count=3D1 page=3DGeneric_Desktop usage=3DWheel, logical=20 range -127..127 End collection Input size=3D8 count=3D1 page=3D0x00ff usage=3D0x00c0, logical range -127= =2E.127 End collection This actually means, that the mouse reports 6 bytes of data in each=20 transmission. The first 4 bits indicate the button states, the next 4 bits= =20 can be ignored. Byte 2 reports the X axis state, byte 3, 4 and 5 data for Y= ,=20 Z and the wheel. The last byte reports vendor specific data (usage page=20 0x00ff). That's it in short. There is of course much to learn regarding the details,= =20 but it should give you a general overview of how this works. Markus --nextPart5572139.TovlfbE5Tt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHuFXM1I0Qcnj4qNQRAg9bAKCWK1PRol2EAVAgTUpfU/AhJmKzNwCg/yXZ yW806VV205ScIpHVm/gMAag= =MhWu -----END PGP SIGNATURE----- --nextPart5572139.TovlfbE5Tt-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 16:50:41 2008 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 EA4E816A468 for ; Sun, 17 Feb 2008 16:50:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E30413C4CC; Sun, 17 Feb 2008 16:50:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47B865E0.20407@FreeBSD.org> Date: Sun, 17 Feb 2008 17:50:40 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Michiel Boland References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217160642.2ac9363e@peedub.jennejohn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: PRINTF_BUFR_SIZE (Re: 7.0 RC2 kernel panic with Kqemu/AMD64) 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, 17 Feb 2008 16:50:42 -0000 Michiel Boland wrote: > On Sun, 17 Feb 2008, Gary Jennejohn wrote: > > [...] >> I can't help with your problem, but I suggest that you add >> options PRINTF_BUFR_SIZE=128 >> to your kernel config file to avoid the above corrupted output. > > Any reason why this PRINTF_BUFR_SIZE option isn't in GENERIC on all > platforms? At the moment it is set for sun4v only. > > Cheers > Michiel > _______________________________________________ > 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 think the fear is that it could cause a stack overflow because it allocates a character array (128-bytes in the above case) on the stack. I would like to know how real this fear is though. Clearly we do need a way to avoid interleaving console output by default. Kris From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 17:23:58 2008 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 82E8616A418 for ; Sun, 17 Feb 2008 17:23:58 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 1E27D13C4DD for ; Sun, 17 Feb 2008 17:23:57 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1131205rvb.43 for ; Sun, 17 Feb 2008 09:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ZAhsQICxaj6KyE/ylLBb+CqC5EmxR+96PQMh8XmNfzk=; b=kD0QQbl4ke9bqk/dsgAjqdPjiu/viTT/e9XHAiUiyHTRX3uvxVnnqBczuD0dZLhPT4pv8vfqBShtEwVecTbBJu/hz7W1m21EpaOGJcWgksrVMOZ55w3BvPO/aTvZApwwrJPQH3MdiLp6k8n9t+sqTy7B0spMLx9nn+ClLuTjNm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kD+1Ht0dGd+LfDjppiTMFVfwjjufMlKj5Vw631Eb0J2oN0MyhrIvoEeQKcjoincJnExvAwmaRHdvhusNjaHhV/tVPZUT2/Swupc+8zpCZO5NKsOil23mPsj3un17ODe92CbSK1Nx/sU3Fpj0Uz27rfrmMtJySC4OdPTj8rZNlpI= Received: by 10.141.79.12 with SMTP id g12mr3255914rvl.182.1203269036519; Sun, 17 Feb 2008 09:23:56 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sun, 17 Feb 2008 09:23:55 -0800 (PST) Message-ID: <2e77fc10802170923v565dfc0pa07f10f4666ab088@mail.gmail.com> Date: Sun, 17 Feb 2008 17:23:55 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: "John Birrell" In-Reply-To: <20080216234246.GA27115@what-creek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080210224247.GA70317@what-creek.com> <47B764D5.8040305@portaone.com> <20080216234246.GA27115@what-creek.com> X-Google-Sender-Auth: 82ead5b4d4fa1aad X-Mailman-Approved-At: Sun, 17 Feb 2008 17:42:55 +0000 Cc: freebsd-current@freebsd.org Subject: Re: New DTrace source snapshot 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, 17 Feb 2008 17:23:58 -0000 On Feb 16, 2008 11:42 PM, John Birrell wrote: > On Sun, Feb 17, 2008 at 12:33:57AM +0200, Andrew Pogrebennyk wrote: > > Snapshot dtrace-20080211.tar.bz compiled well for me on i386. However > > during boot with DTrace I am getting the following tracebacks: > > > > GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install. > > WARNING: WITNESS option enabled, expect reduced performance. > > lock order reversal: > > The lock order reversal warnings are a fault with current at the > moment. If I had my way the cause would be backed out until there > is a solution. I understand that it is a witness improvment that > has caused the warnings to start appearing.... meaning that the > change has exposed an existing problem that wasn't warned obut > before. > > They certainly aren't DTrace change specific. > > > sh*:::line > > { > > @lines[pid, uid, copyinstr(arg0)] = count(); > > } > > There is no sh provider yet. > > -- > John Birrell > I've had several panics while running Bonnie64 benchmars on ZFS on the Dtrace snapshot. I'm not entirely sure if this is Dtrace or ZFS related (the backtrace shows dtrace functions), but here is what textdump shows anyways : vertsion : FreeBSD 8.0-CURRENT #3: Sun Feb 17 16:38:29 EET 2008 root@tester69:/usr/obj/usr/src/sys/GENERIC*** *** This is GENERIC from the DTrace snapshot with INVARIANTS and WITNESS turned off panic message : spin lock held too long msgbuf : spin lock 0xffffffff80aad760 (smp rendezvous) held by 0xffffff000b02d6e0 (tid 100080) too long panic: spin lock held too long cpuid = 1 KDB: enter: panic db:0:kdb.enter.panic> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xffffff000b486370: pid 141 "spa_zio_intr_2" curpcb = 0xffffffffd83e6d40 fpcurthread = none idlethread = 0xffffff0002234370: pid 11 "idle: cpu0" cpuid = 1 curthread = 0xffffff0002dde6e0: pid 34 "arc_reclaim_thread" curpcb = 0xffffffffd5f99d40 fpcurthread = none idlethread = 0xffffff00022346e0: pid 11 "idle: cpu1" db:0:kdb.enter.panic> bt Tracing pid 34 tid 100051 td 0xffffff0002dde6e0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at _mtx_lock_spin+0x9e smp_rendezvous_cpus() at smp_rendezvous_cpus+0xe1 dtrace_xcall() at dtrace_xcall+0x6a dtrace_dynvar_clean() at dtrace_dynvar_clean+0xbe dtrace_state_clean() at dtrace_state_clean+0x29 cyclic_clock() at cyclic_clock+0x12b lapic_handle_timer() at lapic_handle_timer+0x8b Xtimerint() at Xtimerint+0x67 --- interrupt, rip = 0xffffffff80c444e5, rsp = 0xffffffffd5f99b60, rbp = 0xffffffffd5f99b80 --- arc_do_user_evicts() at arc_do_user_evicts+0x85 arc_reclaim_thread() at arc_reclaim_thread+0x1db fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffd5f99d30, rbp = 0 --- Full textdump (debug.ddb.scripting.scripts="textdump set; capture on; show pcpu; bt; show locks; ps; alltrace; show lockedvnods; show alllocks; capture off; call doadump; reset") here : http://bg.freebsd.org/~ndenev/crashdumps/textdump_of_dtrace_or_zfs_panic.tar --Niki From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 17:50:45 2008 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 5396E16A417 for ; Sun, 17 Feb 2008 17:50:45 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id A8A3A13C46E for ; Sun, 17 Feb 2008 17:50:44 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 54594 invoked by uid 80); 17 Feb 2008 17:23:41 -0000 Received: from 10.202.77.197 (SquirrelMail authenticated user gelsemap) by webmail.superhero.nl with HTTP; Sun, 17 Feb 2008 18:23:41 +0100 (CET) Message-ID: <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> In-Reply-To: <47B7D534.7000204@scsiguy.com> References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> Date: Sun, 17 Feb 2008 18:23:41 +0100 (CET) From: "Gelsema, P \(Patrick\) - FreeBSD" To: "Justin T. Gibbs" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Gelsema, P \(Patrick\)" , Niki Denev , freebsd-current@freebsd.org, JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 17:50:45 -0000 On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: > Niki Denev wrote: > > I was playing around with DTrace, tracing cam/xpt and the ahd driver > and > > found out that if i comment the following code : > > > > if ((spi3caps & SID_SPI_IUS) == 0) > > spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : > > > > da0 at ahd0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-3 device > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > da0: Command Queueing Enabled > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > The aic79xx driver was not properly exporting its capabilities to > CAM. This has been addressed as of version 1.30 of aic79xx_osm.c. > Please let me know if you still have problems. hulk# uname -a FreeBSD hulk.superhero.nl 7.0-RC2 FreeBSD 7.0-RC2 #0: Sun Feb 17 17:58:36 CET 2008 admin@hulk.superhero.nl:/usr/obj/usr/src/sys/GENERIC amd64 hulk# camcontrol inquiry da1 pass1: Fixed Direct Access SCSI-3 device pass1: Serial Number 3HX35KPH000075191ZRW pass1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Command Queueing Enabled Working. Thanks! Any chance of mfc-ing this to RELENG_7_0 before 7_0 gets released? Rgds, Patrick > > > > > Unfortunately I began seeing again the "Invalid sequencer interrupt" > > messages that i was seeing before(with fbsd 6.2) with Seagate drives > > on Adaptec at U320 speeds, and I prey that they are harmless (as they > > used to be?) > > While I do not know their root cause, they do appear to be harmless. > Do you happen to have your drives in a SES enclosure (on a backplane > with a SES chip)? One user claimed this was only reproducible when > a GEM318 SES chip was on the bus. > > -- > Justin > > From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 17:55:30 2008 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 5185F16A41B for ; Sun, 17 Feb 2008 17:55:30 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id E6AC813C467 for ; Sun, 17 Feb 2008 17:55:29 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 03C643F61CD for ; Sun, 17 Feb 2008 18:55:27 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id CEE5F3F61C5 for ; Sun, 17 Feb 2008 18:55:26 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id C57AA9BF12; Sun, 17 Feb 2008 17:50:29 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id AE97D405D; Sun, 17 Feb 2008 18:50:29 +0100 (CET) Date: Sun, 17 Feb 2008 18:50:29 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20080217175029.GD92006@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Jeremie Le Hen Subject: Fiddling psm(4) config flags 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, 17 Feb 2008 17:55:30 -0000 Hi list, When I enabled ACPI on my laptop, my mouse doesn't work anymore. I've enabled PSM_DEBUG and it seems the drivers fails here in psmprobe(): % if (sc->config & PSM_CONFIG_NORESET) { % /* % * Don't try to reset the pointing device. It may possibly be % * left in the unknown state, though... % */ % } else { % /* % * NOTE: some controllers appears to hang the `keyboard' when the aux % * port doesn't exist and `PSMC_RESET_DEV' is issued. % * % * Attempt to reset the controller twice -- this helps % * pierce through some KVM switches. The second reset % * is non-fatal. % */ % if (!reset_aux_dev(sc->kbdc)) { % recover_from_error(sc->kbdc); % restore_controller(sc->kbdc, command_byte); % if (verbose) % ==> printf("psm%d: failed to reset the aux device.\n", unit); % endprobe(ENXIO); % } else if (!reset_aux_dev(sc->kbdc)) { % recover_from_error(sc->kbdc); % if (verbose >= 2) % printf("psm%d: failed to reset the aux device (2).\n", % unit); % } % } If anyone understands what's the problem, please let me know. If I fiddle the source code to do as if PSM_CONFIG_NORESET was set, my mouse works. ``sc->config'' is set with device_get_flags(): % sc->config = device_get_flags(dev) & PSM_CONFIG_FLAGS; device_get_flags() returns ``dev->devflags'', but I don't know how to set this. I would say I should do this from /boot/device.hints or something like this, but I couldn't find any documentation about it. Any pointer please? Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 18:04:11 2008 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 5C15E16A418; Sun, 17 Feb 2008 18:04:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0931D13C478; Sun, 17 Feb 2008 18:04:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [10.134.22.37] ([166.133.239.16]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m1HI3tdm004304; Sun, 17 Feb 2008 11:04:02 -0700 (MST) (envelope-from scottl@samsco.org) References: <200704182239.59842.gelsemap@superhero.nl> <86tzvcvaai.fsf@dwp.des.no> <31439.195.50.100.20.1176984826.squirrel@www.superhero.nl> <20080211184453.GA5605@dragon.NUXI.org> <2e77fc10802111330p738d2c93i9eb1189b307d732d@mail.gmail.com> <47B0C34E.7040804@samsco.org> <20080212010836.GA14441@dragon.NUXI.org> <2e77fc10802161506x5d790149lb688d221b0a96222@mail.gmail.com> <47B7D534.7000204@scsiguy.com> <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> Message-Id: From: Scott Long To: "Gelsema, P (Patrick) - FreeBSD" , re In-Reply-To: <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes X-Mailer: iPhone Mail (3A109a) Mime-Version: 1.0 (iPhone Mail 3A109a) Content-Transfer-Encoding: 7bit Date: Sun, 17 Feb 2008 11:03:40 -0700 X-Spam-Status: No, score=0.0 required=5.4 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: "Gelsema, P \(Patrick\)" , Niki Denev , "freebsd-current@freebsd.org" , JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 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, 17 Feb 2008 18:04:11 -0000 I approve of whatever justin does with the aic79xx driver for 7.0. Should just be a simple tweak and nothing more. Scott Sent from my iPhone On Feb 17, 2008, at 10:23 AM, "Gelsema, P \(Patrick\) - FreeBSD" wrote: > On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: >> Niki Denev wrote: >>> I was playing around with DTrace, tracing cam/xpt and the ahd driver >> and >>> found out that if i comment the following code : >>> >>> if ((spi3caps & SID_SPI_IUS) == 0) >>> spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; >>> >>> at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : >>> >>> da0 at ahd0 bus 0 target 0 lun 0 >>> da0: Fixed Direct Access SCSI-3 device >>> da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) >>> da0: Command Queueing Enabled >>> da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) >> >> The aic79xx driver was not properly exporting its capabilities to >> CAM. This has been addressed as of version 1.30 of aic79xx_osm.c. >> Please let me know if you still have problems. > > hulk# uname -a > FreeBSD hulk.superhero.nl 7.0-RC2 FreeBSD 7.0-RC2 #0: Sun Feb 17 > 17:58:36 > CET 2008 admin@hulk.superhero.nl:/usr/obj/usr/src/sys/GENERIC > amd64 > > hulk# camcontrol inquiry da1 > pass1: Fixed Direct Access SCSI-3 device > pass1: Serial Number 3HX35KPH000075191ZRW > pass1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Command > Queueing Enabled > > Working. Thanks! > > Any chance of mfc-ing this to RELENG_7_0 before 7_0 gets released? > > Rgds, > > Patrick > >> >>> >>> Unfortunately I began seeing again the "Invalid sequencer interrupt" >>> messages that i was seeing before(with fbsd 6.2) with Seagate drives >>> on Adaptec at U320 speeds, and I prey that they are harmless (as >>> they >>> used to be?) >> >> While I do not know their root cause, they do appear to be harmless. >> Do you happen to have your drives in a SES enclosure (on a backplane >> with a SES chip)? One user claimed this was only reproducible when >> a GEM318 SES chip was on the bus. >> >> -- >> Justin >> >> > From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 18:54:06 2008 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 E301416A41A for ; Sun, 17 Feb 2008 18:54:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 942B313C457 for ; Sun, 17 Feb 2008 18:54:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=f6SdBr0ImW/JWXQieU7r5HOZ5LZN2u0CPpXjuFOt1xlRSbxvJM+Sb2qqGHvEkJ87Jv3rnVfrv6IbPH0aWT9yYF6B818NmgziER1Qwix5uRs0jYy5psLVckQbacUg22s3S8G5YqxuZOrpbn2jci5XfW29VS0ap/u1xCFXU6x5/Sg=; Received: from amnesiac.at.no.dns (ppp85-141-160-36.pppoe.mtu-net.ru [85.141.160.36]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JQoeK-000DJ3-Rm; Sun, 17 Feb 2008 21:54:05 +0300 Date: Sun, 17 Feb 2008 21:53:57 +0300 From: Eygene Ryabinkin To: Dag-Erling Sm??rgrav Message-ID: References: <86r6fdx0tf.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <86r6fdx0tf.fsf@ds4.des.no> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0-RC2 Available 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, 17 Feb 2008 18:54:07 -0000 Dag-Erling, good day. Sat, Feb 16, 2008 at 12:22:04AM +0100, Dag-Erling Sm??rgrav wrote: > > Seems like the old 2:1 rule is not very cost-effective for common > > setups, but, again, it depends on the situation. > > Not cost-effective? What is the "street price" of 16 GB disk space > these days? About the same as a couple of Big Macs? Hmm, I would better spend these 16 Gb for the log storage, because in my common setups with 8Gb/16Gb/32Gb memory at FreeBSD production servers, swap is truly redundant. But again, it depends on the situation ;)) But if we're measuring 16 Gb of ATA/SATA disk in dollars, then yes, you're right: it is $10 or about 4 or 5 Big Macs in my nearby McDonalds. I really don't know will it be 4 or 5: I don't like these biggies and prefer cheeseburgers. Now they are selling them at 1.28 Gb per one cheeseburger, so this is a good deal ;)) -- Eygene From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 19:19:42 2008 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 EF67616A418; Sun, 17 Feb 2008 19:19:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id A396313C467; Sun, 17 Feb 2008 19:19:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id AF63643E4C8; Sun, 17 Feb 2008 21:19:40 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id MZSxw7RNNx8E; Sun, 17 Feb 2008 21:19:40 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id DDAD343DF8F; Sun, 17 Feb 2008 21:19:39 +0200 (EET) Message-ID: <47B888C7.6020504@icyb.net.ua> Date: Sun, 17 Feb 2008 21:19:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org, freebsd-current@freebsd.org References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> <20080130164508.GC6257@suse.cz> <47A2E7E5.1040307@icyb.net.ua> <20080201093806.GA4632@suse.cz> <47A738AE.5070900@icyb.net.ua> <47AB29D4.1040409@icyb.net.ua> In-Reply-To: <47AB29D4.1040409@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ps/2 mouse patch [intellimouse explorer detection] 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, 17 Feb 2008 19:19:43 -0000 This is an annoying reminder :-) that FreeBSD psm driver still incorrectly probes mice for MS Intellimouse Explorer protocol. http://www.microsoft.com/whdc/device/input/5b_wheel.mspx http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118578 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 20:56:51 2008 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 C48B816A417; Sun, 17 Feb 2008 20:56:51 +0000 (UTC) (envelope-from mcc@fid4.com) Received: from mail102.csoft.net (mail102.csoft.net [205.205.219.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9704C13C455; Sun, 17 Feb 2008 20:56:51 +0000 (UTC) (envelope-from mcc@fid4.com) Received: from [172.16.6.246] (c-24-61-74-156.hsd1.ma.comcast.net [24.61.74.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail102.csoft.net (Postfix) with ESMTP id 3F6FE1D117; Sun, 17 Feb 2008 15:39:45 -0500 (EST) Message-ID: <47B89BE7.9020809@fid4.com> Date: Sun, 17 Feb 2008 15:41:11 -0500 From: "Michael C. Cambria" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Lay References: <47B73F59.1030409@comcast.net> In-Reply-To: <47B73F59.1030409@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: ath and cardbus 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, 17 Feb 2008 20:56:51 -0000 Nathan Lay wrote: [deleted] > Anyone else experience this strange behavior? It is of note, that if > the card is plugged in before booting, it is properly detected and > attached during boot. It is only when plugging it into a running > FreeBSD 7.0 system for the first time that it behaves this way. I can't even get this far. My Atheros AR5212 (Netgate WPN511) isn't even detected by FreeBSD 7 (csup as of this a.m. - 17 Feb 2008). In my case, I am using a PCI to Cardbus adapter. Details posted on mobile@ Which card are you using? MikeC From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 22:30:32 2008 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 707EF16A420 for ; Sun, 17 Feb 2008 22:30:32 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.4.200]) by mx1.freebsd.org (Postfix) with ESMTP id 41AA513C469 for ; Sun, 17 Feb 2008 22:30:32 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JWE00D4DMITVRB0@mta5.srv.hcvlny.cv.net> for freebsd-current@freebsd.org; Sun, 17 Feb 2008 17:30:31 -0500 (EST) Received: from flosoft.no-ip.biz (localhost [IPv6:::1]) by flosoft.no-ip.biz (8.14.2/8.14.2) with ESMTP id m1HMUSap080762; Sun, 17 Feb 2008 17:30:29 -0500 Date: Sun, 17 Feb 2008 17:30:23 -0500 From: "Aryeh M. Friedman" To: aegis-developers@lists.sourceforge.net, freebsd-current@freebsd.org Message-id: <47B8B57F.1080400@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.6 User-Agent: Thunderbird 2.0.0.9 (X11/20080216) Cc: Subject: strverscmp not detected missing 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, 17 Feb 2008 22:30:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In attempting to install aegis-4.24-RC2 on FreeBSD I discovered the following (effects all versions of aegis/autoconf) on FreeBSD 8-CURRENT (AMD64) [note to FreeBSD people I am posting this in -current and not ports since it appears to be a base system problem vs. a ports one].... there is no strverscmp defined in the above version of FreeBSD (there was upto a few days ago) and configure incorrectly thinks there is namely the following line: checking for strverscmp... yes This causes it to set HAVE_STRVERSCMP=1 and thus the build fails. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuLV/k8GFzCrQm4ARAkpGAKDaXNuLb7VTmK0iJPzk2jPhtzwjygCgxUiT wp8V4Y2XkDwQPdfY5WefjoU= =o6xI -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 23:12:29 2008 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 BC2C816A41B for ; Sun, 17 Feb 2008 23:12:29 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 3A54313C457 for ; Sun, 17 Feb 2008 23:12:28 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id CC141254967; Mon, 18 Feb 2008 00:12:26 +0100 (CET) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id m1HNBRFT074295; Mon, 18 Feb 2008 00:11:27 +0100 (CET) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id m1HNBRpN074294; Mon, 18 Feb 2008 00:11:27 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Mon, 18 Feb 2008 00:11:26 +0100 To: John Marino Message-ID: <20080217231126.GA68779@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Sun, 17 Feb 2008 23:26:05 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 17 Feb 2008 23:12:29 -0000 On Sun, Feb 17, 2008 at 06:51:18AM -0600, John Marino wrote: > Hello Juergen, > I decided to build a debug kernel as you suggested with DDB, KDB, > KDB_TRACE, and KDB_UNATTENDED as you suggested. The first time the kernel > panicked, I did not get a dump, but the system did save the second panic. > The backtrace is about the same, but the initial information looks much > better. > > I hope this helps, > John > > > draco-root# kgdb kernel.debug /usr/local/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > kernel > > tFraatpa l trap 12 wi1t2h: interpraugpet sf aduilsta bwlheidle > i > n > Fkaetranle lt rmaopd e1 > :c pupirdi v=i l1e;g eadp iicn sitdr u=c tion0 1f > afualutl tw hviilret uianl kaedrdnreels sm o=d e0 > xc0p > ufiadu l=t 0;c oadpei c =i ds u=p e0r0v > iisnosrt rruecatdi odna tpao,i nptaegre =n o0tx 2pfr3e0s:en0tx > fifnfsftfrfufcft8i0o8n3 bpbocidn > tsetra c=k 0pxo8i:n0txer f f f f f f f f=8 004x710b:a01x5f > fsftfafcfk fpfoaibn9tde6r6 e 0 > f r a m e =p o0ixn1t0e:r0 x f f f f f=f f0fxa1b09:d06xbcf0f > fffrfafmfef 8p0o9i8n1tceer0 > c o d e s e g=m e0nxt1 0=: 0bxase f0fxf0f,f flfifmaibt9 d06xc00,0 > tcyopdee 0sxe0gm > e nt == DbPaLs e0 ,0 xp0r,e sl i0m,i tl o0nxg f0f,f fdfe,f32 0, gran 0 > kernel trap 12 with interrupts disabled OK looks like indeed both cpus are crashing, maybe try setting PRINTF_BUFR_SIZE as others have suggested. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xffffffffffffffd3 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffff00010e1680 OK I doubt thats inside the kernel, but you could try doing `i li *0xffffff00010e1680' in kgdb to make sure... > stack pointer = 0x10:0xffffffffab9d64e0 > frame pointer = 0x10:0xffffffff80a93640 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 999 (qemu-system-x86_64) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x17a > trap_fatal() at trap_fatal+0x29f > trap() at trap+0x242 > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffff00010e1680, rsp = 0xffffffffab9d64e0, rbp = > 0xffffffff80a93640 --- > dmapbase() at 0xffffff00010e1680 > Uptime: 29m47s > Dumping 1983 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 1983MB (507568 pages) 1967 1951 1935 1919 1903 1887 1871 1855 > 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 > 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 > 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 > 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 > 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 > 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 > 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 > 47 31 15 > > #0 doadump () at pcpu.h:194 > 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > > > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0xffffffff80486dd8 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xffffffff80487237 in panic (fmt=Variable "fmt" is not available.) at > /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xffffffff8074857f in trap_fatal (frame=0xc, eva=Variable "eva" is not > available.) at /usr/src/sys/amd64/amd64/trap.c:724 > #4 0xffffffff80749272 in trap (frame=0xffffffffab9d6430) at > /usr/src/sys/amd64/amd64/trap.c:251 > #5 0xffffffff8072e60e in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:169 > #6 0xffffffff8047ba90 in _thread_lock_flags (td=0xffffffffab9d66e0, > opts=Variable "opts" is not available.) at > /usr/src/sys/kern/kern_mutex.c:523 So thats how the backtrace ended, next line was the kdgb prompt? Anyway I'm still not enlightened yet what the actual problem might be... Juergen From owner-freebsd-current@FreeBSD.ORG Sun Feb 17 23:34:35 2008 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 040EC16A41B; Sun, 17 Feb 2008 23:34:35 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7C17C13C4EB; Sun, 17 Feb 2008 23:34:34 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m1HNYOPE099785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 10:04:24 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: John Baldwin Date: Mon, 18 Feb 2008 10:04:05 +1030 User-Agent: KMail/1.9.7 References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802161153.34513.doconnor@gsoft.com.au> <200802160843.11766.jhb@freebsd.org> In-Reply-To: <200802160843.11766.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2524399.hazQX3GVdb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802181004.21379.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Kostik Belousov , Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , freebsd-current@freebsd.org Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 17 Feb 2008 23:34:35 -0000 --nextPart2524399.hazQX3GVdb Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 17 Feb 2008, John Baldwin wrote: > On Friday 15 February 2008 08:23:33 pm Daniel O'Connor wrote: > > On Sat, 16 Feb 2008, John Baldwin wrote: > > > > That's a pretty big advantage :) > > > > > > > > Also, ktrace can't write to a pipe which means you need to > > > > run/process rather than 'stream'. > > > > > > kdump -l. > > > > Ahh nice! > > > > However, you still keep the file around which can be rather space > > consuming :( > > Yes, but it also means you can do offline analysis later. :)=20 > Tradeoffs either way. Yes, but being able to specify stdout to ktrace would be really, really=20 nice.. (No, there aren't any patches on this email :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2524399.hazQX3GVdb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHuMR95ZPcIHs/zowRAn1YAJwPGccii/YWqcEBH/9wWjzkxh/CxwCcCiQK BTYXMbGOqoMAQoW7XER/p48= =Tao8 -----END PGP SIGNATURE----- --nextPart2524399.hazQX3GVdb-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 00:10:21 2008 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 2AA6216A419 for ; Mon, 18 Feb 2008 00:10:21 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id CE9EA13C469 for ; Mon, 18 Feb 2008 00:10:20 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6E23B2092; Mon, 18 Feb 2008 01:10:15 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 414BE2090; Mon, 18 Feb 2008 01:10:15 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1F1D784492; Mon, 18 Feb 2008 01:10:15 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Rainer Duffner References: <86r6fdx0tf.fsf@ds4.des.no> <20080216113721.GA55702@voi.aagh.net> <86tzk8vnz9.fsf@ds4.des.no> Date: Mon, 18 Feb 2008 01:10:15 +0100 In-Reply-To: (Rainer Duffner's message of "Sat\, 16 Feb 2008 18\:16\:25 +0100") Message-ID: <86ve4n15w8.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0-RC2 Available 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, 18 Feb 2008 00:10:21 -0000 Rainer Duffner writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Don't blame me for your decision to use the most expensive type of > > storage available, especially when it has been conclusively shown > > that expensive server-grade disks are no more reliable than cheap > > consumer- grade disks. > I think you are unfair. In some servers (Blades come to mind - but > they're not the only ones) you just can't plug in a 500 GB WD SATA2 > disk. You've got to use either SAS or SAN-boot. In that case, you need to find a better server supplier. (yes, I've seen blades that take 3.5" disks) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 01:04:07 2008 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 314F916A421 for ; Mon, 18 Feb 2008 01:04:07 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 042D213C45E for ; Mon, 18 Feb 2008 01:04:06 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 3499 invoked from network); 18 Feb 2008 01:04:06 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Feb 2008 01:04:06 -0000 Message-ID: <47B8D869.1030009@chuckr.org> Date: Sun, 17 Feb 2008 19:59:21 -0500 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Markus Brueffer References: <47B20739.1050602@chuckr.org> <20080216121241.450ff175@deskjail> <47B79A48.1030406@chuckr.org> <200802171642.04403.markus@FreeBSD.org> In-Reply-To: <200802171642.04403.markus@FreeBSD.org> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: about usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 01:04:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Markus Brueffer wrote: > Am Sonntag, 17. Februar 2008 03:22:00 schrieb Chuck Robey: >> I am still having a miserable time trying to figure out the HID spec, and >> Kai Wang deserves being nominated for Sainthood, for putting up with my >> horde of stupid questions. If anyone knows of a HID device which has a >> published [HID report in hex, Parsed output, and comments on how it got >> from one to the other] I would give nearly anything for such a thing >> (anything I happen to have, which doesn't happen to include cash right >> now). > Boy I am really, really pleased you made this public, and I believe folks will be googling this for years now. What a great thing to do! > This is the raw report descriptor of a very simple device: an Apple Mighty > Mouse: > > 0x05 0x01 0x09 0x02 0xa1 0x01 0x05 0x09 > 0x19 0x01 0x29 0x04 0x15 0x00 0x25 0x01 > 0x95 0x04 0x75 0x01 0x81 0x02 0x95 0x01 > 0x75 0x04 0x81 0x01 0x05 0x01 0x09 0x01 > 0xa1 0x00 0x09 0x30 0x09 0x31 0x09 0x32 > 0x09 0x38 0x15 0x81 0x25 0x7f 0x75 0x08 > 0x95 0x04 0x81 0x06 0xc0 0x05 0xff 0x09 > 0xc0 0x75 0x08 0x95 0x01 0x81 0x02 0xc0 > > Decoding it works as follows: > > Let's look at the first byte 0x05. The binary representation is 00000101. > Splitting this up as described in chapter 6.2.2.2 gives the following (in > binary representation): > > bTag=0000 > bType=01 > bSize=01 > > First, as bTag is not 1111, we know that this is not a long item (see > 6.2.2.3). So this must be a short item. > > bType tells us that this is a global item (6.2.2.2). Finally bSize specifies > the number of following bytes that belong to this item which is 1 in this > case. So, looking back at the raw descriptor we know now that the sequence > 0x05 0x01 forms one item. We also know that it is a short item and that it is > a global item. What we don't know yet is, what global item this is. For this, > we have to look at bTag again. As we know that this is a global item, we take > a look at chapter 6.2.2.7 "Global Items". It tells us that 0000 stands for > Usage Page. Which usage page is meant is encoded in the data part of the > item, which is 0x01. From the HID Usage Tables document Chapter 3 we learn > that 0x01 stands for "Generic Desktop Controls". This gives us the following > for the first item: > > 0x05 0x01 USAGE_PAGE (Generic Desktop) > > Now the second item beginning with 0x09: Binary representation is 00001001. > Splitting this up yields: > > bTag=0000 > bType=10 > bSize=01 > > Again this is a short item as bTag != 1111. bType is a decimal 2 and chapter > 6.2.2.2 tells us that this is a local item. Advancing to chapter > 6.2.2.7 "Local Items" gives us the meaning for bTag, which is "Usage". As > bSize is 1, only the next byte in the report descriptor is considered for the > data of the item, so the usage is 0x02. Looking at the HID Usage Tables > document again, this time chapter 4, as we already learned that this usage > belongs to the usage page Generic Desktop, we see that 0x02 is equivalent > to "Mouse". Now we have: > > 0x05 0x01 USAGE_PAGE (Generic Desktop) > 0x09 0x02 USAGE (Mouse) > > Up to the next item which begins with 0xa1, binary 10100001: > > bTag=1010 > bType=00 > bSize=01 > > Again this is a short item as bTag != 1111. bType is 0, which stands for Main > Item, according to chapter 6.2.2.2. Looking at chapter 6.2.2.4, we learn that > the bTag of 1010 actually means "Collection". The data part of 1 byte (see > bSize), which is in this case 0x01 tells us that this is an "Application > Collection". So, now we have: > > 0x05 0x01 USAGE_PAGE (Generic Desktop) > 0x09 0x02 USAGE (Mouse) > 0xa1 0x01 COLLECTION (Application) > > If you continue decoding it this way, you will finally get the following: > > 0x05 0x01 USAGE_PAGE (Generic Desktop) > 0x09 0x02 USAGE (Mouse) > 0xa1 0x01 COLLECTION (Application) > 0x05 0x09 USAGE_PAGE (Button) > 0x19 0x01 USAGE_MINIMUM (Button 1) > 0x29 0x04 USAGE_MAXIMUM (Button 4) > 0x15 0x00 LOGICAL_MINIMUM (0) > 0x25 0x01 LOGICAL_MAXIMUM (1) > 0x95 0x04 REPORT_COUNT (4) > 0x75 0x01 REPORT_SIZE (1) > 0x81 0x02 INPUT (Data, Var, Abs) > 0x95 0x01 REPORT_COUNT (1) > 0x75 0x04 REPORT_SIZE (4) > 0x81 0x01 INPUT (Const, Var, Abs) > 0x05 0x01 USAGE_PAGE (Generic Desktop) > 0x09 0x01 USAGE (Pointer) > 0xa1 0x00 COLLECTION (Physical) > 0x09 0x30 USAGE (X) > 0x09 0x31 USAGE (Y) > 0x09 0x32 USAGE (Z) > 0x09 0x38 USAGE (WHEEL) > 0x15 0x81 LOGICAL_MINIMUM (0x81) > 0x25 0x7f LOGICAL_MAXIMUM (0x7f) > 0x75 0x08 REPORT_SIZE (8) > 0x95 0x04 REPORT_COUNT (4) > 0x81 0x06 INPUT (Data, Var, Rel) > 0xc0 END COLLECTION > 0x05 0xff USAGE_PAGE (0xff) > 0x09 0xc0 USAGE (0xc0) > 0x75 0x08 REPORT_SIZE (8) > 0x95 0x01 REPORT_COUNT (1) > 0x81 0x02 INPUT (Data, Var, Abs) > 0xc0 > > To actually give meaning to the decoded descriptor, you have to learn how > local, global and main items relate to each other. Main items are actually > the most important ones, as they directly correlate to physical controls of > your device (apart from the collection items). Global and local items > describe the different main items, whereas local items only describe the next > main item. Global items instead keep their state accross main items until > they are specified again or are being overrriden by a local item. > > In this example we have several main items. Lets have a look at the first one > > 0x05 0x01 USAGE_PAGE (Generic Desktop) > 0x09 0x02 USAGE (Mouse) > 0xa1 0x01 COLLECTION (Application) > > This is an application collection. Usage page and usage describe the context > of the items that are within it, so we have: > > Collection page=Generic_Desktop usage=Mouse > > The next item is a bit more interresting. It's an input item: > > 0x05 0x09 USAGE_PAGE (Button) > 0x19 0x01 USAGE_MINIMUM (Button 1) > 0x29 0x04 USAGE_MAXIMUM (Button 4) > 0x15 0x00 LOGICAL_MINIMUM (0) > 0x25 0x01 LOGICAL_MAXIMUM (1) > 0x95 0x04 REPORT_COUNT (4) > 0x75 0x01 REPORT_SIZE (1) > 0x81 0x02 INPUT (Data, Var, Abs) > > It actually describes 4 controls (report count). The meaning of these 4 > controls is specified by the usage page and usage min/max. In this case > Button 1 - Button 4. Logical min/max are 0 and 1 and mean that the range of > the data in the data stream, that is submitted by the device, is between 0 > and 1, which is actually only 0 and 1 in this case. Report size finally gives > the size in the data stream for each button state that is submitted by the > device in number of bits. Now we have: > > Collection page=Generic_Desktop usage=Mouse > Input size=1 count=1 page=Button usage=Button_1, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_2, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_3, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_4, logical range 0..1 > > The next input item is a const item, which is being used for padding in this > case. It can be ignored. In the end we get the following: > > Collection page=Generic_Desktop usage=Mouse > Input size=1 count=1 page=Button usage=Button_1, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_2, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_3, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_4, logical range 0..1 > Input size=4 count=1 page=0x0000 usage=0x0000 Const, logical range 0..1 > Collection page=Generic_Desktop usage=Pointer > Input size=8 count=1 page=Generic_Desktop usage=X, logical range -127..127 > Input size=8 count=1 page=Generic_Desktop usage=Y, logical range -127..127 > Input size=8 count=1 page=Generic_Desktop usage=Z, logical range -127..127 > Input size=8 count=1 page=Generic_Desktop usage=Wheel, logical > range -127..127 > End collection > Input size=8 count=1 page=0x00ff usage=0x00c0, logical range -127..127 > End collection > > This actually means, that the mouse reports 6 bytes of data in each > transmission. The first 4 bits indicate the button states, the next 4 bits > can be ignored. Byte 2 reports the X axis state, byte 3, 4 and 5 data for Y, > Z and the wheel. The last byte reports vendor specific data (usage page > 0x00ff). > > That's it in short. There is of course much to learn regarding the details, > but it should give you a general overview of how this works. > > Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuNhoz62J6PPcoOkRAiuYAJ4iMn+/EX+lDnmvotxzOPa9JLJ6jQCdHtDN HGyri1EPkH97rMTojc/x/MQ= =YWSy -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 04:22:25 2008 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 F3F2516A41B; Mon, 18 Feb 2008 04:22:24 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 5B42213C43E; Mon, 18 Feb 2008 04:22:24 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1I4BbE7022063; Mon, 18 Feb 2008 06:11:37 +0200 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1I4BbO3007953; Mon, 18 Feb 2008 06:11:37 +0200 Received: from kobe.laptop (adsl78-170.kln.forthnet.gr [77.49.125.170]) by MX-IN-04.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1I46TjV031628; Mon, 18 Feb 2008 06:06:32 +0200 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=keramida@freebsd.org; spf=permerror Authentication-Results: MX-IN-04.forthnet.gr header.from=keramida@freebsd.org; sender-id=permerror Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m1I46TmN008294; Mon, 18 Feb 2008 06:06:29 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m1I46Qe3008293; Mon, 18 Feb 2008 06:06:26 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Mon, 18 Feb 2008 06:06:25 +0200 From: Giorgos Keramidas To: "Daniel O'Connor" Message-ID: <20080218040625.GA8141@kobe.laptop> References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802161153.34513.doconnor@gsoft.com.au> <200802160843.11766.jhb@freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802181004.21379.doconnor@gsoft.com.au> Cc: Kostik Belousov , Dag-Erling Smorgrav , freebsd-current@freebsd.org Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 18 Feb 2008 04:22:25 -0000 On 2008-02-18 10:04, Daniel O'Connor wrote: >On Sun, 17 Feb 2008, John Baldwin wrote: >>On Friday 15 February 2008 08:23:33 pm Daniel O'Connor wrote: >>>On Sat, 16 Feb 2008, John Baldwin wrote: >>>>> That's a pretty big advantage :) >>>>> >>>>> Also, ktrace can't write to a pipe which means you need to >>>>> run/process rather than 'stream'. >>>> >>>> kdump -l. >>> >>> Ahh nice! >>> >>> However, you still keep the file around which can be rather space >>> consuming :( >> >> Yes, but it also means you can do offline analysis later. :) >> Tradeoffs either way. > > Yes, but being able to specify stdout to ktrace would be really, really > nice.. Hi Daniel, Specifying stdout may be a bit tricky, since the traced application may be using the same stream to print output. The same is possible with stderr, but may be a tiny bit less likely. It is probably easy to add an -F flag to ktrace/kdump which would inhibit the check for a `regular' file, so you could then write: ( ktrace -aF -f /dev/stdout ls ) | \ kdump -F -f /dev/stdin ( ktrace -aF -f /dev/stderr ls >/dev/null ) 2>&1 | \ kdump -F -f /dev/stdin But the first will probably fail when kdump tries to parse the output of ls(1), and the second may fail in a similar manner when kdump tries to parse an error message like a ktrace record. This sort of difficulty in separating the output of the traced process and the ktrace records themselves is probably at least part of the reason why nobody has done it yet. - Giorgos From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 04:43:59 2008 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 336A916A419; Mon, 18 Feb 2008 04:43:59 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 521BF13C448; Mon, 18 Feb 2008 04:43:57 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m1I4hioc014000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 15:13:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Giorgos Keramidas Date: Mon, 18 Feb 2008 15:13:35 +1030 User-Agent: KMail/1.9.7 References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> <20080218040625.GA8141@kobe.laptop> In-Reply-To: <20080218040625.GA8141@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1353809.8pjBojVj5D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802181513.42681.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Kostik Belousov , Dag-Erling Smorgrav , freebsd-current@freebsd.org Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 18 Feb 2008 04:43:59 -0000 --nextPart1353809.8pjBojVj5D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 18 Feb 2008, Giorgos Keramidas wrote: > >>> However, you still keep the file around which can be rather space > >>> consuming :( > >> > >> Yes, but it also means you can do offline analysis later. :) > >> Tradeoffs either way. > > > > Yes, but being able to specify stdout to ktrace would be really, > > really nice.. > > Specifying stdout may be a bit tricky, since the traced application > may be using the same stream to print output. The same is possible > with stderr, but may be a tiny bit less likely. I didn't realise that the file descriptor used to write tracing data out=20 was 'owned' by the process being traced, I always thought ktrace did. > It is probably easy to add an -F flag to ktrace/kdump which would > inhibit the check for a `regular' file, so you could then write: > > ( ktrace -aF -f /dev/stdout ls ) | \ > kdump -F -f /dev/stdin > > ( ktrace -aF -f /dev/stderr ls >/dev/null ) 2>&1 | \ > kdump -F -f /dev/stdin > > But the first will probably fail when kdump tries to parse the output > of ls(1), and the second may fail in a similar manner when kdump > tries to parse an error message like a ktrace record. > > This sort of difficulty in separating the output of the traced > process and the ktrace records themselves is probably at least part > of the reason why nobody has done it yet. I did have a look at the source and the file opening etc is handled by=20 the kernel but I am not sure who 'owns' that file descriptor. If, as you suggest, it is the process being traced then yes it would=20 cause problems. I guess it couldn't be moved to ktrace without rearchitecting how=20 ktracing works so the ktrace process sticks around writing stuff out to=20 disk. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1353809.8pjBojVj5D Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHuQz+5ZPcIHs/zowRAraHAKCakJJ2Feljucdt/t+LkfmewUt0XwCgib2i LiJ6naAWz9a3Zzue5zR6bUc= =avaK -----END PGP SIGNATURE----- --nextPart1353809.8pjBojVj5D-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 05:28:56 2008 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 A327916A417; Mon, 18 Feb 2008 05:28:56 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7B48613C44B; Mon, 18 Feb 2008 05:28:56 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id DBF868FD79; Sun, 17 Feb 2008 22:28:55 -0700 (MST) Date: Sun, 17 Feb 2008 22:28:55 -0700 From: Brad Davis To: freebsd-hackers@FreeBSD.org Message-ID: <20080218052855.GE49382@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Status Reports for the Fourth Quarter of 2007 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, 18 Feb 2008 05:28:56 -0000 Hi Everyone, The FreeBSD Status Reports for the Fourth Quarter of 2007 are now available at: http://www.freebsd.org/news/status/report-2007-10-2007-12.html Regards, Brad Davis From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 07:02:27 2008 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 A855216A419 for ; Mon, 18 Feb 2008 07:02:27 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2100A13C458 for ; Mon, 18 Feb 2008 07:02:26 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from nbc.matik.com.br (nbc.matik.com.br [200.152.88.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m1I72LZI094452; Mon, 18 Feb 2008 04:02:22 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Mon, 18 Feb 2008 05:01:01 -0300 User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) References: <200704182239.59842.gelsemap@superhero.nl> <47B7D534.7000204@scsiguy.com> <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> In-Reply-To: <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802180501.08502.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Gelsema, P \(Patrick\)" , Niki Denev , "Gelsema, P \(Patrick\) - FreeBSD" Subject: Re: Adaptec AHD U320 operating as only U160 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, 18 Feb 2008 07:02:27 -0000 On Sunday 17 February 2008 14:23:41 Gelsema, P (Patrick) - FreeBSD wrote: > On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: > > Niki Denev wrote: > > > I was playing around with DTrace, tracing cam/xpt and the ahd driver > > > > and > > > > > found out that if i comment the following code : > > > > > > if ((spi3caps & SID_SPI_IUS) =3D=3D 0) > > > spi->ppr_options &=3D ~MSG_EXT_PPR_IU_REQ; > > > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : > > > > > > da0 at ahd0 bus 0 target 0 lun 0 > > > da0: Fixed Direct Access SCSI-3 device > > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > > da0: Command Queueing Enabled > > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > it is not working on Tyan MBs embedded u320 Adaptec, I still get with compl= ete=20 world and kernel build on sources from this night #d3a 0L:a un Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHzS MDPT:, AoPf fCsPeUt #623 ,L=20 au1n6cbhietd)! da0: Command Queueing Enabled da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da1: Command Queueing Enabled da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) Trying to mount root from ufs:/dev/da0s1a It is this controller: ahd0: port 0x9000-0x90ff,0x8800-0x8= 8ff=20 mem 0xfc9fc000-0xfc9fdfff irq 24 at device 6.0 on pci2 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x9800-0x98ff,0x9400-0x9= 4ff=20 mem 0xfc9fe000-0xfc9fffff irq 25 at device 6.1 on pci2 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs which on first site seems to be the same on Supermicros MB: ahd0: port 0xa800-0xa8ff,0xa400-0xa= 4ff=20 mem 0xfc9fe000-0xfc9fffff irq 24 at device 3.0 on pci2 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0xa000-0xa0ff,0xac00-0xa= cff=20 mem 0xfc9fc000-0xfc9fdfff irq 25 at device 3.1 on pci2 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs But I can confirm that it seems to be ok on 29320 Adaptec cards and on=20 Supermicro embedded U320 Adaptec =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 08:18:13 2008 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 5127A16A468 for ; Mon, 18 Feb 2008 08:18:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0D5813C4DB for ; Mon, 18 Feb 2008 08:18:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so1954198pyb.10 for ; Mon, 18 Feb 2008 00:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=K8BlDU2djt/4W1xM2XmjppDyy3sWyLK7YH+IpmeDcIE=; b=IF6wJ09gFN+9N+qiyIeNonrWvWIuGuhwz8vhhSnZ7N/VeNsdqPHmhQgmzAUYBOkaU72UdfaI9HUM83ijCgySdCTvsNDK+OfWyL6zUntqBAgeWWAXu27zgsyZcbKZtDH6AnchJ4HFjF16TocXuWeM7kl7JaLLMiGS6MgtCNWbrOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=bzDxF5PiliOsI6Zju3XjVNwi8llOAdqsk7zUiRxAz/xKBP/OwNybDzV1CLl5+7xkKK0JlTt31zLu8Oy+ZngKLluoNj0StzPLoJak3T6zhYNtkYs+Q+qFXkVcwQTfgdJmbG0qIzhZIPN5oKgCRkfrHVrlesSVp7CL6JEWhV2xYho= Received: by 10.142.78.10 with SMTP id a10mr4080257wfb.37.1203322691839; Mon, 18 Feb 2008 00:18:11 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm16575709wfd.19.2008.02.18.00.18.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Feb 2008 00:18:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1I8I5pi015578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 17:18:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1I8I1vc015577; Mon, 18 Feb 2008 17:18:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 18 Feb 2008 17:18:01 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20080218081801.GB14601@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802171517.26965.freebsd-current@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 08:18:13 -0000 On Sun, Feb 17, 2008 at 03:17:26PM +0100, Milan Obuch wrote: > On Sunday 17 February 2008, Milan Obuch wrote: > > On Sunday 17 February 2008, Robert Watson wrote: > > > On Sat, 16 Feb 2008, Milan Obuch wrote: > > > >> I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. > > > >> Does this also happen on other network interface too? When the system > > > >> hangs, would you break into DDB and show me the output of 'show > > > >> alllocks' and 'ps'? > > > > > > > > I need some tests with another box. I was not able to break into DDB. > > > > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did > > > > not invoke DDB. I do not feel if_vr is culprit here, more probably PCI > > > > bus got somehow locked, but I have no idea how could I test it > > > > currently. > > > > > > FYI, there are known issues with the effectiveness of syscons > > > ctrl-alt-esc to get into the debugger -- if you haven't tried with a > > > serial break on a serial console, you might want to do so. This is > > > because syscons's interrupt handler acquires the Giant lock in an > > > ithread, requiring a lot more things to be happy to succeed. In > > > constrast, sio (and friends) use fast interrupt handlers and no Giant > > > lock on the way to processing the break request. It may well be that a > > > serial break doesn't get into DDB for you, but it's worth trying... > > > > > > Robert N M Watson > > > Computer Laboratory > > > University of Cambridge > > > > You are right, after rebuilding kernel with BREAK_TO_DEBUGGER I am able to > > get requested data. BTW, I can't find just now what ALT_BREAK_TO_DEBUGGER > > means... > > > > After kldload if_vr, dhclient vr0 and ping -f in a minute > > system freezes. > > > > Correction... as I moved cable from on-board re0 to vr0, system remembered arp > table entry and did not actually try to use vr0. Now I repeated it, but boot > system with cable in vr0. This time it hangs right after ping <>, and break > does not enter debugger... hard hang. I tried it twice, the same result... > > So no data to check, actually, only hard hang. > I've put up a new version under the old URL. It's not tested in sparc64 but it seems to work on i386. Would you give it spin? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 08:42:18 2008 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 C078616A417 for ; Mon, 18 Feb 2008 08:42:18 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3EB13C45A for ; Mon, 18 Feb 2008 08:42:18 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 26A96405478 for ; Mon, 18 Feb 2008 09:42:16 +0100 (CET) Message-ID: <47B944E7.1080000@bsdforen.de> Date: Mon, 18 Feb 2008 09:42:15 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: fixing using 3rd party mount tools from fstab 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, 18 Feb 2008 08:42:18 -0000 With the new mount system using fstab entries with 3rd party mount tools does not work any more, because mount -t only uses exec_mountprog for known mount types. I have submitted a small patch that falls back to exec_mountprog if mount_fs fails. This way 3rd party mount tools will work again, without replacing base system mount tools. http://www.freebsd.org/cgi/query-pr.cgi?pr=120784 I could have removed the use_mountprog(vfstype) function, but I left it in, because it documents which mount types in the base system still use the old style mount. From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 10:08:11 2008 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 7DE2916A421 for ; Mon, 18 Feb 2008 10:08:11 +0000 (UTC) (envelope-from root@mobiscar.ru) Received: from fr44.aha.ru (fr44.aha.ru [62.113.100.44]) by mx1.freebsd.org (Postfix) with ESMTP id DBED413C458 for ; Mon, 18 Feb 2008 10:08:10 +0000 (UTC) (envelope-from root@mobiscar.ru) Received: from aha.ru (backend10.aha.ru [62.113.86.199]) by fr44.aha.ru (Postfix) with ESMTP id D9E661B8F0 for ; Mon, 18 Feb 2008 12:30:50 +0300 (MSK) Received: from [77.246.248.9] (HELO gate.mobis-office) by backend10.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPS id 65641878 for freebsd-current@freebsd.org; Mon, 18 Feb 2008 12:30:50 +0300 Received: from it1 ([192.216.119.191]) by gate.mobis-office (8.14.1/8.14.1) with ESMTP id m1I9WHBQ054162 for ; Mon, 18 Feb 2008 12:32:20 +0300 (MSK) (envelope-from root@mobiscar.ru) From: =?utf-8?B?0JPQvtGA0LHQsNGH0ZHQsiDQmi7QkC4=?= To: Date: Mon, 18 Feb 2008 12:31:08 +0300 Organization: =?utf-8?B?0J7QntCeICLQnNC+0LHQuNGB0LrQsNGAIg==?= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200802180501.08502.joao@matik.com.br> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Thread-Index: Achx/Gf3dXwfJtcUQeqUSc9HTUyw4QAEnmzA Subject: RE: Adaptec AHD U320 operating as only U160 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, 18 Feb 2008 10:08:11 -0000 Read this thread = http://readlist.com/lists/freebsd.org/freebsd-current/7/38214.html -----Original Message----- From: owner-freebsd-current@freebsd.org = [mailto:owner-freebsd-current@freebsd.org] On Behalf Of JoaoBR Sent: Monday, February 18, 2008 11:01 AM To: freebsd-current@freebsd.org Cc: Gelsema, P (Patrick); Niki Denev; Gelsema,P (Patrick) - FreeBSD Subject: Re: Adaptec AHD U320 operating as only U160 On Sunday 17 February 2008 14:23:41 Gelsema, P (Patrick) - FreeBSD = wrote: > On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: > > Niki Denev wrote: > > > I was playing around with DTrace, tracing cam/xpt and the ahd = driver > > > > and > > > > > found out that if i comment the following code : > > > > > > if ((spi3caps & SID_SPI_IUS) =3D=3D 0) > > > spi->ppr_options &=3D ~MSG_EXT_PPR_IU_REQ; > > > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as = U320 : > > > > > > da0 at ahd0 bus 0 target 0 lun 0 > > > da0: Fixed Direct Access SCSI-3 = device > > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > > da0: Command Queueing Enabled > > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > it is not working on Tyan MBs embedded u320 Adaptec, I still get with = complete=20 world and kernel build on sources from this night #d3a 0L:a un Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHzS MDPT:, AoPf fCsPeUt #623 ,L=20 au1n6cbhietd)! da0: Command Queueing Enabled da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da1: Command Queueing Enabled da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) Trying to mount root from ufs:/dev/da0s1a It is this controller: ahd0: port = 0x9000-0x90ff,0x8800-0x88ff=20 mem 0xfc9fc000-0xfc9fdfff irq 24 at device 6.0 on pci2 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs ahd1: port = 0x9800-0x98ff,0x9400-0x94ff=20 mem 0xfc9fe000-0xfc9fffff irq 25 at device 6.1 on pci2 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs which on first site seems to be the same on Supermicros MB: ahd0: port = 0xa800-0xa8ff,0xa400-0xa4ff=20 mem 0xfc9fe000-0xfc9fffff irq 24 at device 3.0 on pci2 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs ahd1: port = 0xa000-0xa0ff,0xac00-0xacff=20 mem 0xfc9fc000-0xfc9fdfff irq 25 at device 3.1 on pci2 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs But I can confirm that it seems to be ok on 29320 Adaptec cards and on=20 Supermicro embedded U320 Adaptec --=20 Jo=C3=A3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada = segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 10:45:16 2008 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 0C9CB16A41B; Mon, 18 Feb 2008 10:45:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B8F8D13C4CE; Mon, 18 Feb 2008 10:45:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 37770208E; Mon, 18 Feb 2008 11:45:12 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 25490208C; Mon, 18 Feb 2008 11:45:12 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id D389D844B9; Mon, 18 Feb 2008 11:45:11 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Daniel O'Connor" References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> <20080218040625.GA8141@kobe.laptop> <200802181513.42681.doconnor@gsoft.com.au> Date: Mon, 18 Feb 2008 11:45:11 +0100 In-Reply-To: <200802181513.42681.doconnor@gsoft.com.au> (Daniel O'Connor's message of "Mon\, 18 Feb 2008 15\:13\:35 +1030") Message-ID: <86pruu7dc8.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 18 Feb 2008 10:45:16 -0000 "Daniel O'Connor" writes: > Giorgos Keramidas writes: > > Specifying stdout may be a bit tricky, since the traced application > > may be using the same stream to print output. The same is possible > > with stderr, but may be a tiny bit less likely. > I didn't realise that the file descriptor used to write tracing data > out was 'owned' by the process being traced, I always thought ktrace > did. ktrace does absolutely nothing other than enable tracing and exec the application. The 'k' in "ktrace" means "kernel". > I did have a look at the source and the file opening etc is handled by > the kernel but I am not sure who 'owns' that file descriptor. There is no file descriptor. There is a vnode in the kernel which is not listed in the traced process's file table. This is the whole point of ktrace: it is undetectable by the traced process. > I guess it couldn't be moved to ktrace without rearchitecting how > ktracing works so the ktrace process sticks around writing stuff out > to disk. ...which would make it just as useless as truss, since it would (among other things) change the way job control works for the traced process. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 10:48:20 2008 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 AC38516A417 for ; Mon, 18 Feb 2008 10:48:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4411213C45B for ; Mon, 18 Feb 2008 10:48:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1IAmHWI027766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 21:48:18 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1IAmHAu066066; Mon, 18 Feb 2008 21:48:17 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1IAmH6p066065; Mon, 18 Feb 2008 21:48:17 +1100 (EST) (envelope-from peter) Date: Mon, 18 Feb 2008 21:48:17 +1100 From: Peter Jeremy To: "Aryeh M. Friedman" Message-ID: <20080218104817.GP64299@server.vk2pj.dyndns.org> References: <47B8B57F.1080400@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="THYEXwetZJOK3OLY" Content-Disposition: inline In-Reply-To: <47B8B57F.1080400@gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: aegis-developers@lists.sourceforge.net, freebsd-current@freebsd.org Subject: Re: strverscmp not detected missing 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, 18 Feb 2008 10:48:20 -0000 --THYEXwetZJOK3OLY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 17, 2008 at 05:30:23PM -0500, Aryeh M. Friedman wrote: >no strverscmp defined in the above version of FreeBSD (there was upto a fe= w=20 >days ago) and configure incorrectly thinks there is namely the following= =20 >line: > >checking for strverscmp... yes If the aegis configure script is claiming that strverscmp() exists when it doesn't then that is a bug in the configure script and nothing to do with FreeBSD. I have spent most of the past week fighting broken configure scripts and my opinion of the GNU autotools approach could not get much lower. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --THYEXwetZJOK3OLY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHuWJx/opHv/APuIcRApz0AJ42nSH95DCl4xC6vVVRJ698FeMUqwCgpwBz k10vK3yx5JHUHz6UmKLp6cg= =8Mgt -----END PGP SIGNATURE----- --THYEXwetZJOK3OLY-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 11:05:25 2008 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 71FC016A418 for ; Mon, 18 Feb 2008 11:05:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 05C2E13C45A for ; Mon, 18 Feb 2008 11:05:24 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1IB5LG0006822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 22:05:22 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1IB5LNA066179; Mon, 18 Feb 2008 22:05:21 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1IB5L6Z066178; Mon, 18 Feb 2008 22:05:21 +1100 (EST) (envelope-from peter) Date: Mon, 18 Feb 2008 22:05:21 +1100 From: Peter Jeremy To: "Daniel O'Connor" Message-ID: <20080218110521.GQ64299@server.vk2pj.dyndns.org> References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> <20080218040625.GA8141@kobe.laptop> <200802181513.42681.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OxDG9cJJSSQMUzGF" Content-Disposition: inline In-Reply-To: <200802181513.42681.doconnor@gsoft.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 18 Feb 2008 11:05:25 -0000 --OxDG9cJJSSQMUzGF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2008 at 03:13:35PM +1030, Daniel O'Connor wrote: >I didn't realise that the file descriptor used to write tracing data out= =20 >was 'owned' by the process being traced, I always thought ktrace did. Unlike truss/ptrace type tools, ktrace just sets a flag in the process that tells the kernel to generate ktrace records. This is more obvious when you use the 'ktrace -p PID' form. On Mon, 18 Feb 2008, Giorgos Keramidas wrote: >> It is probably easy to add an -F flag to ktrace/kdump which would >> inhibit the check for a `regular' file, so you could then write: >> >> ( ktrace -aF -f /dev/stdout ls ) | \ >> kdump -F -f /dev/stdin I don't think stdin/stdout is practical here but supporting named pipes sounds like it would be useful. >I guess it couldn't be moved to ktrace without rearchitecting how=20 >ktracing works so the ktrace process sticks around writing stuff out to=20 >disk. And from what I've seen of the innards of ktrace, the re-architecting would be quite significant. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --OxDG9cJJSSQMUzGF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHuWZx/opHv/APuIcRAtkWAJ9YYSjclbypFcSnd7KRk8ARBNQJkACdFS2y sYkxCEqNMRw9i4XDwtXfka4= =iLxu -----END PGP SIGNATURE----- --OxDG9cJJSSQMUzGF-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 11:10:37 2008 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 D5D8A16A418 for ; Mon, 18 Feb 2008 11:10:37 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4EEA113C4E1 for ; Mon, 18 Feb 2008 11:10:36 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from nbc.matik.com.br (nbc.matik.com.br [200.152.88.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m1IBAVk9012399; Mon, 18 Feb 2008 08:10:31 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Mon, 18 Feb 2008 08:10:28 -0300 User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) References: <200704182239.59842.gelsemap@superhero.nl> <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> <200802180501.08502.joao@matik.com.br> In-Reply-To: <200802180501.08502.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802180810.29049.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Gelsema, P \(Patrick\) - FreeBSD" , Niki Denev , "Gelsema, P \(Patrick\)" Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 11:10:37 -0000 On Monday 18 February 2008 05:01:01 JoaoBR wrote: > On Sunday 17 February 2008 14:23:41 Gelsema, P (Patrick) - FreeBSD wrote: > > On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: > > > Niki Denev wrote: > > > > I was playing around with DTrace, tracing cam/xpt and the ahd driv= er > > > > > > and > > > > > > > found out that if i comment the following code : > > > > > > > > if ((spi3caps & SID_SPI_IUS) =3D=3D 0) > > > > spi->ppr_options &=3D ~MSG_EXT_PPR_IU_REQ; > > > > > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320= : > > > > > > > > da0 at ahd0 bus 0 target 0 lun 0 > > > > da0: Fixed Direct Access SCSI-3 device > > > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > > > da0: Command Queueing Enabled > > > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > take care with this hack because at least on Tyans and SM Mbs this hack doe= s=20 nothing good and cause continuous card dumps and some machines do not boot= =20 correctly (seems it depends on kind of disk installed), it is not usable=20 here! the only card which stands this is the pci-x adaptec 29320 > it is not working on Tyan MBs embedded u320 Adaptec, I still get with > complete world and kernel build on sources from this night > > #d3a 0L:a un E ST373207LW 0005> Fixed Direct Access SCSI-3 device > da0: 160.000MB/s transfers (80.000MHzS MDPT:, AoPf fCsPeUt #623 ,L > au1n6cbhietd)! > > da0: Command Queueing Enabled > da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) > da1 at ahd0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) > da1: Command Queueing Enabled > da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) > Trying to mount root from ufs:/dev/da0s1a > > > It is this controller: > > ahd0: port > 0x9000-0x90ff,0x8800-0x88ff mem 0xfc9fc000-0xfc9fdfff irq 24 at device 6.0 > on pci2 > ahd0: [ITHREAD] > aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs > ahd1: port > 0x9800-0x98ff,0x9400-0x94ff mem 0xfc9fe000-0xfc9fffff irq 25 at device 6.1 > on pci2 > ahd1: [ITHREAD] > aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs > > which on first site seems to be the same on Supermicros MB: > > ahd0: port > 0xa800-0xa8ff,0xa400-0xa4ff mem 0xfc9fe000-0xfc9fffff irq 24 at device 3.0 > on pci2 > ahd0: [ITHREAD] > aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs > ahd1: port > 0xa000-0xa0ff,0xac00-0xacff mem 0xfc9fc000-0xfc9fdfff irq 25 at device 3.1 > on pci2 > ahd1: [ITHREAD] > aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs > > > > > > But I can confirm that it seems to be ok on 29320 Adaptec cards and on > Supermicro embedded U320 Adaptec =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 11:18:29 2008 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 9E72216A417; Mon, 18 Feb 2008 11:18:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7312B13C469; Mon, 18 Feb 2008 11:18:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 505A446B9B; Mon, 18 Feb 2008 06:18:28 -0500 (EST) Date: Mon, 18 Feb 2008 11:18:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel O'Connor In-Reply-To: <200802181513.42681.doconnor@gsoft.com.au> Message-ID: <20080218111445.I35880@fledge.watson.org> References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802181004.21379.doconnor@gsoft.com.au> <20080218040625.GA8141@kobe.laptop> <200802181513.42681.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Dag-Erling Smorgrav , freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 18 Feb 2008 11:18:29 -0000 On Mon, 18 Feb 2008, Daniel O'Connor wrote: > On Mon, 18 Feb 2008, Giorgos Keramidas wrote: > >> But the first will probably fail when kdump tries to parse the output of >> ls(1), and the second may fail in a similar manner when kdump tries to >> parse an error message like a ktrace record. >> >> This sort of difficulty in separating the output of the traced process and >> the ktrace records themselves is probably at least part of the reason why >> nobody has done it yet. > > I did have a look at the source and the file opening etc is handled by the > kernel but I am not sure who 'owns' that file descriptor. > > If, as you suggest, it is the process being traced then yes it would cause > problems. > > I guess it couldn't be moved to ktrace without rearchitecting how ktracing > works so the ktrace process sticks around writing stuff out to disk. There are a lot of implicit design assumptions in the current design, such as: (1) Stalling on I/O may sleep, but won't be indefinite. (2) Ktrace I/O can happen from the following contexts without consequence: process exit, thread return to userspace, system call entry, system call exit, namei(), I/O input and output routines for file descriptors, and the utrace() system call. Direct vnode I/O generally meets these criteria, as disk waits, while long, tend to be bounded, and performing arbitrary vnode I/O from, say, the socket receive routine, while potentially slow, is safe. However, if you start using a file descriptor instead of a vnode, you need to worry about things like indefinite blocking, recursion, etc. I'm not saying these can't be addressed, but it's not as simple as replacing references to struct vnode with references to struct file. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 11:43:07 2008 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 77E1F16A417; Mon, 18 Feb 2008 11:43:07 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB5813C469; Mon, 18 Feb 2008 11:43:05 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-73-250.lns10.adl6.internode.on.net [121.45.73.250]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m1IBgpSk026172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 22:12:53 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Mon, 18 Feb 2008 22:12:43 +1030 User-Agent: KMail/1.9.7 References: <200802122009.m1CK94Y8026959@repoman.freebsd.org> <200802181513.42681.doconnor@gsoft.com.au> <86pruu7dc8.fsf@ds4.des.no> In-Reply-To: <86pruu7dc8.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart19102424.6xQeb0Q0rm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802182212.45377.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Kostik Belousov , freebsd-current@freebsd.org, Giorgos Keramidas Subject: Re: [src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h 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, 18 Feb 2008 11:43:07 -0000 --nextPart19102424.6xQeb0Q0rm Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 18 Feb 2008, Dag-Erling Sm=C3=B8rgrav wrote: > "Daniel O'Connor" writes: > > Giorgos Keramidas writes: > > > Specifying stdout may be a bit tricky, since the traced > > > application may be using the same stream to print output. The > > > same is possible with stderr, but may be a tiny bit less likely. > > > > I didn't realise that the file descriptor used to write tracing > > data out was 'owned' by the process being traced, I always thought > > ktrace did. > > ktrace does absolutely nothing other than enable tracing and exec the > application. The 'k' in "ktrace" means "kernel". Yes.. > > I did have a look at the source and the file opening etc is handled > > by the kernel but I am not sure who 'owns' that file descriptor. > > There is no file descriptor. There is a vnode in the kernel which is > not listed in the traced process's file table. This is the whole > point of ktrace: it is undetectable by the traced process. I thought it was undetectable but I was willing to learn, I guess I was=20 right originally :) > > I guess it couldn't be moved to ktrace without rearchitecting how > > ktracing works so the ktrace process sticks around writing stuff > > out to disk. > > ...which would make it just as useless as truss, since it would > (among other things) change the way job control works for the traced > process. I don't see why, I thought that if you had to specify an FD then it=20 could be one owned by ktrace rather than the tracing process, however=20 that was based on an incorrect assumption so it is not relevant. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart19102424.6xQeb0Q0rm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHuW815ZPcIHs/zowRAkhuAJ9uapz6PTf9WtZcRhKR3bw/SG96DgCgm3Zq kwjOsf07dhvhRTZqApxHlbA= =JDbG -----END PGP SIGNATURE----- --nextPart19102424.6xQeb0Q0rm-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 11:54:04 2008 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 721F616A420 for ; Mon, 18 Feb 2008 11:54:04 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B33813C478 for ; Mon, 18 Feb 2008 11:54:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JR4ZN-0004fC-9o for freebsd-current@freebsd.org; Mon, 18 Feb 2008 11:54:01 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Feb 2008 11:54:01 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Feb 2008 11:54:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 18 Feb 2008 12:56:10 +0100 Lines: 41 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF136B2DD0C3EA6F8A7362CD0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) X-Enigmail-Version: 0.95.0 Sender: news Subject: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 11:54:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF136B2DD0C3EA6F8A7362CD0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I've again encountered the problem of FreeBSD 7 not wanting to boot on a HP server. The last time was early in 7.x development on a HP blade (2xdual-core Opteron), without any solution (reported on this list about a year ago). This time it's on a ML 350 G5 machine, with a quad-core Xeon= =2E The problem is very hard to diagnose - the entire machine locks up during pci bus/device detection - the kernel debugger doesn't work, the keyboard lights (PS/2 keyboard) don't work, it's completely frozen. This is on both i386 and AMD64 kernels. The machine freezes after detecting pcib6. The working 6.x kernel detects upto pcib16, and the first device detected after pcib6 is the CISS controller, so maybe it's the controller driver, but the first machine (the blade) didn't have CISS controllers. Any ideas? --------------enigF136B2DD0C3EA6F8A7362CD0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHuXJgldnAQVacBcgRAnNPAKDS1/juRp0ToElGFQM1fYx8241wOQCeO0Go pb8gBnptMfbuoEIOXyM6NvA= =qyeN -----END PGP SIGNATURE----- --------------enigF136B2DD0C3EA6F8A7362CD0-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 12:03:35 2008 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 7F54C16A468 for ; Mon, 18 Feb 2008 12:03:35 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3587713C468 for ; Mon, 18 Feb 2008 12:03:35 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=WlMMLdo4FTvS+eLLsI86B8cABoVDDfABpd/PBpqCCsPSzd/WlpHGGAknHdJAjAyt82K29d4HxhzAyUFooOc7xgMG1qkJIhPO0DFHX78WsgUEhBaRhHSv4MsB7pRmHvbNUbbXy1LkcRqNe/XKE+H+0fTXY/xlWMMpFgbIdQ044b8=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JR4ic-000JQM-5l; Mon, 18 Feb 2008 15:03:34 +0300 Date: Mon, 18 Feb 2008 15:03:33 +0300 From: Eygene Ryabinkin To: Ivan Voras Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: freebsd-current@freebsd.org Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 12:03:35 -0000 Ivan, good day. Mon, Feb 18, 2008 at 12:56:10PM +0100, Ivan Voras wrote: > I've again encountered the problem of FreeBSD 7 not wanting to boot on a > HP server. The last time was early in 7.x development on a HP blade > (2xdual-core Opteron), without any solution (reported on this list about > a year ago). This time it's on a ML 350 G5 machine, with a quad-core Xeon. > > The problem is very hard to diagnose - the entire machine locks up > during pci bus/device detection - the kernel debugger doesn't work, the > keyboard lights (PS/2 keyboard) don't work, it's completely frozen. > > This is on both i386 and AMD64 kernels. > > The machine freezes after detecting pcib6. The working 6.x kernel > detects upto pcib16, and the first device detected after pcib6 is the > CISS controller, so maybe it's the controller driver, but the first > machine (the blade) didn't have CISS controllers. > > Any ideas? I have a couple of BL640c and older BLp running 7.0 -- no problems encountered. While this is not the direct answer to your question, had you tried to update the blade firmware to the latest versions with Firmware Maintenance CD? Sometimes it helps... -- Eygene From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 07:08:22 2008 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 C6F2916A41A for ; Mon, 18 Feb 2008 07:08:22 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 94E3513C468 for ; Mon, 18 Feb 2008 07:08:22 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: by shepard.synsport.net (Postfix, from userid 108) id B47C2435F9; Mon, 18 Feb 2008 01:08:21 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shepard X-Spam-Level: X-Spam-Status: No, score=-4.4 required=6.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from secure.synsport.net (unknown [208.69.230.150]) by shepard.synsport.net (Postfix) with ESMTP id 0E01743578; Mon, 18 Feb 2008 01:08:19 -0600 (CST) Received: from 82.234.78.29 (SquirrelMail authenticated user marst2) by secure.synsport.net with HTTP; Mon, 18 Feb 2008 01:08:19 -0600 (CET) Message-ID: <51702.82.234.78.29.1203318499.squirrel@secure.synsport.net> In-Reply-To: <20080217231126.GA68779@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217231126.GA68779@saturn.kn-bremen.de> Date: Mon, 18 Feb 2008 01:08:19 -0600 (CET) From: "John Marino" To: "Juergen Lock" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 18 Feb 2008 12:20:38 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 18 Feb 2008 07:08:22 -0000 Hello Juergen, I compiled a new debug kernel with PRINTF_BUFR_SIZE=128 option. After that, KQuemu locked up in the same exact place but Freebsd would not dump it's core. I had been using KQemu with the XFCE desktop. Finally I started invoking it from the commandline. The emulator's display was garbled. The first time it panicked, it looked like I had an interactive debugger, but it was logged on. The core did not dump. I repeated this again and finally FreeBSD dumped core, but it seems like it's a different issue than before. Hopefully this will enlighten you... John draco-root# kgdb kernel.debug /usr/local/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: kernel tkernel trap 12 with interrupts disabled kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff804b2e50 stack pointer = 0x10:0xffffffffab9d6190 frame pointer = 0x10:0xffffffffab9d61b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1588 (qemu-system-x86_64) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a trap_fatal() at trap_fatal+0x29f trap() at trap+0x242 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff804b2e50, rsp = 0xffffffffab9d6190, rbp = 0xffffffffab9d61b0 --- putcons() at putcons+0x50 putchar() at putchar+0x6b kvprintf() at kvprintf+0x72 printf() at printf+0xcc uart_z8530_class() at 0x1 uart_z8530_class() at 0x1 uart_z8530_class() at 0x1 Uptime: 6h2m48s Dumping 1983 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 1983MB (507568 pages) 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0xffffffff80486dd8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff80487237 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xffffffff8074860f in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:724 #4 0xffffffff80749302 in trap (frame=0xffffffffab9d60e0) at /usr/src/sys/amd64/amd64/trap.c:251 #5 0xffffffff8072e69e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #6 0xffffffff804b2e50 in putcons (c=Variable "c" is not available. ) at /usr/src/sys/kern/subr_prf.c:389 #7 0xffffffff804b302b in putchar (c=10, arg=Variable "arg" is not available. ) at /usr/src/sys/kern/subr_prf.c:421 #8 0xffffffff804b1582 in kvprintf (fmt=0xffffffff8083c0b8 "", func=0xffffffff804b2fc0 , arg=0xffffffffab9d63d0, radix=10, ap=Variable "ap" is not available. ) at /usr/src/sys/kern/subr_prf.c:674 #9 0xffffffff804b2bbc in printf (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/subr_prf.c:314 #10 0x0000000000000001 in ?? () #11 0xffffffffab9d66f0 in ?? () #12 0xffffffff80735ca3 in spinlock_exit () at cpufunc.h:391 #13 0x0000000000000001 in ?? () #14 0xffffffffab9d6790 in ?? () #15 0x0000000080699029 in ?? () #16 0x00000000ffffff04 in ?? () #17 0xffffffffab9d6928 in ?? () #18 0x0000000000000000 in ?? () #19 0xffffffff80a6f8a0 in thread0 () #20 0x00000000ab9d6930 in ?? () #21 0x0000000000000000 in ?? () #22 0xffffffff00000005 in ?? () #23 0x0000000000000000 in ?? () #24 0xffffffffab9d66f0 in ?? () #25 0x0000000000000080 in ?? () #26 0xffffffffab9d6720 in ?? () #27 0x0000000000000050 in ?? () #28 0x0000003000000020 in ?? () #29 0xffffffffab9d6890 in ?? () #30 0xffffffffab9d67c0 in ?? () #31 0xfffbbfffab9d6970 in ?? () #32 0x00000000a38d6a20 in ?? () #33 0x000000000000000c in ?? () #34 0xffffffff8083bdbf in printinterval.9757 () #35 0xffffffff80805203 in op_table () #36 0x0000000000000001 in ?? () #37 0x000000000000009b in ?? () #38 0xffffffffab9d6aa0 in ?? () #39 0x0000000000000001 in ?? () #40 0xffffff0001554301 in ?? () #41 0x0000000000000001 in ?? () #42 0xffffffff00000000 in ?? () #43 0xffffffff80a6f8a0 in thread0 () #44 0x000000006e72656b in ?? () #45 0xfffeffff00000000 in ?? () #46 0x0800000008808004 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000810000000000 in ?? () #49 0x0400200000000000 in ?? () #50 0x4000300100002000 in ?? () ---Type to continue, or q to quit--- #51 0x0000000020000010 in ?? () #52 0x0000008000000200 in ?? () #53 0x0050400140000000 in ?? () #54 0xffffffff80a6f8a0 in thread0 () #55 0x0000000000000010 in ?? () #56 0xffffffffab9d68e0 in ?? () #57 0xffffffff807483f9 in trap_fatal (frame=0x3a00000039, eva=0) at /usr/src/sys/amd64/amd64/trap.c:667 Previous frame inner to this frame (corrupt stack?) (kgdb) (kgdb) i li *0xffffffff804b2e50 Line 390 of "/usr/src/sys/kern/subr_prf.c" starts at address 0xffffffff804b2e50 and ends at 0xffffffff804b2e53 . (kgdb) > On Sun, Feb 17, 2008 at 06:51:18AM -0600, John Marino wrote: > > OK looks like indeed both cpus are crashing, maybe try setting > PRINTF_BUFR_SIZE as others have suggested. > > So thats how the backtrace ended, next line was the kdgb prompt? > > Anyway I'm still not enlightened yet what the actual problem might be... > Juergen > From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 12:20:44 2008 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 B43F816A530; Mon, 18 Feb 2008 12:20:44 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE7413C4EE; Mon, 18 Feb 2008 12:20:44 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id DF5D7BFEC94; Mon, 18 Feb 2008 12:05:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id giDhIBoueF9g; Mon, 18 Feb 2008 12:05:32 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 30554BFEC65; Mon, 18 Feb 2008 12:05:32 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1IC5V6F066168; Mon, 18 Feb 2008 13:05:31 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1IC5Vqu066167; Mon, 18 Feb 2008 13:05:31 +0100 (CET) (envelope-from rink) Date: Mon, 18 Feb 2008 13:05:31 +0100 From: Rink Springer To: Ivan Voras Message-ID: <20080218120531.GD98720@rink.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 12:20:44 -0000 Hi Ivan, On Mon, Feb 18, 2008 at 12:56:10PM +0100, Ivan Voras wrote: > Any ideas? Try building a kernel with VERBOSE_SYSINIT option in it - you'll see which functions it's calling, and you can use this to see where it gets stuck. Cheers, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 12:23:33 2008 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 4294116A419; Mon, 18 Feb 2008 12:23:33 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id CA0C113C4D3; Mon, 18 Feb 2008 12:23:32 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 3DF7CB0290; Mon, 18 Feb 2008 13:04:46 +0100 (CET) MIME-Version: 1.0 Date: Mon, 18 Feb 2008 13:04:46 +0100 From: Marian Hettwer To: Ivan Voras In-Reply-To: References: Message-ID: <27bd9855e7ddafac0a6f31462b057298@localhost> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 12:23:33 -0000 Hi Ivan, On Mon, 18 Feb 2008 12:56:10 +0100, Ivan Voras wrote: > Hi, > > I've again encountered the problem of FreeBSD 7 not wanting to boot on a > HP server. The last time was early in 7.x development on a HP blade > (2xdual-core Opteron), without any solution (reported on this list about > a year ago). This time it's on a ML 350 G5 machine, with a quad-core Xeon. > I don't have a ML 350 G5 machine at hand, but fwiw I do have a HP BL465c G1 blade. It's a 2 dual core AMD Opteron blade. Right now it's running FreeBSD 7.0-BETA4. I'm running make world right now to get a recent RELENG_7 Meanwhile: [root@marian46-23] <~>uname -a [12:01:36 on 08-02-18] FreeBSD marian46-23 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Tue Dec 18 12:07:27 CET 2007 root@marian46-23:/usr/obj/usr/src/sys/MOBILE amd64 dmesg: Copyright (c) 1992-2007 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 7.0-BETA4 #0: Tue Dec 18 12:07:27 CET 2007 root@marian46-23:/usr/obj/usr/src/sys/MOBILE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual-Core AMD Opteron(tm) Processor 2218 (2600.11-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 4280225792 (4081 MB) avail memory = 4118867968 (3928 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Dec 18 2007 12:07:17) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 cpu2: on acpi0 powernow2: on cpu2 cpu3: on acpi0 powernow3: on cpu3 pcib0: on acpi0 pci0: on pcib0 vgapci0: port 0x1000-0x10ff mem 0xe8000000-0xefffffff,0xf7ff0000-0xf7ffffff irq 20 at device 3.0 on pci0 pci0: at device 4.0 (no driver attached) pci0: at device 4.2 (no driver attached) uhci0: port 0x1800-0x181f irq 21 at device 4.4 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: <(0x103c) UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 4.6 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 bce0: mem 0xfa000000-0xfbffffff irq 22 at device 3.0 on pci2 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 1000baseSX-FDX, auto bce0: Ethernet address: 00:1c:c4:aa:08:58 bce0: [ITHREAD] bce0: ASIC (0x57060021); Rev (A2); Bus (PCI-X, 64-bit, 100MHz); F/W (0x01090605); Flags( MSI ) bce1: mem 0xf8000000-0xf9ffffff irq 23 at device 4.0 on pci2 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 1000baseSX-FDX, auto bce1: Ethernet address: 00:1c:c4:aa:08:88 bce1: [ITHREAD] bce1: ASIC (0x57060021); Rev (A2); Bus (PCI-X, 64-bit, 100MHz); F/W (0x01090605); Flags( MSI ) isab0: at device 6.2 on pci0 isa0: on isab0 ohci0: port 0x1c00-0x1cff mem 0xf7ee0000-0xf7ee0fff irq 5 at device 7.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci0 usb1: USB revision 1.0 uhub1: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1 uhub1: 2 ports with 2 removable, self powered ohci1: port 0x3000-0x30ff mem 0xf7ed0000-0xf7ed0fff irq 5 at device 7.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci1 usb2: USB revision 1.0 uhub2: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: port 0x3400-0x34ff mem 0xf7ec0000-0xf7ec0fff irq 5 at device 7.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: <(0x1166) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb3 uhub3: 4 ports with 4 removable, self powered pcib3: on acpi0 pci4: on pcib3 pcib4: irq 16 at device 15.0 on pci4 pci5: on pcib4 pcib5: irq 20 at device 16.0 on pci4 pci12: on pcib5 pcib6: irq 19 at device 17.0 on pci4 pci19: on pcib6 pcib7: at device 0.0 on pci19 pci20: on pcib7 pcib8: at device 4.0 on pci20 pci21: on pcib8 ciss0: port 0x4000-0x40ff mem 0xfdf80000-0xfdffffff,0xfdf70000-0xfdf77fff irq 19 at device 8.0 on pci20 ciss0: [ITHREAD] pcib9: irq 18 at device 18.0 on pci4 pci22: on pcib9 pcib10: irq 17 at device 19.0 on pci4 pci25: on pcib10 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcefff,0xcf000-0xd07ff,0xe6000-0xe7fff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub0 kbd2 at ukbd0 ums0: on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 uhub4: on uhub0 uhub4: 7 ports with 7 removable, self powered Timecounters tick every 1.000 msec hptrr: no controller detected. SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: 69973MB (143305920 512 byte sectors: 255H 32S/T 17562C) Trying to mount root from ufs:/dev/da0s1a HTH, Marian From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 12:30:13 2008 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 3DF2D16A421 for ; Mon, 18 Feb 2008 12:30:13 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id F011813C4E9 for ; Mon, 18 Feb 2008 12:30:12 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1368576rvb.43 for ; Mon, 18 Feb 2008 04:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Vb/nFW17tMZBYoM/cIMF/HK2NtXlDu62hxlcEfKeMPE=; b=qpy70txFr4oDbzG6YS8rtrtlYQ5TNV9Ci7GcG56Qp7QUKzz6pFQ4AHqY8z9MCdN33egPEhaXwDPV5LKT0X6T8rnwRe38+/2jmJLT2R6sM057m2gBff1ljnICU615ZONA8BZ4sB5kGvCvyqSc72q6ixVMRFfWT6H+4/UPg9EogWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=L64gUrc1uyqXYvXxK0Sjf3hZD2ATnwWU2IE0+HPxDaBwtdb7//xVRCCbb+5w/sfwkDhLRNkZ+yk6JETk0IcYHEgw/Tr9YVgqJUcDrL1FKgBSslq455GKYNH1i2G9A3yGJJt3OD6zEZ7RSxeQSxlXp6Avr9XFE8ywwVf2lQ2t3kM= Received: by 10.141.79.12 with SMTP id g12mr3772407rvl.87.1203337811664; Mon, 18 Feb 2008 04:30:11 -0800 (PST) Received: by 10.141.170.18 with HTTP; Mon, 18 Feb 2008 04:30:11 -0800 (PST) Message-ID: <2e77fc10802180430m18215bdav3716048ac3a2e6d0@mail.gmail.com> Date: Mon, 18 Feb 2008 14:30:11 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: JoaoBR In-Reply-To: <200802180810.29049.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200704182239.59842.gelsemap@superhero.nl> <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> <200802180501.08502.joao@matik.com.br> <200802180810.29049.joao@matik.com.br> X-Google-Sender-Auth: 8b1b52a334ba4b5d Cc: freebsd-current@freebsd.org Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 12:30:13 -0000 On 2/18/08, JoaoBR wrote: > On Monday 18 February 2008 05:01:01 JoaoBR wrote: > > On Sunday 17 February 2008 14:23:41 Gelsema, P (Patrick) - FreeBSD wrot= e: > > > On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: > > > > Niki Denev wrote: > > > > > I was playing around with DTrace, tracing cam/xpt and the ahd dr= iver > > > > > > > > and > > > > > > > > > found out that if i comment the following code : > > > > > > > > > > if ((spi3caps & SID_SPI_IUS) =3D=3D 0) > > > > > spi->ppr_options &=3D ~MSG_EXT_PPR_IU_REQ; > > > > > > > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U3= 20 : > > > > > > > > > > da0 at ahd0 bus 0 target 0 lun 0 > > > > > da0: Fixed Direct Access SCSI-3 devi= ce > > > > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) > > > > > da0: Command Queueing Enabled > > > > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > > > > > take care with this hack because at least on Tyans and SM Mbs this hack d= oes > nothing good and cause continuous card dumps and some machines do not boo= t > correctly (seems it depends on kind of disk installed), it is not usable > here! > > > the only card which stands this is the pci-x adaptec 29320 > > > > > > it is not working on Tyan MBs embedded u320 Adaptec, I still get with > > complete world and kernel build on sources from this night > > > > #d3a 0L:a un > E ST373207LW 0005> Fixed Direct Access SCSI-3 device > > da0: 160.000MB/s transfers (80.000MHzS MDPT:, AoPf fCsPeUt #623 ,L > > au1n6cbhietd)! > > > > da0: Command Queueing Enabled > > da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) > > da1 at ahd0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-3 device > > da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) > > da1: Command Queueing Enabled > > da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) > > Trying to mount root from ufs:/dev/da0s1a > > > > > > It is this controller: > > > > ahd0: port > > 0x9000-0x90ff,0x8800-0x88ff mem 0xfc9fc000-0xfc9fdfff irq 24 at device = 6.0 > > on pci2 > > ahd0: [ITHREAD] > > aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCB= s > > ahd1: port > > 0x9800-0x98ff,0x9400-0x94ff mem 0xfc9fe000-0xfc9fffff irq 25 at device = 6.1 > > on pci2 > > ahd1: [ITHREAD] > > aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCB= s > > > > which on first site seems to be the same on Supermicros MB: > > > > ahd0: port > > 0xa800-0xa8ff,0xa400-0xa4ff mem 0xfc9fe000-0xfc9fffff irq 24 at device = 3.0 > > on pci2 > > ahd0: [ITHREAD] > > aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCB= s > > ahd1: port > > 0xa000-0xa0ff,0xac00-0xacff mem 0xfc9fc000-0xfc9fdfff irq 25 at device = 3.1 > > on pci2 > > ahd1: [ITHREAD] > > aic7902: Ultra320 Wide Channel B, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCB= s > > > > > > > > > > > > But I can confirm that it seems to be ok on 29320 Adaptec cards and on > > Supermicro embedded U320 Adaptec > > -- > > Jo=E3o > Yes, that's a gross hack, no doubt about it. I posted it mainly to serve as a pointer to the real problem, and I think it did that. With version 1.30 of aic79xx_osm.c my negotiation problems are gone. --Niki From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 13:37:58 2008 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 CAE6C16A419 for ; Mon, 18 Feb 2008 13:37:58 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 34C7213C46B for ; Mon, 18 Feb 2008 13:37:57 +0000 (UTC) (envelope-from gelsemap@superhero.nl) Received: (qmail 488 invoked by uid 80); 18 Feb 2008 13:37:35 -0000 Received: from 195.50.100.20 (SquirrelMail authenticated user gelsemap) by www.superhero.nl with HTTP; Mon, 18 Feb 2008 14:37:35 +0100 (CET) Message-ID: <23378.195.50.100.20.1203341855.squirrel@www.superhero.nl> In-Reply-To: <2e77fc10802180430m18215bdav3716048ac3a2e6d0@mail.gmail.com> References: <200704182239.59842.gelsemap@superhero.nl> <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> <200802180501.08502.joao@matik.com.br> <200802180810.29049.joao@matik.com.br> <2e77fc10802180430m18215bdav3716048ac3a2e6d0@mail.gmail.com> Date: Mon, 18 Feb 2008 14:37:35 +0100 (CET) From: "Gelsema, P \(Patrick\)" To: "Niki Denev" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org, JoaoBR Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 13:37:59 -0000 On Mon, February 18, 2008 13:30, Niki Denev wrote: > On 2/18/08, JoaoBR wrote: >> On Monday 18 February 2008 05:01:01 JoaoBR wrote: >> > On Sunday 17 February 2008 14:23:41 Gelsema, P (Patrick) - FreeBSD >> wrote: >> > > On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: >> > > > Niki Denev wrote: >> > > > > I was playing around with DTrace, tracing cam/xpt and the ahd >> driver >> > > > >> > > > and >> > > > >> > > > > found out that if i comment the following code : >> > > > > >> > > > > if ((spi3caps & SID_SPI_IUS) == 0) >> > > > > spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; >> > > > > >> > > > > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as >> U320 : >> > > > > >> > > > > da0 at ahd0 bus 0 target 0 lun 0 >> > > > > da0: Fixed Direct Access SCSI-3 >> device >> > > > > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) >> > > > > da0: Command Queueing Enabled >> > > > > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) >> > >> >> >> >> take care with this hack because at least on Tyans and SM Mbs this hack >> does >> nothing good and cause continuous card dumps and some machines do not >> boot >> correctly (seems it depends on kind of disk installed), it is not usable >> here! >> >> >> the only card which stands this is the pci-x adaptec 29320 >> >> >> >> >> > it is not working on Tyan MBs embedded u320 Adaptec, I still get with >> > complete world and kernel build on sources from this night >> > >> > #d3a 0L:a un> > E ST373207LW 0005> Fixed Direct Access SCSI-3 device >> > da0: 160.000MB/s transfers (80.000MHzS MDPT:, AoPf fCsPeUt #623 ,L >> > au1n6cbhietd)! >> > >> > da0: Command Queueing Enabled >> > da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) >> > da1 at ahd0 bus 0 target 1 lun 0 >> > da1: Fixed Direct Access SCSI-3 device >> > da1: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) >> > da1: Command Queueing Enabled >> > da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) >> > Trying to mount root from ufs:/dev/da0s1a >> > >> > >> > It is this controller: >> > >> > ahd0: port >> > 0x9000-0x90ff,0x8800-0x88ff mem 0xfc9fc000-0xfc9fdfff irq 24 at device >> 6.0 >> > on pci2 >> > ahd0: [ITHREAD] >> > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs >> > ahd1: port >> > 0x9800-0x98ff,0x9400-0x94ff mem 0xfc9fe000-0xfc9fffff irq 25 at device >> 6.1 >> > on pci2 >> > ahd1: [ITHREAD] >> > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs >> > >> > which on first site seems to be the same on Supermicros MB: >> > >> > ahd0: port >> > 0xa800-0xa8ff,0xa400-0xa4ff mem 0xfc9fe000-0xfc9fffff irq 24 at device >> 3.0 >> > on pci2 >> > ahd0: [ITHREAD] >> > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs >> > ahd1: port >> > 0xa000-0xa0ff,0xac00-0xacff mem 0xfc9fc000-0xfc9fdfff irq 25 at device >> 3.1 >> > on pci2 >> > ahd1: [ITHREAD] >> > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs >> > >> > >> > >> > >> > >> > But I can confirm that it seems to be ok on 29320 Adaptec cards and on >> > Supermicro embedded U320 Adaptec >> >> -- >> >> João >> > > Yes, that's a gross hack, no doubt about it. > I posted it mainly to serve as a pointer to the > real problem, and I think it did that. > With version 1.30 of aic79xx_osm.c my negotiation > problems are gone. I am getting confused. Is version 1.30 considered a gross hack? If required I can do tests on my machine. If so, please let me know which ones. Rgds, Patrick > > --Niki > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 14:07:14 2008 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 ED16216A417 for ; Mon, 18 Feb 2008 14:07:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 86EAB13C4D1 for ; Mon, 18 Feb 2008 14:07:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (74-92-209-69-Colorado.hfc.comcastbusiness.net [74.92.209.69] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m1IE73Mc012926; Mon, 18 Feb 2008 07:07:08 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47B99107.3000204@samsco.org> Date: Mon, 18 Feb 2008 07:07:03 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: JoaoBR References: <200704182239.59842.gelsemap@superhero.nl> <2442.10.202.77.197.1203269021.squirrel@webmail.superhero.nl> <200802180501.08502.joao@matik.com.br> <200802180810.29049.joao@matik.com.br> In-Reply-To: <200802180810.29049.joao@matik.com.br> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.4 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: "Gelsema, P \(Patrick\) - FreeBSD" , freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , Niki Denev Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 14:07:15 -0000 JoaoBR wrote: > On Monday 18 February 2008 05:01:01 JoaoBR wrote: >> On Sunday 17 February 2008 14:23:41 Gelsema, P (Patrick) - FreeBSD wrote: >>> On Sun, February 17, 2008 07:33, Justin T. Gibbs wrote: >>>> Niki Denev wrote: >>>> > I was playing around with DTrace, tracing cam/xpt and the ahd driver >>>> >>>> and >>>> >>>> > found out that if i comment the following code : >>>> > >>>> > if ((spi3caps & SID_SPI_IUS) == 0) >>>> > spi->ppr_options &= ~MSG_EXT_PPR_IU_REQ; >>>> > >>>> > at line 6655 in sys/cam/cam_xpt.c my disks again negotiate as U320 : >>>> > >>>> > da0 at ahd0 bus 0 target 0 lun 0 >>>> > da0: Fixed Direct Access SCSI-3 device >>>> > da0: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) >>>> > da0: Command Queueing Enabled >>>> > da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) > > > > take care with this hack because at least on Tyans and SM Mbs this hack does > nothing good and cause continuous card dumps and some machines do not boot > correctly (seems it depends on kind of disk installed), it is not usable > here! > > > the only card which stands this is the pci-x adaptec 29320 > You are confusing people by posting a response to a discussion that has already moved beyond where you are responding. The real fix to the original poster's problem has already been identified, please catch up. Also, in the future, whether you are up to date on the discussion or not, making a post saying that something crashes/doesn't work, but without posting any of the debugging information that goes with it, is pretty close to being useless. Scott From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 14:49:23 2008 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 3A5D216A41A for ; Mon, 18 Feb 2008 14:49:23 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4780213C467 for ; Mon, 18 Feb 2008 14:49:21 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m1IEnJjE030232; Mon, 18 Feb 2008 11:49:19 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Mon, 18 Feb 2008 11:49:16 -0300 User-Agent: KMail/1.9.7 References: <200704182239.59842.gelsemap@superhero.nl> <200802180810.29049.joao@matik.com.br> <47B99107.3000204@samsco.org> In-Reply-To: <47B99107.3000204@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802181149.17068.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Gelsema, P \(Patrick\)" , Niki Denev , "Gelsema, P \(Patrick\) - FreeBSD" Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 14:49:23 -0000 On Monday 18 February 2008 11:07:03 Scott Long wrote: > You are confusing people by posting a response to a discussion that has > already moved beyond where you are responding. =A0The real fix to the > original poster's problem has already been identified, please catch > up. not so sure about this ... firstable I guess I was the original poster some month ago ... secondable I let it clear that it seems to work for Adaptec's 29320 but not= on=20 other adaptors which I let also clear in my former msg, just read it entire= ly > > Also, in the future, whether you are up to date on the discussion or > not, making a post saying that something crashes/doesn't work, but > without posting any of the debugging information that goes with it, > is pretty close to being useless. yep I guess so, take your time: from a SM MB ahd0: port 0xa800-0xa8ff,0xa400-0xa= 4ff=20 mem 0xfc9fe000-0xfc9fffff irq 24 at device 3.0 on pci2 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=3D7, PCI-X 67-100Mhz, 512 SCBs =46eb 18 08:00:48 wco-and kernel: Sequencer Complete DMA-inprog list: =46eb 18 08:00:48 wco-and kernel: Sequencer Complete list: =46eb 18 08:00:48 wco-and kernel: Sequencer DMA-Up and Complete list: =46eb 18 08:00:48 wco-and kernel: Sequencer On QFreeze and Complete list: =46eb 18 08:00:48 wco-and kernel: =46eb 18 08:00:48 wco-and kernel: =46eb 18 08:00:48 wco-and kernel: ahd0: FIFO0 Active, LONGJMP =3D=3D 0x8277= , SCB=20 0x1f6 =46eb 18 08:00:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x10] DFCNTRL[0x= 4]=20 DFSTATUS[0x89] =46eb 18 08:00:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0]=20 DFFSXFRCTL[0x0] =46eb 18 08:00:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x2] SHADDR =3D 0x= 00,=20 SHCNT =3D 0x0 =46eb 18 08:00:48 wco-and kernel: HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10] =46eb 18 08:00:48 wco-and kernel: =46eb 18 08:00:48 wco-and kernel: ahd0: FIFO1 Free, LONGJMP =3D=3D 0x8063, = SCB 0x1f9 =46eb 18 08:00:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0= ]=20 DFSTATUS[0x89] =46eb 18 08:00:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0]=20 DFFSXFRCTL[0x0] =46eb 18 08:00:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x5] SHADDR =3D 0x= 00,=20 SHCNT =3D 0x0 =46eb 18 08:00:48 wco-and kernel: HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x0] =46eb 18 08:00:48 wco-and kernel: LQIN: 0x5 0x0 0x1 0xf6 0x0 0x0 0x0 0x0 0x= 0 0x0=20 0x0 0x0 0x0 0x0 0x40 0x0 0x0 0x0 0x2 0x0 =46eb 18 08:00:48 wco-and kernel: ahd0: LQISTATE =3D 0x30, LQOSTATE =3D 0x0= ,=20 OPTIONMODE =3D 0x42 =46eb 18 08:00:48 wco-and kernel: ahd0: OS_SPACE_CNT =3D 0x20 MAXCMDCNT =3D= 0x8 =46eb 18 08:00:48 wco-and kernel: ahd0: SAVED_SCSIID =3D 0x0 SAVED_LUN =3D = 0x0 =46eb 18 08:00:48 wco-and kernel: SIMODE0[0xc] =46eb 18 08:00:48 wco-and kernel: CCSCBCTL[0x0] =46eb 18 08:00:48 wco-and kernel: ahd0: REG0 =3D=3D 0xd9, SINDEX =3D 0x112,= DINDEX =3D=20 0x102 =46eb 18 08:00:48 wco-and kernel: ahd0: SCBPTR =3D=3D 0x9d, SCB_NEXT =3D=3D= 0xff80,=20 SCB_NEXT2 =3D=3D 0xff22 =46eb 18 08:00:48 wco-and kernel: CDB 2a 0 0 80 88 eb =46eb 18 08:00:48 wco-and kernel: STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 =46eb 18 08:00:48 wco-and kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends=20 >>>>>>>>>>>>>>>>>> =46eb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): SCB 501 - timed out =46eb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): Queuing a BDR SCB =46eb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): Task Management Func 0x= 1=20 Complete =46eb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): no longer in timeout, s= tatus=20 =3D 24b =46eb 18 08:00:48 wco-and kernel: ahd0: Recovery Initiated - Card was not p= aused =46eb 18 08:00:48 wco-and kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins= =20 <<<<<<<<<<<<<<<<< =46eb 18 08:00:48 wco-and kernel: ahd0: Dumping Card State at program addre= ss=20 0x22 Mode 0x33 =46eb 18 08:00:48 wco-and kernel: INTSTAT[0x0] SELOID[0x1] SELID[0x0]=20 HS_MAILBOX[0x0] =46eb 18 08:00:48 wco-and kernel: INTCTL[0x80] SEQINTSTAT[0x0] SAVED_MODE[0= x11]=20 DFFSTAT[0x33] =46eb 18 08:00:48 wco-and kernel: SCSISIGI[0x0] SCSIPHASE[0x0] SCSIBUS[0x0]= =20 LASTPHASE[0x1] =46eb 18 08:00:48 wco-and kernel: SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x0]= =20 SEQINTCTL[0x0] =46eb 18 08:00:48 wco-and kernel: SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0]=20 QFREEZE_COUNT[0x24] =46eb 18 08:00:48 wco-and kernel: KERNEL_QFREEZE_COUNT[0x24]=20 MK_MESSAGE_SCB[0x8e] MK_MESSAGE_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: SSTAT0[0x0] SSTAT1[0x8] SSTAT2[0x0] SSTAT3 [0x0] PERRDIAG[0x0] =46eb 18 08:00:48 wco-and kernel: SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0]= =20 LQISTAT2[0x0] =46eb 18 08:00:48 wco-and kernel: LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0xe1] =46eb 18 08:00:48 wco-and kernel: =46eb 18 08:00:48 wco-and kernel: SCB Count =3D 512 CMDS_PENDING =3D 63 LAS= TSCB=20 0x1f6 CURRSCB 0x1f5 NEXTSCB 0xff80 =46eb 18 08:00:48 wco-and kernel: qinstart =3D 5542 qinfifonext =3D 5542 =46eb 18 08:00:48 wco-and kernel: QINFIFO: =46eb 18 08:00:48 wco-and kernel: WAITING_TID_QUEUES: =46eb 18 08:00:48 wco-and kernel: Pending list: =46eb 18 08:00:48 wco-and kernel: 200 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 486 FIFO_USE[0x0] SCB_CONTROL[0x62]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 227 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 208 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 483 FIFO_USE[0x0] SCB_CONTROL[0x62]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 138 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 392 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 154 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 234 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 411 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 155 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 195 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 415 FIFO_USE[0x0] SCB_CONTROL[0x62]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 503 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 204 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 152 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 469 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 133 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 222 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 235 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 498 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 202 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 451 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 471 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 232 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 455 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 198 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 401 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 242 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 419 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 448 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 245 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 132 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 213 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 137 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 161 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 194 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 388 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 408 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 190 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 460 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 393 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 488 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 457 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 215 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 163 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 140 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 454 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 201 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 199 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 143 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 399 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 458 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 405 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 230 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 473 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 389 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 396 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 226 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 472 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 136 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 450 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: 142 FIFO_USE[0x0] SCB_CONTROL[0x60]=20 SCB_SCSIID[0x17] =46eb 18 08:00:48 wco-and kernel: Total 63 =46eb 18 08:00:48 wco-and kernel: Kernel Free SCB lists: =46eb 18 08:00:48 wco-and kernel: Any Device: 501 502 157 456 413 482 490 1= 60=20 217 239 246 398 461 216 192 491 464 149 205 394 254 446 139 416 417 485 510= =20 395 410 478 244 500 145 495 508 412 470 406 403 467 484 459 489 496 447 409= =20 497 418 452 499 453 506 507 511 474 487 477 391 462 479 509 504 400 505 466= =20 414 397 468 493 404 463 402 476 494 465 475 480 390 449 481 407 420 421 422= =20 423 424 425 426 427 429 428 444 443 442 441 440 439 438 437 436 435 434 433= =20 432 431 430 445 492 387 386 385 384 383 382 381 380 379 378 377 376 375 374= =20 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355= =20 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336= =20 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317= =20 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298= =20 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279= =20 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260= =20 259 258 257 256 255 253 252 251 250 249 248 247 243 241 240 =46eb 18 08:00:48 wco-and kernel: 37 236 233 231 229 228 225 224 223 221 22= 0 219=20 218 214 212 211 210 209 207 206 203 197 196 193 191 189 188 187 186 185 184= =20 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165= =20 164 162 159 158 156 153 151 150 148 147 146 144 141 135 134 131 130 129 128= =20 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109= =20 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 = 86=20 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 = 60=20 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 = 34=20 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8= 7=20 6 5 4 3 2 1 0 =46eb 18 08:02:48 wco-and kernel: Sequencer Complete DMA-inprog list: =46eb 18 08:02:48 wco-and kernel: Sequencer Complete list: =46eb 18 08:02:48 wco-and kernel: Sequencer DMA-Up and Complete list: =46eb 18 08:02:48 wco-and kernel: Sequencer On QFreeze and Complete list: =46eb 18 08:02:48 wco-and kernel: =46eb 18 08:02:48 wco-and kernel: =46eb 18 08:02:48 wco-and kernel: ahd0: FIFO0 Active, LONGJMP =3D=3D 0x8277= , SCB=20 0x1a1 =46eb 18 08:02:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x10] DFCNTRL[0x= 4]=20 DFSTATUS[0x89] =46eb 18 08:02:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0]=20 DFFSXFRCTL[0x0] =46eb 18 08:02:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x2] SHADDR =3D 0x= 00,=20 SHCNT =3D 0x0 =46eb 18 08:02:48 wco-and kernel: HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x10] =46eb 18 08:02:48 wco-and kernel: =46eb 18 08:02:48 wco-and kernel: ahd0: FIFO1 Free, LONGJMP =3D=3D 0x8063, = SCB 0x1f9 =46eb 18 08:02:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0= ]=20 DFSTATUS[0x89] =46eb 18 08:02:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0]=20 DFFSXFRCTL[0x0] =46eb 18 08:02:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x5] SHADDR =3D 0x= 00,=20 SHCNT =3D 0x0 =46eb 18 08:02:48 wco-and kernel: HADDR =3D 0x00, HCNT =3D 0x0 CCSGCTL[0x0] =46eb 18 08:02:48 wco-and kernel: LQIN: 0x5 0x0 0x1 0xa1 0x0 0x0 0x0 0x0 0x= 0 0x0=20 0x0 0x0 0x0 0x0 0x18 0x0 0x0 0x0 0x2 0x0 =46eb 18 08:02:48 wco-and kernel: ahd0: LQISTATE =3D 0x30, LQOSTATE =3D 0x0= ,=20 OPTIONMODE =3D 0x42 =46eb 18 08:02:48 wco-and kernel: ahd0: OS_SPACE_CNT =3D 0x20 MAXCMDCNT =3D= 0x1 =46eb 18 08:02:48 wco-and kernel: ahd0: SAVED_SCSIID =3D 0x0 SAVED_LUN =3D = 0x0 =46eb 18 08:02:48 wco-and kernel: SIMODE0[0xc] =46eb 18 08:02:48 wco-and kernel: CCSCBCTL[0x4] =46eb 18 08:02:48 wco-and kernel: ahd0: REG0 =3D=3D 0x1e3, SINDEX =3D 0x104= , DINDEX =3D=20 0x104 =46eb 18 08:02:48 wco-and kernel: ahd0: SCBPTR =3D=3D 0xffe3, SCB_NEXT =3D= =3D 0xff80,=20 SCB_NEXT2 =3D=3D 0xff22 =46eb 18 08:02:48 wco-and kernel: CDB 2a 0 4 60 0 ef =46eb 18 08:02:48 wco-and kernel: STACK: 0x24 0x0 0x0 0x0 0x0 0x0 0x0 0x0 =46eb 18 08:02:48 wco-and kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends=20 >>>>>>>>>>>>>>>>>> =46eb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): SCB 154 - timed out =46eb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): Queuing a BDR SCB =46eb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): Task Management Func 0x= 1=20 Complete =46eb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): no longer in timeout, s= tatus=20 =3D 24b this is beeing repeated endless =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 14:57:50 2008 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 C9EC116A417 for ; Mon, 18 Feb 2008 14:57:50 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id 81E0E13C461 for ; Mon, 18 Feb 2008 14:57:49 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 3649 invoked by uid 80); 18 Feb 2008 14:57:26 -0000 Received: from 195.50.100.20 (SquirrelMail authenticated user gelsemap) by www.superhero.nl with HTTP; Mon, 18 Feb 2008 15:57:26 +0100 (CET) Message-ID: <9914.195.50.100.20.1203346646.squirrel@www.superhero.nl> In-Reply-To: <200802181149.17068.joao@matik.com.br> References: <200704182239.59842.gelsemap@superhero.nl> <200802180810.29049.joao@matik.com.br> <47B99107.3000204@samsco.org> <200802181149.17068.joao@matik.com.br> Date: Mon, 18 Feb 2008 15:57:26 +0100 (CET) From: "Gelsema, P \(Patrick\) - FreeBSD" To: "JoaoBR" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Gelsema, P \(Patrick\)" , freebsd-current@freebsd.org, "Gelsema, P \(Patrick\) - FreeBSD" , Niki Denev Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 14:57:51 -0000 On Mon, February 18, 2008 15:49, JoaoBR wrote: > On Monday 18 February 2008 11:07:03 Scott Long wrote: >> You are confusing people by posting a response to a discussion that has >> already moved beyond where you are responding.  The real fix to the >> original poster's problem has already been identified, please catch >> up. > > not so sure about this ... > > firstable I guess I was the original poster some month ago ... > > secondable I let it clear that it seems to work for Adaptec's 29320 but > not on > other adaptors which I let also clear in my former msg, just read it > entirely > Joao, is this because of your hack or because of the cvs commit: src/sys/dev/aic7xxx aic79xx_osm.c version 1.32? That is why I am confused. If you get it because of the committed version, could you please let me know how how I can repeat this on my machine, as I would love to see this version committed to RELENG_7_0. Rgds, Patrick >> >> Also, in the future, whether you are up to date on the discussion or >> not, making a post saying that something crashes/doesn't work, but >> without posting any of the debugging information that goes with it, >> is pretty close to being useless. > > > yep I guess so, take your time: > > from a SM MB > > ahd0: port > 0xa800-0xa8ff,0xa400-0xa4ff > mem 0xfc9fe000-0xfc9fffff irq 24 at device 3.0 on pci2 > ahd0: [ITHREAD] > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs > > > > Feb 18 08:00:48 wco-and kernel: Sequencer Complete DMA-inprog list: > Feb 18 08:00:48 wco-and kernel: Sequencer Complete list: > Feb 18 08:00:48 wco-and kernel: Sequencer DMA-Up and Complete list: > Feb 18 08:00:48 wco-and kernel: Sequencer On QFreeze and Complete list: > Feb 18 08:00:48 wco-and kernel: > Feb 18 08:00:48 wco-and kernel: > Feb 18 08:00:48 wco-and kernel: ahd0: FIFO0 Active, LONGJMP == 0x8277, SCB > 0x1f6 > Feb 18 08:00:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x10] > DFCNTRL[0x4] > DFSTATUS[0x89] > Feb 18 08:00:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0] > DFFSXFRCTL[0x0] > Feb 18 08:00:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x2] SHADDR = 0x00, > SHCNT = 0x0 > Feb 18 08:00:48 wco-and kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] > Feb 18 08:00:48 wco-and kernel: > Feb 18 08:00:48 wco-and kernel: ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB > 0x1f9 > Feb 18 08:00:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] > DFSTATUS[0x89] > Feb 18 08:00:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0] > DFFSXFRCTL[0x0] > Feb 18 08:00:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x5] SHADDR = 0x00, > SHCNT = 0x0 > Feb 18 08:00:48 wco-and kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x0] > Feb 18 08:00:48 wco-and kernel: LQIN: 0x5 0x0 0x1 0xf6 0x0 0x0 0x0 0x0 0x0 > 0x0 > 0x0 0x0 0x0 0x0 0x40 0x0 0x0 0x0 0x2 0x0 > Feb 18 08:00:48 wco-and kernel: ahd0: LQISTATE = 0x30, LQOSTATE = 0x0, > OPTIONMODE = 0x42 > Feb 18 08:00:48 wco-and kernel: ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x8 > Feb 18 08:00:48 wco-and kernel: ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 > Feb 18 08:00:48 wco-and kernel: SIMODE0[0xc] > Feb 18 08:00:48 wco-and kernel: CCSCBCTL[0x0] > Feb 18 08:00:48 wco-and kernel: ahd0: REG0 == 0xd9, SINDEX = 0x112, DINDEX > = > 0x102 > Feb 18 08:00:48 wco-and kernel: ahd0: SCBPTR == 0x9d, SCB_NEXT == 0xff80, > SCB_NEXT2 == 0xff22 > Feb 18 08:00:48 wco-and kernel: CDB 2a 0 0 80 88 eb > Feb 18 08:00:48 wco-and kernel: STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 > Feb 18 08:00:48 wco-and kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>> > Feb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): SCB 501 - timed out > Feb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): Queuing a BDR SCB > Feb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): Task Management Func 0x1 > Complete > Feb 18 08:00:48 wco-and kernel: (da1:ahd0:0:1:0): no longer in timeout, > status > = 24b > Feb 18 08:00:48 wco-and kernel: ahd0: Recovery Initiated - Card was not > paused > Feb 18 08:00:48 wco-and kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins > <<<<<<<<<<<<<<<<< > Feb 18 08:00:48 wco-and kernel: ahd0: Dumping Card State at program > address > 0x22 Mode 0x33 > Feb 18 08:00:48 wco-and kernel: INTSTAT[0x0] SELOID[0x1] SELID[0x0] > HS_MAILBOX[0x0] > Feb 18 08:00:48 wco-and kernel: INTCTL[0x80] SEQINTSTAT[0x0] > SAVED_MODE[0x11] > DFFSTAT[0x33] > Feb 18 08:00:48 wco-and kernel: SCSISIGI[0x0] SCSIPHASE[0x0] SCSIBUS[0x0] > LASTPHASE[0x1] > Feb 18 08:00:48 wco-and kernel: SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x0] > SEQINTCTL[0x0] > Feb 18 08:00:48 wco-and kernel: SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] > QFREEZE_COUNT[0x24] > Feb 18 08:00:48 wco-and kernel: KERNEL_QFREEZE_COUNT[0x24] > MK_MESSAGE_SCB[0x8e] MK_MESSAGE_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: SSTAT0[0x0] SSTAT1[0x8] SSTAT2[0x0] SSTAT3 > [0x0] PERRDIAG[0x0] > Feb 18 08:00:48 wco-and kernel: SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0] > LQISTAT2[0x0] > Feb 18 08:00:48 wco-and kernel: LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0xe1] > Feb 18 08:00:48 wco-and kernel: > Feb 18 08:00:48 wco-and kernel: SCB Count = 512 CMDS_PENDING = 63 LASTSCB > 0x1f6 CURRSCB 0x1f5 NEXTSCB 0xff80 > Feb 18 08:00:48 wco-and kernel: qinstart = 5542 qinfifonext = 5542 > Feb 18 08:00:48 wco-and kernel: QINFIFO: > Feb 18 08:00:48 wco-and kernel: WAITING_TID_QUEUES: > Feb 18 08:00:48 wco-and kernel: Pending list: > Feb 18 08:00:48 wco-and kernel: 200 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 486 FIFO_USE[0x0] SCB_CONTROL[0x62] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 227 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 208 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 483 FIFO_USE[0x0] SCB_CONTROL[0x62] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 138 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 392 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 154 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 234 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 411 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 155 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 195 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 415 FIFO_USE[0x0] SCB_CONTROL[0x62] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 503 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 204 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 152 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 469 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 133 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 222 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 235 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 498 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 202 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 451 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 471 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 232 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 455 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 198 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 401 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 242 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 419 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 448 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 245 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 132 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 213 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 137 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 161 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 194 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 388 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 408 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 190 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 460 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 393 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 488 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 457 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 215 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 163 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 140 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 454 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 201 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 199 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 143 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 399 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 458 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 405 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 230 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 473 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 389 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 396 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 226 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 472 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 136 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 450 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: 142 FIFO_USE[0x0] SCB_CONTROL[0x60] > SCB_SCSIID[0x17] > Feb 18 08:00:48 wco-and kernel: Total 63 > Feb 18 08:00:48 wco-and kernel: Kernel Free SCB lists: > Feb 18 08:00:48 wco-and kernel: Any Device: 501 502 157 456 413 482 490 > 160 > 217 239 246 398 461 216 192 491 464 149 205 394 254 446 139 416 417 485 > 510 > 395 410 478 244 500 145 495 508 412 470 406 403 467 484 459 489 496 447 > 409 > 497 418 452 499 453 506 507 511 474 487 477 391 462 479 509 504 400 505 > 466 > 414 397 468 493 404 463 402 476 494 465 475 480 390 449 481 407 420 421 > 422 > 423 424 425 426 427 429 428 444 443 442 441 440 439 438 437 436 435 434 > 433 > 432 431 430 445 492 387 386 385 384 383 382 381 380 379 378 377 376 375 > 374 > 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 > 355 > 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 > 336 > 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 > 317 > 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 > 298 > 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 > 279 > 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 > 260 > 259 258 257 256 255 253 252 251 250 249 248 247 243 241 240 > Feb 18 08:00:48 wco-and kernel: 37 236 233 231 229 228 225 224 223 221 220 > 219 > 218 214 212 211 210 209 207 206 203 197 196 193 191 189 188 187 186 185 > 184 > 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 > 165 > 164 162 159 158 156 153 151 150 148 147 146 144 141 135 134 131 130 129 > 128 > 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 > 109 > 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 > 86 > 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 > 60 > 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 > 34 > 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 > 8 7 > 6 5 4 3 2 1 0 > Feb 18 08:02:48 wco-and kernel: Sequencer Complete DMA-inprog list: > Feb 18 08:02:48 wco-and kernel: Sequencer Complete list: > Feb 18 08:02:48 wco-and kernel: Sequencer DMA-Up and Complete list: > Feb 18 08:02:48 wco-and kernel: Sequencer On QFreeze and Complete list: > Feb 18 08:02:48 wco-and kernel: > Feb 18 08:02:48 wco-and kernel: > Feb 18 08:02:48 wco-and kernel: ahd0: FIFO0 Active, LONGJMP == 0x8277, SCB > 0x1a1 > Feb 18 08:02:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x10] > DFCNTRL[0x4] > DFSTATUS[0x89] > Feb 18 08:02:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0] > DFFSXFRCTL[0x0] > Feb 18 08:02:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x2] SHADDR = 0x00, > SHCNT = 0x0 > Feb 18 08:02:48 wco-and kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10] > Feb 18 08:02:48 wco-and kernel: > Feb 18 08:02:48 wco-and kernel: ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB > 0x1f9 > Feb 18 08:02:48 wco-and kernel: SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0] > DFSTATUS[0x89] > Feb 18 08:02:48 wco-and kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0] > DFFSXFRCTL[0x0] > Feb 18 08:02:48 wco-and kernel: SOFFCNT[0x3f] MDFFSTAT[0x5] SHADDR = 0x00, > SHCNT = 0x0 > Feb 18 08:02:48 wco-and kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x0] > Feb 18 08:02:48 wco-and kernel: LQIN: 0x5 0x0 0x1 0xa1 0x0 0x0 0x0 0x0 0x0 > 0x0 > 0x0 0x0 0x0 0x0 0x18 0x0 0x0 0x0 0x2 0x0 > Feb 18 08:02:48 wco-and kernel: ahd0: LQISTATE = 0x30, LQOSTATE = 0x0, > OPTIONMODE = 0x42 > Feb 18 08:02:48 wco-and kernel: ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 > Feb 18 08:02:48 wco-and kernel: ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 > Feb 18 08:02:48 wco-and kernel: SIMODE0[0xc] > Feb 18 08:02:48 wco-and kernel: CCSCBCTL[0x4] > Feb 18 08:02:48 wco-and kernel: ahd0: REG0 == 0x1e3, SINDEX = 0x104, > DINDEX = > 0x104 > Feb 18 08:02:48 wco-and kernel: ahd0: SCBPTR == 0xffe3, SCB_NEXT == > 0xff80, > SCB_NEXT2 == 0xff22 > Feb 18 08:02:48 wco-and kernel: CDB 2a 0 4 60 0 ef > Feb 18 08:02:48 wco-and kernel: STACK: 0x24 0x0 0x0 0x0 0x0 0x0 0x0 0x0 > Feb 18 08:02:48 wco-and kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>> > Feb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): SCB 154 - timed out > Feb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): Queuing a BDR SCB > Feb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): Task Management Func 0x1 > Complete > Feb 18 08:02:48 wco-and kernel: (da1:ahd0:0:1:0): no longer in timeout, > status > = 24b > > > this is beeing repeated endless > > > -- > > João > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 15:28:29 2008 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 7C14616A41B for ; Mon, 18 Feb 2008 15:28:29 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 032F813C43E for ; Mon, 18 Feb 2008 15:28:28 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from nbc.matik.com.br (nbc.matik.com.br [200.152.88.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m1IFSOxN033380; Mon, 18 Feb 2008 12:28:25 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Mon, 18 Feb 2008 12:28:18 -0300 User-Agent: KMail/1.9.6 (enterprise 0.20071204.744707) References: <200704182239.59842.gelsemap@superhero.nl> <200802181149.17068.joao@matik.com.br> <9914.195.50.100.20.1203346646.squirrel@www.superhero.nl> In-Reply-To: <9914.195.50.100.20.1203346646.squirrel@www.superhero.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802181228.18458.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Gelsema, P \(Patrick\)" , Niki Denev , "Gelsema, P \(Patrick\) - FreeBSD" Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 15:28:29 -0000 On Monday 18 February 2008 11:57:26 Gelsema, P (Patrick) - FreeBSD wrote: > On Mon, February 18, 2008 15:49, JoaoBR wrote: > > On Monday 18 February 2008 11:07:03 Scott Long wrote: > >> You are confusing people by posting a response to a discussion that has > >> already moved beyond where you are responding. =A0The real fix to the > >> original poster's problem has already been identified, please catch > >> up. > > > > not so sure about this ... > > > > firstable I guess I was the original poster some month ago ... > > > > secondable I let it clear that it seems to work for Adaptec's 29320 but > > not on > > other adaptors which I let also clear in my former msg, just read it > > entirely > > Joao, > > is this because of your hack or because of the cvs commit: > src/sys/dev/aic7xxx aic79xx_osm.c version 1.32? > > That is why I am confused. > > If you get it because of the committed version, could you please let me > know how how I can repeat this on my machine, as I would love to see this > version committed to RELENG_7_0. no, also not my hack, I believe it was Niki or Justin who suggested to comm= ent=20 a part in cam_xpto.c only with this hack the problem occures BTW without it the drives are still only at 160/80 negotiated =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 15:39:34 2008 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 66D1A16A417 for ; Mon, 18 Feb 2008 15:39:34 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: from superman.superhero.nl (superhero.nl [82.95.198.17]) by mx1.freebsd.org (Postfix) with ESMTP id BBCEB13C448 for ; Mon, 18 Feb 2008 15:39:33 +0000 (UTC) (envelope-from freebsd@superhero.nl) Received: (qmail 5409 invoked by uid 80); 18 Feb 2008 15:39:11 -0000 Received: from 195.50.100.20 (SquirrelMail authenticated user gelsemap) by www.superhero.nl with HTTP; Mon, 18 Feb 2008 16:39:11 +0100 (CET) Message-ID: <63045.195.50.100.20.1203349151.squirrel@www.superhero.nl> In-Reply-To: <200802181228.18458.joao@matik.com.br> References: <200704182239.59842.gelsemap@superhero.nl> <200802181149.17068.joao@matik.com.br> <9914.195.50.100.20.1203346646.squirrel@www.superhero.nl> <200802181228.18458.joao@matik.com.br> Date: Mon, 18 Feb 2008 16:39:11 +0100 (CET) From: "Gelsema, P \(Patrick\) - FreeBSD" To: "JoaoBR" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "Gelsema, P \(Patrick\) - FreeBSD" , freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" , Niki Denev Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 15:39:34 -0000 On Mon, February 18, 2008 16:28, JoaoBR wrote: > On Monday 18 February 2008 11:57:26 Gelsema, P (Patrick) - FreeBSD wrote: >> On Mon, February 18, 2008 15:49, JoaoBR wrote: >> > On Monday 18 February 2008 11:07:03 Scott Long wrote: >> >> You are confusing people by posting a response to a discussion that >> has >> >> already moved beyond where you are responding.  The real fix to the >> >> original poster's problem has already been identified, please catch >> >> up. >> > >> > not so sure about this ... >> > >> > firstable I guess I was the original poster some month ago ... >> > >> > secondable I let it clear that it seems to work for Adaptec's 29320 >> but >> > not on >> > other adaptors which I let also clear in my former msg, just read it >> > entirely >> >> Joao, >> >> is this because of your hack or because of the cvs commit: >> src/sys/dev/aic7xxx aic79xx_osm.c version 1.32? >> >> That is why I am confused. >> >> If you get it because of the committed version, could you please let me >> know how how I can repeat this on my machine, as I would love to see >> this >> version committed to RELENG_7_0. > > > no, also not my hack, I believe it was Niki or Justin who suggested to > comment > a part in cam_xpto.c > > only with this hack the problem occures > > BTW without it the drives are still only at 160/80 negotiated on RELENG_7_0 I only updated aic79xx_osm.c and my drives successfully negotiated 320. No other hacks applied. Justin, could you MFC this before release? Cheers Patrick > > > -- > > João > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 15:48:45 2008 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 90D0A16A469 for ; Mon, 18 Feb 2008 15:48:45 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id E6A1C13C4D1 for ; Mon, 18 Feb 2008 15:48:44 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1412328rvb.43 for ; Mon, 18 Feb 2008 07:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=vDdA2t527WmO1LIgT6JCP5Fo4DHQsAiMvU15PIju/hQ=; b=k7ROl/kSu6iFGVzmrM3elnuBqeSB98myRUK+82CdPbu1XIEIdZ7udyrb7/Q+ppFd+9riIoLzRqElEdTOpR9e+llNnnX7xa4L71nrVxnkc90Bu32lt+okJMPXRZ50oNBRBauWBQt8T1F4EipHiV01xQxVVWpPBLLH+xpA1KVdW1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZmqfcOeDCugqNaHF6q1FikQOCcVOiY/DzTudUd55dqxQV0PhZIpbSGqRVSq/NYjYTU3+gwMUc1zZoVkG66IaTehslQBTb97ZvR4Y/gtCZmvTa9JMf0aWo4umA3Vy6fCjv4+knASGUv3AKPEoL2HdgQsGr78qjFFXOx0m/rU+4KI= Received: by 10.140.147.13 with SMTP id u13mr3904751rvd.228.1203349723416; Mon, 18 Feb 2008 07:48:43 -0800 (PST) Received: by 10.141.170.18 with HTTP; Mon, 18 Feb 2008 07:48:43 -0800 (PST) Message-ID: <2e77fc10802180748p5e78ef98s5fbbc27b8e7df3aa@mail.gmail.com> Date: Mon, 18 Feb 2008 15:48:43 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: JoaoBR In-Reply-To: <200802181228.18458.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200704182239.59842.gelsemap@superhero.nl> <200802181149.17068.joao@matik.com.br> <9914.195.50.100.20.1203346646.squirrel@www.superhero.nl> <200802181228.18458.joao@matik.com.br> X-Google-Sender-Auth: f31c06b805982c91 Cc: freebsd-current@freebsd.org, "Gelsema, P \(Patrick\)" Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 15:48:45 -0000 On Feb 18, 2008 3:28 PM, JoaoBR wrote: > On Monday 18 February 2008 11:57:26 Gelsema, P (Patrick) - FreeBSD wrote: > > On Mon, February 18, 2008 15:49, JoaoBR wrote: > > > On Monday 18 February 2008 11:07:03 Scott Long wrote: > > >> You are confusing people by posting a response to a discussion that has > > >> already moved beyond where you are responding. The real fix to the > > >> original poster's problem has already been identified, please catch > > >> up. > > > > > > not so sure about this ... > > > > > > firstable I guess I was the original poster some month ago ... > > > > > > secondable I let it clear that it seems to work for Adaptec's 29320 but > > > not on > > > other adaptors which I let also clear in my former msg, just read it > > > entirely > > > > Joao, > > > > is this because of your hack or because of the cvs commit: > > src/sys/dev/aic7xxx aic79xx_osm.c version 1.32? > > > > That is why I am confused. > > > > If you get it because of the committed version, could you please let me > > know how how I can repeat this on my machine, as I would love to see this > > version committed to RELENG_7_0. > > > no, also not my hack, I believe it was Niki or Justin who suggested to comment > a part in cam_xpto.c > > only with this hack the problem occures > > BTW without it the drives are still only at 160/80 negotiated > > There is some misunderstanding here. I had the negotiation problem, and as a result of this i started playing around with DTrace on this machine and discovered that if I comment these lines my drives were correctly detected. I posted this as a pointer/clue to the problem. Then Justin replied, that the actual problem is in the aic79xx driver not properly exporting it's capabilites to CAM, and the latest revisions of aic_79xx_osm.c > 1.30 fix this. There is no need to touch cam_xpt.c, just update aic_79xx_osm.c, and the problem should be resolved. --Niki From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 16:34:32 2008 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 64B0816A477; Mon, 18 Feb 2008 16:34:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3E7C613C4CC; Mon, 18 Feb 2008 16:34:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 562C646B5E; Mon, 18 Feb 2008 11:34:31 -0500 (EST) Date: Mon, 18 Feb 2008 16:34:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: <20080218163118.V49202@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 16:34:32 -0000 On Mon, 18 Feb 2008, Ivan Voras wrote: > I've again encountered the problem of FreeBSD 7 not wanting to boot on a HP > server. The last time was early in 7.x development on a HP blade > (2xdual-core Opteron), without any solution (reported on this list about a > year ago). This time it's on a ML 350 G5 machine, with a quad-core Xeon. > > The problem is very hard to diagnose - the entire machine locks up during > pci bus/device detection - the kernel debugger doesn't work, the keyboard > lights (PS/2 keyboard) don't work, it's completely frozen. > > This is on both i386 and AMD64 kernels. > > The machine freezes after detecting pcib6. The working 6.x kernel detects > upto pcib16, and the first device detected after pcib6 is the CISS > controller, so maybe it's the controller driver, but the first machine (the > blade) didn't have CISS controllers. FYI, I'm not seeing anything like this on the two DL 145 boxes I'm using for 10gbps testing with 7.x / 8.x. I did have problems with at least a couple of the BIOS revs in the past, so I'd repeat the advice offered elsewhere in the thread and make sure that it's up-to-date. There was one BIOS rev where I couldn't use a boot loader cross-built from i386 to amd64, but both the i386 boot loader and the natively built amd64 boot loader worked fine. The BIOS upgrade made the problem entirely go away, go figure... Otherwise, you're probably down to the printf model for debugging, unless you have an NMI button that can get into DDB? Mine have NMI buttons on the botherboard, I believe, but it requires opening the case to get to. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 17:20:03 2008 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 9180A16A474 for ; Mon, 18 Feb 2008 17:20:03 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id E05DA13C4D1 for ; Mon, 18 Feb 2008 17:20:02 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m1IHK0qe042570; Mon, 18 Feb 2008 14:20:00 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Mon, 18 Feb 2008 14:19:57 -0300 User-Agent: KMail/1.9.7 References: <200704182239.59842.gelsemap@superhero.nl> <200802181228.18458.joao@matik.com.br> <2e77fc10802180748p5e78ef98s5fbbc27b8e7df3aa@mail.gmail.com> In-Reply-To: <2e77fc10802180748p5e78ef98s5fbbc27b8e7df3aa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802181419.57455.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: Niki Denev , "Gelsema, P \(Patrick\)" Subject: Re: Adaptec AHD U320 operating as only U160 (take care with this hack!) 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, 18 Feb 2008 17:20:03 -0000 On Monday 18 February 2008 12:48:43 Niki Denev wrote: > On Feb 18, 2008 3:28 PM, JoaoBR wrote: > > On Monday 18 February 2008 11:57:26 Gelsema, P (Patrick) - FreeBSD wrot= e: > > > On Mon, February 18, 2008 15:49, JoaoBR wrote: > > > > On Monday 18 February 2008 11:07:03 Scott Long wrote: > > > >> You are confusing people by posting a response to a discussion that > > > >> has already moved beyond where you are responding. The real fix to > > > >> the original poster's problem has already been identified, please > > > >> catch up. > > > > > > > > not so sure about this ... > > > > > > > > firstable I guess I was the original poster some month ago ... > > > > > > > > secondable I let it clear that it seems to work for Adaptec's 29320 > > > > but not on > > > > other adaptors which I let also clear in my former msg, just read it > > > > entirely > > > > > > Joao, > > > > > > is this because of your hack or because of the cvs commit: > > > src/sys/dev/aic7xxx aic79xx_osm.c version 1.32? > > > > > > That is why I am confused. > > > > > > If you get it because of the committed version, could you please let = me > > > know how how I can repeat this on my machine, as I would love to see > > > this version committed to RELENG_7_0. > > > > no, also not my hack, I believe it was Niki or Justin who suggested to > > comment a part in cam_xpto.c > > > > only with this hack the problem occures > > > > BTW without it the drives are still only at 160/80 negotiated > > There is some misunderstanding here. > I had the negotiation problem, and as a result of this i started playing > around with DTrace on this machine and discovered that if I comment these > lines my drives were correctly detected. I posted this as a pointer/clue = to > the problem. Then Justin replied, that the actual problem is in the aic79= xx > driver not properly > exporting it's capabilites to CAM, and the latest revisions of > aic_79xx_osm.c > 1.30 > fix this. There is no need to touch cam_xpt.c, just update > aic_79xx_osm.c, and the problem > should be resolved. > well, or my english sounds greek but I never said something different, I s= aid=20 that the cam_xpto.c hack give up problems,=20 I never said that the new aic79xx_osm.c is a problem neither mentioned the= =20 file =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 17:29:48 2008 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 686F416A476 for ; Mon, 18 Feb 2008 17:29:48 +0000 (UTC) (envelope-from morten@lightworkings.dk) Received: from mail.tobocom.net (mail.tobocom.net [89.221.166.157]) by mx1.freebsd.org (Postfix) with SMTP id C118513C4E8 for ; Mon, 18 Feb 2008 17:29:47 +0000 (UTC) (envelope-from morten@lightworkings.dk) Received: from BigMac.local ([85.80.153.38]) by mail.tobocom.net with hMailServer ; Mon, 18 Feb 2008 18:09:27 +0100 Message-ID: <47B9BBC6.70808@lightworkings.dk> Date: Mon, 18 Feb 2008 18:09:26 +0100 From: =?ISO-8859-1?Q?Morten_Str=E5rup?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20080218163118.V49202@fledge.watson.org> In-Reply-To: <20080218163118.V49202@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 17:29:48 -0000 Robert Watson wrote: > > On Mon, 18 Feb 2008, Ivan Voras wrote: > >> I've again encountered the problem of FreeBSD 7 not wanting to boot >> on a HP server. The last time was early in 7.x development on a HP >> blade (2xdual-core Opteron), without any solution (reported on this >> list about a year ago). This time it's on a ML 350 G5 machine, with a >> quad-core Xeon. >> >> The problem is very hard to diagnose - the entire machine locks up >> during pci bus/device detection - the kernel debugger doesn't work, >> the keyboard lights (PS/2 keyboard) don't work, it's completely frozen. >> >> This is on both i386 and AMD64 kernels. >> >> The machine freezes after detecting pcib6. The working 6.x kernel >> detects upto pcib16, and the first device detected after pcib6 is the >> CISS controller, so maybe it's the controller driver, but the first >> machine (the blade) didn't have CISS controllers. > > FYI, I'm not seeing anything like this on the two DL 145 boxes I'm > using for 10gbps testing with 7.x / 8.x. I did have problems with at > least a couple of the BIOS revs in the past, so I'd repeat the advice > offered elsewhere in the thread and make sure that it's up-to-date. > There was one BIOS rev where I couldn't use a boot loader cross-built > from i386 to amd64, but both the i386 boot loader and the natively > built amd64 boot loader worked fine. The BIOS upgrade made the > problem entirely go away, go figure... > > Otherwise, you're probably down to the printf model for debugging, > unless you have an NMI button that can get into DDB? Mine have NMI > buttons on the botherboard, I believe, but it requires opening the > case to get to. > Hi! It is possible to invoke an NMI through the Intregrated LightsOut management system that is built into the server. Look under Diagnostics when you get into the iLO system. Kind regards Morten Strårup From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 18:48:30 2008 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 732D016A46D for ; Mon, 18 Feb 2008 18:48:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 221FC13C4EC for ; Mon, 18 Feb 2008 18:48:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRB2N-0000sn-Il for freebsd-current@freebsd.org; Mon, 18 Feb 2008 18:48:24 +0000 Received: from 78-1-122-238.adsl.net.t-com.hr ([78.1.122.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Feb 2008 18:48:23 +0000 Received: from ivoras by 78-1-122-238.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Feb 2008 18:48:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 18 Feb 2008 19:48:07 +0100 Lines: 34 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09E1F125CEB83C1CA440C171" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-122-238.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 18:48:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09E1F125CEB83C1CA440C171 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Eygene Ryabinkin wrote: > I have a couple of BL640c and older BLp running 7.0 -- > no problems encountered. While this is not the direct answer to > your question, had you tried to update the blade firmware to the > latest versions with Firmware Maintenance CD? Sometimes it helps... Thanks for the suggestion, but the blade server is deployed now and will = stay with 6.x until there's a reason to move. --------------enig09E1F125CEB83C1CA440C171 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHudLwldnAQVacBcgRAiEoAJ9NWoWdPk+/IM+WHLZexfGUFZtJxQCg0buZ VKKMGy774gtf6cT7JVmhDZ8= =Tx90 -----END PGP SIGNATURE----- --------------enig09E1F125CEB83C1CA440C171-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 18:55:16 2008 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 2F16416A418 for ; Mon, 18 Feb 2008 18:55:16 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AE65613C448 for ; Mon, 18 Feb 2008 18:55:15 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRB8u-0001Rx-SN for freebsd-current@freebsd.org; Mon, 18 Feb 2008 18:55:08 +0000 Received: from 78-1-122-238.adsl.net.t-com.hr ([78.1.122.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Feb 2008 18:55:08 +0000 Received: from ivoras by 78-1-122-238.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Feb 2008 18:55:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 18 Feb 2008 19:55:01 +0100 Lines: 59 Message-ID: References: <20080218163118.V49202@fledge.watson.org> <47B9BBC6.70808@lightworkings.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3CF956B1B906DF44B7276FFD" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-122-238.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <47B9BBC6.70808@lightworkings.dk> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 18:55:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3CF956B1B906DF44B7276FFD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Morten Str=C3=A5rup wrote: > Robert Watson wrote: >> >> FYI, I'm not seeing anything like this on the two DL 145 boxes I'm=20 >> using for 10gbps testing with 7.x / 8.x. I did have problems with at = >> least a couple of the BIOS revs in the past, so I'd repeat the advice = >> offered elsewhere in the thread and make sure that it's up-to-date. =20 >> There was one BIOS rev where I couldn't use a boot loader cross-built = >> from i386 to amd64, but both the i386 boot loader and the natively=20 >> built amd64 boot loader worked fine. The BIOS upgrade made the=20 >> problem entirely go away, go figure... >> >> Otherwise, you're probably down to the printf model for debugging,=20 >> unless you have an NMI button that can get into DDB? Mine have NMI=20 >> buttons on the botherboard, I believe, but it requires opening the=20 >> case to get to. >> >=20 > Hi! >=20 > It is possible to invoke an NMI through the Intregrated LightsOut=20 > management system that is built into the server. >=20 > Look under Diagnostics when you get into the iLO system. Thanks for the ideas, Robert and Morten - I'll try them. The reason I=20 thought it was something well known/common was that this is the second=20 HP system I tried 7.0 on (very different from each other) and both of=20 them failed in what looks as the same place :( It might just be bad luck.= I have the machine on my desk so any other hardware-related ideas are=20 also welcome. --------------enig3CF956B1B906DF44B7276FFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHudSGldnAQVacBcgRAoC1AJ0ZJ3d2eEN0cvIpYBLtnOUSqlvlPwCeJg8H mvv5t5OR39uN7zWbhDV7N5o= =Jk8r -----END PGP SIGNATURE----- --------------enig3CF956B1B906DF44B7276FFD-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 19:04:06 2008 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 498E716A41B; Mon, 18 Feb 2008 19:04:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 01A5113C4E1; Mon, 18 Feb 2008 19:04:05 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=PO+vww3Ebmxx6yJK6ZpcG+a6N+7U2dK6cJojgakJc6z1TtP8IeAIrBARsCD0+oqws7Y8W02eIS21ILPA/epeAwnw4FTpUo+eKIinA+kFXYPA2BFDd1KzTbX+JCpQ8A9eH5hWlC3sRJfxGtSy682JhLbDdC6aJ1dpKJdhpalSR68=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRBHY-000Lxy-Dc; Mon, 18 Feb 2008 22:04:04 +0300 Date: Mon, 18 Feb 2008 22:04:03 +0300 From: Eygene Ryabinkin To: Ivan Voras Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 18 Feb 2008 19:04:06 -0000 Ivan, Mon, Feb 18, 2008 at 07:48:07PM +0100, Ivan Voras wrote: >> I have a couple of BL640c and older BLp running 7.0 -- >> no problems encountered. While this is not the direct answer to >> your question, had you tried to update the blade firmware to the >> latest versions with Firmware Maintenance CD? Sometimes it helps... > > Thanks for the suggestion, but the blade server is deployed now and will > stay with 6.x until there's a reason to move. But you can try to update firmware images on the ML350. Firmware Maintenance CD 7.91 supports this beast: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=3279711&prodTypeId=15351&prodSeriesId=1121586&swLang=8&taskId=135&swEnvOID=2026#2913 http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=15351&prodSeriesId=1121586&prodNameId=3279711&swEnvOID=2026&swLang=8&mode=2&taskId=135&swItem=MTX-26a0f9e294764a91b76b282f2a -- Eygene From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 19:08:12 2008 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 2D80016A473 for ; Mon, 18 Feb 2008 19:08:12 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id B841413C4E1 for ; Mon, 18 Feb 2008 19:08:11 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id m1IIba5e013288; Mon, 18 Feb 2008 18:37:36 GMT Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JRArw-0003RK-KD; Mon, 18 Feb 2008 18:37:36 +0000 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m1IIbaWY058328; Mon, 18 Feb 2008 18:37:36 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m1IIbaDu058327; Mon, 18 Feb 2008 18:37:36 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Richard Todd In-Reply-To: <20080215231507.EAB7D641@mx2.synetsystems.com> References: <20080215231507.EAB7D641@mx2.synetsystems.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Feb 2008 18:37:35 +0000 Message-Id: <1203359855.43782.60.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org Subject: Re: ZFS: data sometimes not getting correctly flushed to disk (possible mmap/write issue)? 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, 18 Feb 2008 19:08:12 -0000 On Fri, 2008-02-15 at 16:59 -0600, Richard Todd wrote: > Bit of a long story behind this one: I've been playing with the "picard" > program in ports to do re-tagging of audio (mp3/ogg) files, and was having > problems with the tagging process creating corrupted .ogg files. On > further investigation trying to debug this, I found that the "picard" > program seemed to be correctly writing the files if I checked them > immediately, but the files were corrupt when I looked at them later. > Further investigation and coming up with test cases brought me to the > surprising conclusion that ZFS was to blame -- under certain conditions ZFS > seems not to be writing all the data in the file out to disk correctly. > The file appears to be good only so long as the file's data is in cache, but > the data actually on disk doesn't match what's in cache. I don't currently have a system that I can test this with, but is there any chance you could make the following change to your script? #!/bin/sh NAME=$1 LEN=$2 rm $NAME ./a.out $NAME $LEN ./gen2.py $NAME md5 $NAME + cp $NAME /some/ufs/filesystem/$NAME.1 ls -l $NAME sudo umount /u3 sudo mount -t zfs u3 /u3 md5 $NAME + cp $NAME /some/ufs/filesystem/$NAME.2 ls -l $NAME + md5 /some/ufs/filesystem/$NAME.? and when you find files that differ, compare the two copies stored on the UFS filesystem with cmp(1)? I'd be interested to know exactly what the corruption looks like - is a single bit differen? Or was an entire page destroyed? Gavin Gavin From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 20:10:35 2008 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 A5C0216A473; Mon, 18 Feb 2008 20:10:35 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 92B4613C4D9; Mon, 18 Feb 2008 20:10:35 +0000 (UTC) (envelope-from ulf@alameda.net) Received: by mail.alameda.net (Postfix, from userid 1000) id A3D0233D3F; Mon, 18 Feb 2008 11:43:55 -0800 (PST) Date: Mon, 18 Feb 2008 11:43:55 -0800 From: Ulf Zimmermann To: Robert Watson Message-ID: <20080218194355.GZ87650@evil.alameda.net> References: <20080218163118.V49202@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080218163118.V49202@fledge.watson.org> User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Urgent problem - 7.x doesn't work on HP servers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 20:10:35 -0000 On Mon, Feb 18, 2008 at 04:34:31PM +0000, Robert Watson wrote: > > On Mon, 18 Feb 2008, Ivan Voras wrote: > > >I've again encountered the problem of FreeBSD 7 not wanting to boot on a > >HP server. The last time was early in 7.x development on a HP blade > >(2xdual-core Opteron), without any solution (reported on this list about a > >year ago). This time it's on a ML 350 G5 machine, with a quad-core Xeon. > > > >The problem is very hard to diagnose - the entire machine locks up during > >pci bus/device detection - the kernel debugger doesn't work, the keyboard > >lights (PS/2 keyboard) don't work, it's completely frozen. > > > >This is on both i386 and AMD64 kernels. > > > >The machine freezes after detecting pcib6. The working 6.x kernel detects > >upto pcib16, and the first device detected after pcib6 is the CISS > >controller, so maybe it's the controller driver, but the first machine > >(the blade) didn't have CISS controllers. > > FYI, I'm not seeing anything like this on the two DL 145 boxes I'm using > for 10gbps testing with 7.x / 8.x. I did have problems with at least a > couple of the BIOS revs in the past, so I'd repeat the advice offered > elsewhere in the thread and make sure that it's up-to-date. There was one > BIOS rev where I couldn't use a boot loader cross-built from i386 to amd64, > but both the i386 boot loader and the natively built amd64 boot loader > worked fine. The BIOS upgrade made the problem entirely go away, go > figure... > > Otherwise, you're probably down to the printf model for debugging, unless > you have an NMI button that can get into DDB? Mine have NMI buttons on the > botherboard, I believe, but it requires opening the case to get to. You can generate NMI from the iLO and iLO2 interface. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 22:35:33 2008 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 7560E16A41A for ; Mon, 18 Feb 2008 22:35:33 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 15C6613C461 for ; Mon, 18 Feb 2008 22:35:32 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP for id m1IMZVXI002208 (8.13.4/1.4); Mon, 18 Feb 2008 23:35:31 +0100 (MET) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP for id m1IMZVOK002205 (8.13.4/2.02); Mon, 18 Feb 2008 23:35:31 +0100 (MET) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Mon, 18 Feb 2008 23:35:31 +0100 (MET) From: Michiel Boland To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: panic upon starting X in recent -CURRENTs (intel driver) 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, 18 Feb 2008 22:35:33 -0000 > Hi. After recent upgrade (from 21 dec to today's src) the kernel crashes when > starting X with > > panic: pmap_remove_all: page 0xc56e07f8 is fictitious FWIW below is a trivial program to re-create a similar crash. Needs root, obviously. But still shouldn't cause a panic though. Note that the trick in the program is that we mmap two pages, then munmap only half of them. #include #include #include #include #include static const off_t map_address = 0xa0000; static const size_t map_size = 0x1000; static int testit(int fd) { void *p; int rv; p = mmap(NULL, 2 * map_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, map_address); if (p == MAP_FAILED) { perror("mmap"); return -1; } rv = *(char *) p; if (munmap(p, map_size) == -1) { perror("munmap"); return -1; } return rv; } int main(void) { int fd, rv; fd = open("/dev/mem", O_RDWR); if (fd == -1) { perror("open"); return 1; } rv = testit(fd); close(fd); return rv; } From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 23:29:36 2008 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 399CD16A41A for ; Mon, 18 Feb 2008 23:29:36 +0000 (UTC) (envelope-from freebsd-current.alex@trull.org) Received: from mail.internationalconspiracy.org (mail.internationalconspiracy.org [85.234.142.62]) by mx1.freebsd.org (Postfix) with ESMTP id F2CB813C45A for ; Mon, 18 Feb 2008 23:29:35 +0000 (UTC) (envelope-from freebsd-current.alex@trull.org) Received: from localhost (mail.internationalconspiracy.org [85.234.142.62]) by mail.internationalconspiracy.org (Postfix) with ESMTP id 0D0CFACB3 for ; Mon, 18 Feb 2008 23:12:05 +0000 (GMT) X-Virus-Scanned: amavisd-new at mail.internationalconspiracy.org Received: from mail.internationalconspiracy.org ([85.234.142.62]) by localhost (mail.internationalconspiracy.org [85.234.142.62]) (amavisd-new, port 10024) with LMTP id zTKkQyBFLXO4 for ; Mon, 18 Feb 2008 23:12:02 +0000 (GMT) Received: from [192.168.124.200] (77-96-69-222.cable.ubr09.croy.blueyonder.co.uk [77.96.69.222]) by mail.internationalconspiracy.org (Postfix) with ESMTP id 908C7ACAB for ; Mon, 18 Feb 2008 23:12:02 +0000 (GMT) Message-ID: <47BA10C1.5030701@trull.org> Date: Mon, 18 Feb 2008 23:12:01 +0000 From: Alex Trull User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: 1202955279.6548.2.camel@section-8.internal.avioc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: hptrr driver panics on 7.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current.alex@trull.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 23:29:36 -0000 Issue also confirmed with the rocketraid 2310 / revision 2.2 firmware on amd64. -- Alex From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 23:44:32 2008 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 9BDF716A41B for ; Mon, 18 Feb 2008 23:44:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4029113C468 for ; Mon, 18 Feb 2008 23:44:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from ydesk.samsco.home (ydesk.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m1INiShj017175; Mon, 18 Feb 2008 16:44:29 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47BA185C.6030703@samsco.org> Date: Mon, 18 Feb 2008 16:44:28 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: freebsd-current.alex@trull.org References: 1202955279.6548.2.camel@section-8.internal.avioc.org <47BA10C1.5030701@trull.org> In-Reply-To: <47BA10C1.5030701@trull.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: hptrr driver panics on 7.0-RC2 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, 18 Feb 2008 23:44:32 -0000 Alex Trull wrote: > Issue also confirmed with the rocketraid 2310 / revision 2.2 firmware on > amd64. Yeah, known issue that will be addressed shortly. Sorry for the inconvenience. Does it work with RC1 for you? Scott From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 07:41:56 2008 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 F1BEA16A473 for ; Tue, 19 Feb 2008 07:41:55 +0000 (UTC) (envelope-from freebsd-current.alex@trull.org) Received: from mail.internationalconspiracy.org (mail.internationalconspiracy.org [85.234.142.62]) by mx1.freebsd.org (Postfix) with ESMTP id A4C3613C4D1 for ; Tue, 19 Feb 2008 07:41:55 +0000 (UTC) (envelope-from freebsd-current.alex@trull.org) Received: from localhost (mail.internationalconspiracy.org [85.234.142.62]) by mail.internationalconspiracy.org (Postfix) with ESMTP id BE449B745; Tue, 19 Feb 2008 07:41:54 +0000 (GMT) X-Virus-Scanned: amavisd-new at mail.internationalconspiracy.org Received: from mail.internationalconspiracy.org ([85.234.142.62]) by localhost (mail.internationalconspiracy.org [85.234.142.62]) (amavisd-new, port 10024) with LMTP id 8qkA6ktrcdUc; Tue, 19 Feb 2008 07:41:33 +0000 (GMT) Received: from [192.168.124.200] (77-96-69-222.cable.ubr09.croy.blueyonder.co.uk [77.96.69.222]) by mail.internationalconspiracy.org (Postfix) with ESMTP id A22D0B727; Tue, 19 Feb 2008 07:41:33 +0000 (GMT) Message-ID: <47BA882C.7090103@trull.org> Date: Tue, 19 Feb 2008 07:41:32 +0000 From: Alex Trull User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Scott Long References: 1202955279.6548.2.camel@section-8.internal.avioc.org <47BA10C1.5030701@trull.org> <47BA185C.6030703@samsco.org> In-Reply-To: <47BA185C.6030703@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: hptrr driver panics on 7.0-RC2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current.alex@trull.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 07:41:56 -0000 Scott Long wrote: > Alex Trull wrote: >> Issue also confirmed with the rocketraid 2310 / revision 2.2 firmware >> on amd64. > > Yeah, known issue that will be addressed shortly. Sorry for the > inconvenience. Does it work with RC1 for you? > > Scott > _______________________________________________ > 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" Yes - the quickest recovery was booting the rc1 livefs image followed by copying over that image's /boot/kernel. Thanks. -- Alex From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 08:57:41 2008 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 4631516A420 for ; Tue, 19 Feb 2008 08:57:41 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by mx1.freebsd.org (Postfix) with ESMTP id 21D0013C44B for ; Tue, 19 Feb 2008 08:57:40 +0000 (UTC) (envelope-from vehemens@verizon.net) Received: from susy.dsl-verizon.net ([71.106.237.229]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWH0011B6VL0VPH@vms173001.mailsrvcs.net> for freebsd-current@freebsd.org; Tue, 19 Feb 2008 01:45:21 -0600 (CST) Date: Mon, 18 Feb 2008 23:57:31 -0800 From: vehemens To: freebsd-current@freebsd.org Message-id: <200802182357.31764.vehemens@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline User-Agent: KMail/1.9.6 Subject: Re: panic w/ ohci_add_done:addr xxxx not found 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, 19 Feb 2008 08:57:41 -0000 There are several existing FreeBSD PRs (88568, 104810, 107827, 120283) describing OHCI problems. Googling also shows a number of others having OHCI problems. My M2A-VM with BIOS version 1603 does it as well, so I wouldn't expect a BIOS update to fix the problem. Some testing indicates that its' a result of legacy USB support. If I disable it, the kernel doesn't panic, however the boot loader doesn't work with a USB keyboard so it's not a real fix. Probably need to prod the driver folks given that USB keyboards and mouses are becoming more common. From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:55:20 2008 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 733B416A417 for ; Tue, 19 Feb 2008 09:55:20 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.freebsd.org (Postfix) with ESMTP id 2F23A13C448 for ; Tue, 19 Feb 2008 09:55:20 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from chaos.nox (80.221.12.61) by pne-smtpout3-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A78857000C6C37 for freebsd-current@freebsd.org; Tue, 19 Feb 2008 09:45:49 +0100 Date: Tue, 19 Feb 2008 10:45:32 +0200 From: Mikael Ikivesi To: freebsd-current@freebsd.org Message-ID: <20080219104532.0dc2b565@chaos.nox> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: 2 core dumps 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, 19 Feb 2008 09:55:20 -0000 Hi with RELENG_7 (4-7 days old) I have come across with 2 panic/reboot. The first hapened while machine was compiling ports. When I came back the machine had rebooted and coredumped. Second time was while was surfing while machine compiled audacious-plugins. Because X was running I did not see any messages. Laptop just rebooted and dumped. I could not find anything from log files. -Mikael ----First dump--- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: e1134000 Uptime: 4h57m8s Physical memory: 886 MB Dumping 192 MB: 177 161 145 129 113 97 81 65 49 33 17 1 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) (kgdb) q #0 doadump () at pcpu.h:195 #1 0xc05cdfba in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc05ce3c4 in panic ( fmt=0xc0987a2a "vm_fault: fault on nofault entry, addr: %lx") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0845d43 in vm_fault (map=0xc1054000, vaddr=3776135168, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:275 #4 0xc09145a3 in trap_pfault (frame=0xe1136be0, usermode=0, eva=3776135168) at /usr/src/sys/i386/i386/trap.c:801 #5 0xc0914f3c in trap (frame=0xe1136be0) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc08fdbeb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0912636 in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 Previous frame inner to this frame (corrupt stack?) ----Second dump--- GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf799fb5c fault code = supervisor write, page not present instruction pointer = 0x20:0xc08e8d49 stack pointer = 0x28:0xe114fc7c frame pointer = 0x28:0xe114fcbc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 39 (irq12: psm0) trap number = 12 panic: page fault Uptime: 25m27s Physical memory: 886 MB Dumping 116 MB: 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) (kgdb) q #0 doadump () at pcpu.h:195 #1 0xc05cdfba in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc05ce3c4 in panic (fmt=0xc09541fd "%s") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc09141fd in trap_fatal (frame=0xe114fc3c, eva=4154063708) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc091457a in trap_pfault (frame=0xe114fc3c, usermode=0, eva=4154063708) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0914f3c in trap (frame=0xe114fc3c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc08fdbeb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc08e8d49 in psmintr (arg=0xc399f000) at /usr/src/sys/dev/atkbdc/psm.c:2094 #8 0xc05b000d in ithread_loop (arg=0xc39aa200) at /usr/src/sys/kern/kern_intr.c:1036 #9 0xc05acd4d in fork_exit (callout=0xc05afee0 , arg=0xc39aa200, frame=0xe114fd38) at /usr/src/sys/kern/kern_fork.c:781 #10 0xc08fdc60 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:09:37 2008 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 E27BC16A419 for ; Tue, 19 Feb 2008 10:09:37 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 174D513C4E5; Tue, 19 Feb 2008 10:09:36 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BAAADF.2000707@FreeBSD.org> Date: Tue, 19 Feb 2008 11:09:35 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mikael Ikivesi References: <20080219104532.0dc2b565@chaos.nox> In-Reply-To: <20080219104532.0dc2b565@chaos.nox> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 2 core dumps 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, 19 Feb 2008 10:09:38 -0000 Mikael Ikivesi wrote: > Hi > > with RELENG_7 (4-7 days old) I have come across with 2 > panic/reboot. Both look like signs of failing hardware to me. Kris From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 10:36:30 2008 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 666D916A418 for ; Tue, 19 Feb 2008 10:36:30 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id B01CE13C4E9 for ; Tue, 19 Feb 2008 10:36:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7487519E071 for ; Tue, 19 Feb 2008 11:17:51 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id B625819E070 for ; Tue, 19 Feb 2008 11:17:45 +0100 (CET) Message-ID: <47BAACD7.5050303@quip.cz> Date: Tue, 19 Feb 2008 11:17:59 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 10:36:30 -0000 Hi, I got kernel panic after removing 2GB file previously created by dd. root@retezat ~/# dd if=/dev/zero of=/vol1/test.file bs=1m count=2048 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 132.726566 secs (16179757 bytes/sec) root@retezat ~/# rm /vol1/test.file and then I wanted to create same file on another mountpoint with dd if=/dev/zero of=/vol0/test.file bs=1m count=2048 but system paniced and rebooted. I done this many times before on the same machine and on the other machines with the same version of FreeBSD without panic, so I don't know why system paniced this time. I am using gmirror from whole two disks. /vol0 = USF2 + gjournal /vol1 = UFS2 + SU This is the first time I am reporting kernel panic, so let me know if I can provide some more informations. Note: this is 'production' machine, so I can't try to reproduce the panic. See kgdb backtrace on the end of this e-mail Miroslav Lachman > gmirror list Geom name: gm0 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 2 ID: 482383735 Providers: 1. Name: mirror/gm0 Mediasize: 494994980352 (461G) Sectorsize: 512 Mode: r8w8e10 Consumers: 1. Name: ad4 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 2 ID: 877246835 2. Name: ad6 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 2 ID: 757379427 > gjournal list Geom name: gjournal 344136938 ID: 344136938 Providers: 1. Name: mirror/gm0s2e.journal Mediasize: 417680393728 (389G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm0s2d Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e1 Jend: 2147483136 Jstart: 0 Role: Journal 2. Name: mirror/gm0s2e Mediasize: 417680394240 (389G) Sectorsize: 512 Mode: r1w1e1 Role: Data > df -ih Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/mirror/gm0s1a 496M 129M 327M 28% 1830 63960 3% / devfs 1.0K 1.0K 0B 100% 0 0 100% /dev /dev/mirror/gm0s1e 7.7G 1.9G 5.2G 27% 206466 853372 19% /usr /dev/mirror/gm0s1d 33G 2.8G 27G 9% 26519 4448359 1% /var /dev/mirror/gm0s1f 2.4G 2.1M 2.2G 0% 1079 328647 0% /tmp /dev/mirror/gm0s2e.journal 377G 18G 328G 5% 611265 50449469 1% /vol0 /dev/mirror/gm0s2f 19G 2.0G 16G 11% 3 2637819 0% /vol1 FreeBSD 7.0-RC1 #0: Mon Dec 24 12:18:24 UTC 2007 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 root@retezat ~/# kgdb /boot/kernel/kernel /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: dev = mirror/gm0s2e.journal, block = 6417368, fs = /vol0 panic: ffs_blkfree: freeing free block cpuid = 0 Uptime: 1d19h21m35s Physical memory: 2035 MB Dumping 290 MB: 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0753f07 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc07541c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc092becd in ffs_blkfree (ump=0xc59b7900, fs=0xc54a6000, devvp=0xc597acc0, bno=6417368, size=16384, inum=4) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1893 #4 0xc093456a in ffs_indirtrunc (ip=0xc8c51108, lbn=-139276, dbn=25591968, lastbn=-1, level=0, countp=0xe84bf920) at /usr/src/sys/ufs/ffs/ffs_inode.c:619 #5 0xc0934525 in ffs_indirtrunc (ip=0xc8c51108, lbn=-2061, dbn=376384, lastbn=-1, level=1, countp=0xe84bfa04) at /usr/src/sys/ufs/ffs/ffs_inode.c:614 #6 0xc0935a3b in ffs_truncate (vp=0xc7a04110, length=0, flags=Variable "flags" is not available. ) at /usr/src/sys/ufs/ffs/ffs_inode.c:418 #7 0xc0960056 in ufs_setattr (ap=0xe84bfb68) at /usr/src/sys/ufs/ufs/ufs_vnops.c:566 #8 0xc0a7d3c2 in VOP_SETATTR_APV (vop=0xc0bb2100, a=0xe84bfb68) at vnode_if.c:583 #9 0xc07d7c76 in kern_open (td=0xc8470c60, path=0x38202043
, pathseg=UIO_USERSPACE, flags=Variable "flags" is not available. ) at vnode_if.h:315 #10 0xc07d7de0 in open (td=0xc8470c60, uap=0xe84bfcfc) at /usr/src/sys/kern/vfs_syscalls.c:995 #11 0xc0a67955 in syscall (frame=0xe84bfd38) at /usr/src/sys/i386/i386/trap.c:1035 #12 0xc0a4dfb0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 12:53:10 2008 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 8F25416A46D for ; Tue, 19 Feb 2008 12:53:10 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb7:ef56]) by mx1.freebsd.org (Postfix) with ESMTP id 0438C13C46B for ; Tue, 19 Feb 2008 12:53:09 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id m1JCr0nr010809; Tue, 19 Feb 2008 13:53:00 +0100 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Tue, 19 Feb 2008 13:53:00 +0100 User-Agent: KMail/1.9.7 References: <47BAACD7.5050303@quip.cz> In-Reply-To: <47BAACD7.5050303@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802191353.00235.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 12:53:10 -0000 What revision of sys/vm/vm_object.c do you have? -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 12:56:52 2008 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 D38B416A480 for ; Tue, 19 Feb 2008 12:56:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7A613C4D5 for ; Tue, 19 Feb 2008 12:56:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRS1i-0007EI-9y for freebsd-current@freebsd.org; Tue, 19 Feb 2008 12:56:50 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 12:56:50 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 12:56:50 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 19 Feb 2008 13:59:07 +0100 Lines: 58 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F389B210ED1CA22E2867B53" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 19 Feb 2008 12:56:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F389B210ED1CA22E2867B53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eygene Ryabinkin wrote: > Ivan, >=20 > Mon, Feb 18, 2008 at 07:48:07PM +0100, Ivan Voras wrote: >>> I have a couple of BL640c and older BLp running 7.0 -- >>> no problems encountered. While this is not the direct answer to >>> your question, had you tried to update the blade firmware to the >>> latest versions with Firmware Maintenance CD? Sometimes it helps... >> Thanks for the suggestion, but the blade server is deployed now and wi= ll=20 >> stay with 6.x until there's a reason to move. >=20 > But you can try to update firmware images on the ML350. Firmware > Maintenance CD 7.91 supports this beast: Updating the firmware didn't help. I generated a NMI and have the debugger running. Apparently it's stuck in DELAY; the trace (transcribed by hand) is: DELAY() vpd_nextbyte() pci_read_device() pci_add_children() acpi_pci_attach() device_attach() bus_generic_attach() acpi_pcib_attach() acpi_pcib_pci_attach() device_attach() bus_generic_attach() =2E.. this stack goes on... note repetition of device_attach in the stack, it's repeated at least three more times. I don't know if this is normal. Any suggestion what to do while in the debugger? --------------enig9F389B210ED1CA22E2867B53 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHutKbldnAQVacBcgRAn8ZAKDGuwFnXMJfyw7+U/+c/UMYvk4z8wCg+ysm l8b+8NoVweKb9NuNak76oEI= =i5kj -----END PGP SIGNATURE----- --------------enig9F389B210ED1CA22E2867B53-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 13:25:13 2008 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 1164116A417; Tue, 19 Feb 2008 13:25:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 95E1E13C47E; Tue, 19 Feb 2008 13:25:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JRST4-0008NV-2l; Tue, 19 Feb 2008 15:25:10 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1JDOY91040022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 15:24:34 +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.2/8.14.2) with ESMTP id m1JDOuv5001564; Tue, 19 Feb 2008 15:24:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1JDOtpW001563; Tue, 19 Feb 2008 15:24:55 +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: Tue, 19 Feb 2008 15:24:55 +0200 From: Kostik Belousov To: Michiel Boland Message-ID: <20080219132455.GD57756@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p0yZhIIvPymhuc7/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 88d0fd334128e7d5bb9b9ebe4fef9048 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2256 [Feb 19 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic upon starting X in recent -CURRENTs (intel driver) 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, 19 Feb 2008 13:25:13 -0000 --p0yZhIIvPymhuc7/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2008 at 11:35:31PM +0100, Michiel Boland wrote: > >Hi. After recent upgrade (from 21 dec to today's src) the kernel crashes= =20 > >when starting X with > > > >panic: pmap_remove_all: page 0xc56e07f8 is fictitious >=20 > FWIW below is a trivial program to re-create a similar crash. Needs root,= =20 > obviously. But still shouldn't cause a panic though. Note that the trick= =20 > in the program is that we mmap two pages, then munmap only half of them. >=20 > #include > #include > #include > #include > #include >=20 > static const off_t map_address =3D 0xa0000; > static const size_t map_size =3D 0x1000; >=20 > static int testit(int fd) > { > void *p; > int rv; >=20 > p =3D mmap(NULL, 2 * map_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, > map_address); > if (p =3D=3D MAP_FAILED) { > perror("mmap"); > return -1; > } > rv =3D *(char *) p; > if (munmap(p, map_size) =3D=3D -1) { > perror("munmap"); > return -1; > } > return rv; > } >=20 > int main(void) > { > int fd, rv; >=20 > fd =3D open("/dev/mem", O_RDWR); > if (fd =3D=3D -1) { > perror("open"); > return 1; > } > rv =3D testit(fd); > close(fd); > return rv; > } What happen there is that munmap() do the split for the /dev/mem mapping. This caused the OBJT_DEVICE ref_count to be bumped, and vm_map_entry_delete= () called vm_object_page_remove(). The later called pmap_remove_all() unconditionally. pmap_remove_all has the KASSERT that fails exactly when supplied fictitious page. It becomes KASSERT in the rev. 1.106 of i386/pmap.c, committed 2008/01/08, it was under the PMAP_DIAGNOSTIC before. Since such page has md.pv_list empty anyway, this KASSERT seems to be only the statement of intent. The change below would prevent the panic by not calling pmap_remove_all from vm_object_page_remove for such pages. Alan, do you have objections ? [Alternative seems to be a removal of the assertions from all pmap implementations, that also weaken the invariants for other callers that do skip fictitious pages]. diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c index 21c0ac6..21ee10d 100644 --- a/sys/vm/vm_object.c +++ b/sys/vm/vm_object.c @@ -1884,7 +1884,8 @@ again: */ if ((wirings =3D p->wire_count) !=3D 0 && (wirings =3D pmap_page_wired_mappings(p)) !=3D p->wire_count) { - pmap_remove_all(p); + if ((p->flags & PG_FICTITIOUS) =3D=3D 0) + pmap_remove_all(p); /* Account for removal of managed, wired mappings. */ p->wire_count -=3D wirings; if (!clean_only) @@ -1898,7 +1899,8 @@ again: if (p->valid & p->dirty) continue; } - pmap_remove_all(p); + if ((p->flags & PG_FICTITIOUS) =3D=3D 0) + pmap_remove_all(p); /* Account for removal of managed, wired mappings. */ if (wirings !=3D 0) p->wire_count -=3D wirings; --p0yZhIIvPymhuc7/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke62KYACgkQC3+MBN1Mb4jA6wCgx09AvshM2AbjR/FEKDFBCeAe HssAn3801VxP8WIJjiNIuMRjaNcdY3uS =FRNq -----END PGP SIGNATURE----- --p0yZhIIvPymhuc7/-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 13:32:34 2008 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 7E9EB16A418 for ; Tue, 19 Feb 2008 13:32:34 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D56B13C442 for ; Tue, 19 Feb 2008 13:32:33 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRSaC-0000PB-Lt for freebsd-current@freebsd.org; Tue, 19 Feb 2008 13:32:28 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 13:32:28 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 13:32:28 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 19 Feb 2008 14:34:49 +0100 Lines: 31 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9182DA1F112D4581AC91CA91" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 19 Feb 2008 13:32:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9182DA1F112D4581AC91CA91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Updating the firmware didn't help. I generated a NMI and have the > debugger running. Apparently it's stuck in DELAY;=20 Hmm, new data! It works on 8-CURRENT! Something's fishy here. I'll try and investigate more, but if anyone has more ideas about where to look, I'd appreciate them - I don't want to run a -CURRENT system in production. --------------enig9182DA1F112D4581AC91CA91 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHutr5ldnAQVacBcgRAnHvAJ0RAuTQqoZNTCHDXUlJjNMSDm1D3wCglxbp 51XYFM7b/8WwrG6vv2W7QWQ= =KhSB -----END PGP SIGNATURE----- --------------enig9182DA1F112D4581AC91CA91-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 13:34:58 2008 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 337FE16A41B for ; Tue, 19 Feb 2008 13:34:58 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id E181813C478 for ; Tue, 19 Feb 2008 13:34:57 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E770419E070; Tue, 19 Feb 2008 14:34:56 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id A974C19E073; Tue, 19 Feb 2008 14:34:54 +0100 (CET) Message-ID: <47BADB0C.4020000@quip.cz> Date: Tue, 19 Feb 2008 14:35:08 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Pieter de Goeje References: <47BAACD7.5050303@quip.cz> <200802191353.00235.pieter@degoeje.nl> In-Reply-To: <200802191353.00235.pieter@degoeje.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 13:34:58 -0000 Pieter de Goeje wrote: > What revision of sys/vm/vm_object.c do you have? __FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19 05:48:45 alc Exp $"); System is FreeBSD 7.0-RC1 i386 installation. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 13:49:48 2008 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 3BAF916A421 for ; Tue, 19 Feb 2008 13:49:48 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id A4E4513C46A for ; Tue, 19 Feb 2008 13:49:47 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1JDnhPc029724; Tue, 19 Feb 2008 14:49:46 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1JDnhp9029723; Tue, 19 Feb 2008 14:49:43 +0100 (CET) (envelope-from olli) Date: Tue, 19 Feb 2008 14:49:43 +0100 (CET) Message-Id: <200802191349.m1JDnhp9029723@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, 000.fbsd@quip.cz In-Reply-To: <47BAACD7.5050303@quip.cz> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Feb 2008 14:49:46 +0100 (CET) Cc: Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, 000.fbsd@quip.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 13:49:48 -0000 Miroslav Lachman wrote: > panic: ffs_blkfree: freeing free block I had exactly the same panic, also on a FreeBSD 7 system with gmirror. I'm not sure if it's related, but I tell you my story anyway ... Apparently it was caused by a bug that caused corruption in the file system. The bug was fixed in October, IIRC, but the corruption remained and eventually crashed the machine again. A forced fsck ("fsck -f -y") seems to have fixed it for me finally. So, my recommendation is this: - Make sure you update to the latest sources. - "fsck -f -y" all your filesystems in single-user mode. Alternatively, newfs them and restore from backup. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 14:13:50 2008 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 5F79616A473 for ; Tue, 19 Feb 2008 14:13:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 19C6213C4D1 for ; Tue, 19 Feb 2008 14:13:49 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id AA18619E071 for ; Tue, 19 Feb 2008 15:13:48 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id 95D9B19E054 for ; Tue, 19 Feb 2008 15:13:46 +0100 (CET) Message-ID: <47BAE428.1040101@quip.cz> Date: Tue, 19 Feb 2008 15:14:00 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG References: <200802191349.m1JDnhp9029723@lurza.secnetix.de> In-Reply-To: <200802191349.m1JDnhp9029723@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 14:13:50 -0000 Oliver Fromme wrote: > Miroslav Lachman wrote: > > panic: ffs_blkfree: freeing free block > > I had exactly the same panic, also on a FreeBSD 7 system > with gmirror. I'm not sure if it's related, but I tell > you my story anyway ... > > Apparently it was caused by a bug that caused corruption > in the file system. The bug was fixed in October, IIRC, > but the corruption remained and eventually crashed the > machine again. A forced fsck ("fsck -f -y") seems to have > fixed it for me finally. > > So, my recommendation is this: > - Make sure you update to the latest sources. > - "fsck -f -y" all your filesystems in single-user mode. > Alternatively, newfs them and restore from backup. This was on 1 week old (brand new HW) machine. Just installed and put it in production (migration from one datacenter to another) so I think that it is not affected by anything from October or before. /vol0 and /vol1 was newfs-ed about 2 days befor kernel panic. But thank you for suggesion anyway. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 14:14:56 2008 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 AEC0D16A420 for ; Tue, 19 Feb 2008 14:14:56 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 01EC113C4DB for ; Tue, 19 Feb 2008 14:14:55 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 19 Feb 2008 13:48:15 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp017) with SMTP; 19 Feb 2008 14:48:15 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX19k9opTyvdkjnnd8kiHO1q+zYo4ViTRcNWkUBSaFJ OriVAeqIenTxwH Message-ID: <47BADE07.9020402@gmx.de> Date: Tue, 19 Feb 2008 14:47:51 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 19 Feb 2008 14:36:10 +0000 Subject: nfs mounts don't work through fstab 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, 19 Feb 2008 14:14:56 -0000 My nfs mounts haven't been working by their fstab entries, ever since I switched to RELENG_7. Today I took the time tracking the issue down by adding lots of printf to mount.c. I tracked the problem down to the function fstabscan() in the file "/usr/src/lib/libc/gen/fstab.c". The result of my testing was that it is now obligatory to set 'sw', 'ro' or 'rw' in the options list. This is a change, that in my opinion should either be undone or documented in "/usr/src/UPDATING" and in the fstab(5) manual page. From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:33:39 2008 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 24FF716A419 for ; Tue, 19 Feb 2008 15:33:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D030613C44B for ; Tue, 19 Feb 2008 15:33:38 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRUTL-00070A-Sw for freebsd-current@freebsd.org; Tue, 19 Feb 2008 15:33:31 +0000 Received: from dhcp100.ifado.de ([195.253.22.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 15:33:31 +0000 Received: from wb by dhcp100.ifado.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Feb 2008 15:33:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wilhelm B. Kloke" Date: Tue, 19 Feb 2008 15:33:22 +0000 (UTC) Organization: InstArbPhysUniDo Lines: 17 Message-ID: References: <47BADE07.9020402@gmx.de> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp100.ifado.de User-Agent: slrn/0.9.8.1 (FreeBSD) Cache-Post-Path: vestein.arb-phys.uni-dortmund.de!unknown@localhost X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Sender: news Subject: Re: nfs mounts don't work through fstab 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, 19 Feb 2008 15:33:39 -0000 Dominic Fandrey schrieb: > My nfs mounts haven't been working by their fstab entries, ever since I > switched to RELENG_7. Today I took the time tracking the issue down by > adding lots of printf to mount.c. I tracked the problem down to the function > fstabscan() in the file "/usr/src/lib/libc/gen/fstab.c". > I have a problem which is possibly related to this one. My FreeBSD7-amd64 system fails to boot, because the network device nfe0 cannot be configured by dhclient. Dhclient refuses to work because / is not yet writeable. So I have to mount_-u_-o_r_/ manually, start dhclient_nfe0 again, and quit single-user mode to get the system booted. -- W.B. Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:34:37 2008 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 B9D4F16A417 for ; Tue, 19 Feb 2008 15:34:37 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 744B013C4E9 for ; Tue, 19 Feb 2008 15:34:37 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 4437B5E49 for ; Tue, 19 Feb 2008 18:18:11 +0300 (MSK) Date: Tue, 19 Feb 2008 18:18:10 +0300 From: Igor Sysoev To: freebsd-current@FreeBSD.ORG Message-ID: <20080219151809.GF57366@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: malloc(3) ignores RLIMIT_DATA 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, 19 Feb 2008 15:34:37 -0000 malloc(3) in FreeBSD 7 uses mmap() (then sbrk() on 32-bit platform) and ignores RLIMIT_DATA. FreeBSD 8's malloc() can be configured to use sbrk() only ("Dm"), but default setting is "DM". Instead of gracefully handling ENOMEM condition processes grows and swaps out, causing livelock. Using RLIMIT_AS (aka RLIMIT_VMEM) as suggested interacts badly with stack growth in process low memory condition. As sbrk() is less preferable because of framentation and race conditions, why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use it in malloc(3) ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:36:46 2008 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 C141316A468 for ; Tue, 19 Feb 2008 15:36:46 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb5:7e66]) by mx1.freebsd.org (Postfix) with ESMTP id 3E82B13C457 for ; Tue, 19 Feb 2008 15:36:46 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id m1JFaa3x012395; Tue, 19 Feb 2008 16:36:36 +0100 From: Pieter de Goeje To: Miroslav Lachman <000.fbsd@quip.cz> Date: Tue, 19 Feb 2008 16:36:36 +0100 User-Agent: KMail/1.9.7 References: <47BAACD7.5050303@quip.cz> <200802191353.00235.pieter@degoeje.nl> <47BADB0C.4020000@quip.cz> In-Reply-To: <47BADB0C.4020000@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802191636.36444.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 15:36:46 -0000 On Tuesday 19 February 2008, Miroslav Lachman wrote: > Pieter de Goeje wrote: > > What revision of sys/vm/vm_object.c do you have? > > __FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19 > 05:48:45 alc Exp $"); > Hmm that's odd, some time ago I tracked this issue down to this commit, but apparently there's still something wrong or the issue was fixed in another commit in the same timeframe. > System is FreeBSD 7.0-RC1 i386 installation. Can you please try updating to the latest 7.0 (and/or 7-stable) to see if you still can still reproduce this? I will try to reproduce this here. > > Miroslav Lachman -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:51:11 2008 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 6474816A417 for ; Tue, 19 Feb 2008 15:51:11 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 16D2213C458 for ; Tue, 19 Feb 2008 15:51:10 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=AvBgmgkzLu1UTKsMaIaJ4JMMFSpWS/orjQb3edYN8kbHbWu5QHazcR5H9uuhVNb755ILdZAY9yl3Y4o0U4Dtx5IdfBwlHNKM1bWwYxkCcHAIwi3+5au4+ZiCb9V2iuMuryMaI9ede71hh5ZNBORfs8NSbDZgYOSza5YVNE+21mg=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRUkP-0003WZ-9W; Tue, 19 Feb 2008 18:51:09 +0300 Date: Tue, 19 Feb 2008 18:51:08 +0300 From: Eygene Ryabinkin To: Dominic Fandrey Message-ID: <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> References: <47BADE07.9020402@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BADE07.9020402@gmx.de> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 19 Feb 2008 15:51:11 -0000 Dominic, good day. Tue, Feb 19, 2008 at 02:47:51PM +0100, Dominic Fandrey wrote: > My nfs mounts haven't been working by their fstab entries, ever since I > switched to RELENG_7. Today I took the time tracking the issue down by > adding lots of printf to mount.c. I tracked the problem down to the > function > fstabscan() in the file "/usr/src/lib/libc/gen/fstab.c". > > The result of my testing was that it is now obligatory to set 'sw', 'ro' or > 'rw' in the options list. Could you, please, show your /etc/fstab? I see that lib/libc/gen/fstab.c was last changed 4 years ago (not counting revision 1.15, where the advertising license clause was removed), so perhaps fstabscan() is not guilty. Thank you! -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 15:51:25 2008 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 8494716A4EE for ; Tue, 19 Feb 2008 15:51:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 25E1713C4CC for ; Tue, 19 Feb 2008 15:51:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JRUkZ-000C1o-EB for freebsd-current@freebsd.org; Tue, 19 Feb 2008 17:51:23 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1JFonJI044698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 17:50:49 +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.2/8.14.2) with ESMTP id m1JFpB0o009295; Tue, 19 Feb 2008 17:51:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1JFpBSD009294; Tue, 19 Feb 2008 17:51:11 +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: Tue, 19 Feb 2008 17:51:11 +0200 From: Kostik Belousov To: Pieter de Goeje Message-ID: <20080219155111.GE57756@deviant.kiev.zoral.com.ua> References: <47BAACD7.5050303@quip.cz> <200802191353.00235.pieter@degoeje.nl> <47BADB0C.4020000@quip.cz> <200802191636.36444.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3OIx1w/Pkt2PF0IZ" Content-Disposition: inline In-Reply-To: <200802191636.36444.pieter@degoeje.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: bb9f355b5be917825c280d06cf0e20ab X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2263 [Feb 19 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-current@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 15:51:25 -0000 --3OIx1w/Pkt2PF0IZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2008 at 04:36:36PM +0100, Pieter de Goeje wrote: > On Tuesday 19 February 2008, Miroslav Lachman wrote: > > Pieter de Goeje wrote: > > > What revision of sys/vm/vm_object.c do you have? > > > > __FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19 > > 05:48:45 alc Exp $"); > > >=20 > Hmm that's odd, some time ago I tracked this issue down to this commit, b= ut=20 > apparently there's still something wrong or the issue was fixed in anothe= r=20 > commit in the same timeframe. The issue can appear for a lot of different reasons. The panic is mostly a post-check for something already gone wrong. I would first check the filesystem with fsck and somehow verified consistency of the mirror. Another reason for the panic was fixed in rev. 1.50.10.1 of the sys/ufs/ffs/ffs_balloc.c. But the conditions that caused panic fixed in this rev. usually appear when filesystem becomes full. --3OIx1w/Pkt2PF0IZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke6+u4ACgkQC3+MBN1Mb4iIcQCg98qqSrMgsQSXgOVOsKRuQUX3 oMUAoIEJQkJP1SPPZFZ98Lkvnu9/MTZ3 =uibf -----END PGP SIGNATURE----- --3OIx1w/Pkt2PF0IZ-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 17:08:50 2008 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 89D0316A469 for ; Tue, 19 Feb 2008 17:08:50 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB7013C461 for ; Tue, 19 Feb 2008 17:08:50 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTP id 72195129831; Tue, 19 Feb 2008 09:13:02 -0800 (PST) Message-ID: <47BB0D29.5080403@freebsd.org> Date: Tue, 19 Feb 2008 09:08:57 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20080213) MIME-Version: 1.0 To: Igor Sysoev References: <20080219151809.GF57366@rambler-co.ru> In-Reply-To: <20080219151809.GF57366@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: malloc(3) ignores RLIMIT_DATA 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, 19 Feb 2008 17:08:50 -0000 Igor Sysoev wrote: > malloc(3) in FreeBSD 7 uses mmap() (then sbrk() on 32-bit platform) > and ignores RLIMIT_DATA. FreeBSD 8's malloc() can be configured > to use sbrk() only ("Dm"), but default setting is "DM". I plan to merge these changes to RELENG_7 shortly after FreeBSD 7.0 is released. As for the default, "DM", there is a strong argument that malloc() should try hard to succeed, and only fail prematurely if the user has added constraints via resource limits. Unfortunately, RELENG_7_0 will not have the proper MALLOC_OPTIONS support to disable mmap()-based allocation, but the release engineers prudently deemed the necessary malloc(3) changes too risky so late in the release cycle. > As sbrk() is less preferable because of framentation and race conditions, > why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use it > in malloc(3) ? There has been general agreement among the people I've discussed this issue with that the correct solution is to add a separate resource limit for anonymously mapped memory, which would provide capabilities similar to what your suggestion would provide. Jason From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 18:02:33 2008 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 71E1616A468 for ; Tue, 19 Feb 2008 18:02:33 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 291E613C467 for ; Tue, 19 Feb 2008 18:02:32 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1JRWnU-0001Uz-BE; Tue, 19 Feb 2008 21:02:28 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 2D0207D1C05; Tue, 19 Feb 2008 21:02:27 +0300 (MSK) Date: Tue, 19 Feb 2008 21:02:27 +0300 From: Stanislav Sedov To: "Wilhelm B. Kloke" Message-ID: <20080219180227.GC73371@dracon.ht-systems.ru> References: <47BADE07.9020402@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 19 Feb 2008 18:02:33 -0000 On Tue, Feb 19, 2008 at 03:33:22PM +0000 Wilhelm B. Kloke mentioned: > Dominic Fandrey schrieb: > > My nfs mounts haven't been working by their fstab entries, ever since I > > switched to RELENG_7. Today I took the time tracking the issue down by > > adding lots of printf to mount.c. I tracked the problem down to the function > > fstabscan() in the file "/usr/src/lib/libc/gen/fstab.c". > > > I have a problem which is possibly related to this one. My FreeBSD7-amd64 > system fails to boot, because the network device nfe0 cannot be > configured by dhclient. Dhclient refuses to work because / is not > yet writeable. So I have to mount_-u_-o_r_/ manually, start > dhclient_nfe0 again, and quit single-user mode to get the > system booted. > Do you mount your / via nfs? -- Stanislav Sedov ST4096-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 16:20:20 2008 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 7BC9F16A420 for ; Tue, 19 Feb 2008 16:20:20 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DC34513C467 for ; Tue, 19 Feb 2008 16:20:19 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 19 Feb 2008 16:20:18 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp028) with SMTP; 19 Feb 2008 17:20:18 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX19Ai10zCd5AjxvJpDUI41c5dufv32H23sWrGBahdj irjd6sKxtrj4d1 Message-ID: <47BB01BE.4010309@gmx.de> Date: Tue, 19 Feb 2008 17:20:14 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Eygene Ryabinkin References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> In-Reply-To: <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 19 Feb 2008 18:35:40 +0000 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 19 Feb 2008 16:20:20 -0000 Eygene Ryabinkin wrote: > Dominic, good day. > > Tue, Feb 19, 2008 at 02:47:51PM +0100, Dominic Fandrey wrote: >> My nfs mounts haven't been working by their fstab entries, ever since I >> switched to RELENG_7. Today I took the time tracking the issue down by >> adding lots of printf to mount.c. I tracked the problem down to the >> function >> fstabscan() in the file "/usr/src/lib/libc/gen/fstab.c". >> >> The result of my testing was that it is now obligatory to set 'sw', 'ro' or >> 'rw' in the options list. > > Could you, please, show your /etc/fstab? I see that lib/libc/gen/fstab.c > was last changed 4 years ago (not counting revision 1.15, where the > advertising license clause was removed), so perhaps fstabscan() is > not guilty. > > Thank you! These 2 lines have been in use since 6.0 release: mobileKamikaze:/usr/src /usr/src nfs -b,-T,-R=5,noauto 0 0 mobileKamikaze:/usr/obj /usr/obj nfs -b,-T,-R=5,noauto 0 0 They stopped working with the switch to RELENG_7. # mount /usr/src/ 0 /root fstab: /etc/fstab:27: Inappropriate file type or format fstab: /etc/fstab:28: Inappropriate file type or format fstab: /etc/fstab:27: Inappropriate file type or format fstab: /etc/fstab:28: Inappropriate file type or format mount: /usr/src: unknown special file or file system fstabscan() is the place where the "Inappropriate file type or format" error is printed. The pointer char* cp either points to a string "rw", "ro" or "sw". If none of these are present cp is a NULL-pointer when the final check in line 207 is reached. So error(EFTYPE) is called. From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 18:58:09 2008 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 C4B6216A469 for ; Tue, 19 Feb 2008 18:58:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 89F0C13C4D5 for ; Tue, 19 Feb 2008 18:58:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9FD3946BC9; Tue, 19 Feb 2008 13:58:08 -0500 (EST) Date: Tue, 19 Feb 2008 18:58:08 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jason Evans In-Reply-To: <47BB0D29.5080403@freebsd.org> Message-ID: <20080219185615.R21494@fledge.watson.org> References: <20080219151809.GF57366@rambler-co.ru> <47BB0D29.5080403@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Igor Sysoev , freebsd-current@FreeBSD.ORG Subject: Re: malloc(3) ignores RLIMIT_DATA 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, 19 Feb 2008 18:58:09 -0000 On Tue, 19 Feb 2008, Jason Evans wrote: >> As sbrk() is less preferable because of framentation and race conditions, >> why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use it >> in malloc(3) ? > > There has been general agreement among the people I've discussed this issue > with that the correct solution is to add a separate resource limit for > anonymously mapped memory, which would provide capabilities similar to what > your suggestion would provide. Konstantine has updated his patches and reported on them in the recent status report: http://www.freebsd.org/news/status/report-2007-10-2007-12.html#VM-Overcommit Here's the main site for information on the patch: http://people.freebsd.org/~kib/overcommit/ He describes a per-uid limit, but I think it might also be useful to have a per-process limit tht can also be enforced, although possibly not by default, so that protecting applications from each other doesn't require creating separate users for them. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 19:38:52 2008 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 537F116A421; Tue, 19 Feb 2008 19:38:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id DE58113C45A; Tue, 19 Feb 2008 19:38:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JRYIi-000BR4-2U; Tue, 19 Feb 2008 21:38:50 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1JJcK9O050704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 21:38:20 +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.2/8.14.2) with ESMTP id m1JJcgmH074393; Tue, 19 Feb 2008 21:38:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1JJcggs074392; Tue, 19 Feb 2008 21:38:42 +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: Tue, 19 Feb 2008 21:38:42 +0200 From: Kostik Belousov To: Robert Watson Message-ID: <20080219193842.GG57756@deviant.kiev.zoral.com.ua> References: <20080219151809.GF57366@rambler-co.ru> <47BB0D29.5080403@freebsd.org> <20080219185615.R21494@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NZdDWKHbmnyWnFtu" Content-Disposition: inline In-Reply-To: <20080219185615.R21494@fledge.watson.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 6dc4245230f22f3abb357b69a6da667e X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2264 [Feb 19 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Igor Sysoev , Jason Evans , freebsd-current@freebsd.org Subject: Re: malloc(3) ignores RLIMIT_DATA 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, 19 Feb 2008 19:38:52 -0000 --NZdDWKHbmnyWnFtu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2008 at 06:58:08PM +0000, Robert Watson wrote: >=20 > On Tue, 19 Feb 2008, Jason Evans wrote: >=20 > >>As sbrk() is less preferable because of framentation and race condition= s,=20 > >>why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use = it=20 > >>in malloc(3) ? > > > >There has been general agreement among the people I've discussed this=20 > >issue with that the correct solution is to add a separate resource limit= =20 > >for anonymously mapped memory, which would provide capabilities similar = to=20 > >what your suggestion would provide. >=20 > Konstantine has updated his patches and reported on them in the recent=20 > status report: >=20 > http://www.freebsd.org/news/status/report-2007-10-2007-12.html#VM-Overc= ommit >=20 > Here's the main site for information on the patch: >=20 > http://people.freebsd.org/~kib/overcommit/ >=20 > He describes a per-uid limit, but I think it might also be useful to have= a=20 > per-process limit tht can also be enforced, although possibly not by=20 > default, so that protecting applications from each other doesn't require= =20 > creating separate users for them. Yes, per-process limits can be added too, although it would require some additional thinking. The persistent objects backed by anonymous memory, like SysV shm or shm_open(2) handles would be billed for the creator only. It is not immediately obvious whether it is right or not. Anyway, I want to get the review first, before doing further modifications. --NZdDWKHbmnyWnFtu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke7MEEACgkQC3+MBN1Mb4ikQgCfZrnzQ+FjqJHniRl/1KTOILm7 ymUAoNZmzI/NfVMhASNHC07i2dT4MxDc =7VSO -----END PGP SIGNATURE----- --NZdDWKHbmnyWnFtu-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 19:48:57 2008 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 AD67B16A46E for ; Tue, 19 Feb 2008 19:48:57 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.freebsd.org (Postfix) with ESMTP id 724A413C44B for ; Tue, 19 Feb 2008 19:48:57 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from [80.221.12.61] (80.221.12.61) by pne-smtpout3-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A78857000D13E9 for freebsd-current@freebsd.org; Tue, 19 Feb 2008 20:48:56 +0100 From: Mikael Ikivesi To: freebsd-current In-Reply-To: <47BAAADF.2000707@FreeBSD.org> References: <20080219104532.0dc2b565@chaos.nox> <47BAAADF.2000707@FreeBSD.org> Content-Type: text/plain Date: Tue, 19 Feb 2008 21:48:40 +0200 Message-Id: <1203450520.7248.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Subject: Re: 2 core dumps 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, 19 Feb 2008 19:48:57 -0000 On Tue, 2008-02-19 at 11:09 +0100, Kris Kennaway wrote: > Mikael Ikivesi wrote: > > Hi > > > > with RELENG_7 (4-7 days old) I have come across with 2 > > panic/reboot. > > Both look like signs of failing hardware to me. > This didn't happen with RELENG_6. For me it only paniced once because I forgot to unmount usb drive before I removed it. Little while ago I upgraded to RELENG_7. The problem appeared few times after that. And this has not happened with Linux. If I switch from X to console and back I get some jerkiness/momentary freezing of system. This might be related to synaptics touchpad or radeon xpress 200m. And I think these are related to crashes too. It takes a moment before X comes back after hitting alt-F9. First the screen is bit corrupted and only then it gets back properly. During this corrupt screen phase most of the stuff freeze for a moment. Few media players continue to play music uninterrupted (ex. audacious) but most of them always freeze for awhile (ex. mplayer) Moving touchpad before X has 'resumed' properly sometimes causes this freezing to last more than 5 secs. The second of the coredumps happened just few seconds after this kind of freezing and switching back to console. Is there anything I can do to help tracking reason for these panics? -Mikael From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 21:58:31 2008 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 E3BA816A417 for ; Tue, 19 Feb 2008 21:58:31 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id A118413C4F2 for ; Tue, 19 Feb 2008 21:58:31 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [192.168.1.34] (unknown [83.167.116.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTP id 79E2F17086 for ; Wed, 20 Feb 2008 00:47:43 +0300 (MSK) Message-ID: <47BB4E5D.7010505@citrin.ru> Date: Wed, 20 Feb 2008 00:47:09 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: tcsh in current-8.0 coredump 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, 19 Feb 2008 21:58:32 -0000 Problem was described here: http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html This was fixed for RELENG_7: http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c Revision 1.1.1.8 (vendor branch): download - view: text, markup, annotated - select for diffs Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp Branches: ZOULAS, MAIN CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, RELENG_7 Diff to: previous 1.1.1.7: preferred, colored Changes since revision 1.1.1.7: +2 -1 lines Import vendor patch to fix postcmd regression in tcsh-6.15.00. ------- But this bug was not fixed in HEAD. -- WBR, Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 22:58:12 2008 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 1581C16A469 for ; Tue, 19 Feb 2008 22:58:12 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id CBCE413C469 for ; Tue, 19 Feb 2008 22:58:11 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BE72019E023; Tue, 19 Feb 2008 23:58:10 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTP id AD44419E019; Tue, 19 Feb 2008 23:58:08 +0100 (CET) Message-ID: <47BB5F0E.8030206@quip.cz> Date: Tue, 19 Feb 2008 23:58:22 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Pieter de Goeje References: <47BAACD7.5050303@quip.cz> <200802191353.00235.pieter@degoeje.nl> <47BADB0C.4020000@quip.cz> <200802191636.36444.pieter@degoeje.nl> In-Reply-To: <200802191636.36444.pieter@degoeje.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_blkfree: freeing free block (7.0-RC1) 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, 19 Feb 2008 22:58:12 -0000 Pieter de Goeje wrote: > On Tuesday 19 February 2008, Miroslav Lachman wrote: > >>Pieter de Goeje wrote: >> >>>What revision of sys/vm/vm_object.c do you have? >> >>__FBSDID("$FreeBSD: src/sys/vm/vm_object.c,v 1.385.2.1 2007/10/19 >>05:48:45 alc Exp $"); >> > > > Hmm that's odd, some time ago I tracked this issue down to this commit, but > apparently there's still something wrong or the issue was fixed in another > commit in the same timeframe. > > >>System is FreeBSD 7.0-RC1 i386 installation. > > > Can you please try updating to the latest 7.0 (and/or 7-stable) to see if you > still can still reproduce this? > > I will try to reproduce this here. I can't try to reproduce it, because it is production machine and I have no other spare machine to play with. :( Maybe in next two weeks I will buy another machine and will have time to test it. Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 01:16:05 2008 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 59ED016A400 for ; Wed, 20 Feb 2008 01:16:05 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (unknown [IPv6:2001:388:f000::a25]) by mx1.freebsd.org (Postfix) with ESMTP id 17EE413C442 for ; Wed, 20 Feb 2008 01:16:05 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from localhost (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id 631C1172296; Wed, 20 Feb 2008 12:18:30 +1100 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by localhost (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id KMgFtqEqF+FN; Wed, 20 Feb 2008 12:18:27 +1100 (EST) Received: from [IPv6:2002:9665:9a11:1:21c:b3ff:febe:59cc] (unknown [IPv6:2002:9665:9a11:1:21c:b3ff:febe:59cc]) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTP id 3002217010C; Wed, 20 Feb 2008 12:18:27 +1100 (EST) Message-Id: <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> From: Sean To: Dominic Fandrey In-Reply-To: <47BB01BE.4010309@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 12:15:57 +1100 References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 01:16:05 -0000 From FreeBSD 5.5 (the earliest I can check readily) fstab(5) The fourth field, (fs_mntops), describes the mount options associated with the file system. It is formatted as a comma separated list of options. It contains at least the type of mount (see fs_type below) plus any additional options appropriate to the file system type. See the options flag (-o) in the mount(8) page and the file system specific page, such as mount_nfs(8), for additional options that may be specified. So the fs_type (rw, ro, etc.) has always been documented as obligatory, though in slightly less than obvious wording. On 20/02/2008, at 3:20 AM, Dominic Fandrey wrote: > Eygene Ryabinkin wrote: >> Dominic, good day. >> Tue, Feb 19, 2008 at 02:47:51PM +0100, Dominic Fandrey wrote: >>> My nfs mounts haven't been working by their fstab entries, ever >>> since I switched to RELENG_7. Today I took the time tracking the >>> issue down by adding lots of printf to mount.c. I tracked the >>> problem down to the function >>> fstabscan() in the file "/usr/src/lib/libc/gen/fstab.c". >>> >>> The result of my testing was that it is now obligatory to set >>> 'sw', 'ro' or 'rw' in the options list. >> Could you, please, show your /etc/fstab? I see that lib/libc/gen/ >> fstab.c >> was last changed 4 years ago (not counting revision 1.15, where the >> advertising license clause was removed), so perhaps fstabscan() is >> not guilty. >> Thank you! > > These 2 lines have been in use since 6.0 release: > > mobileKamikaze:/usr/src /usr/src nfs -b,-T,-R=5,noauto 0 0 > mobileKamikaze:/usr/obj /usr/obj nfs -b,-T,-R=5,noauto 0 0 > > They stopped working with the switch to RELENG_7. > > # mount /usr/src/ 0 /root > fstab: /etc/fstab:27: Inappropriate file type or format > fstab: /etc/fstab:28: Inappropriate file type or format > fstab: /etc/fstab:27: Inappropriate file type or format > fstab: /etc/fstab:28: Inappropriate file type or format > > mount: /usr/src: unknown special file or file system > > fstabscan() is the place where the "Inappropriate file type or > format" error is printed. The pointer char* cp either points to a > string "rw", "ro" or "sw". If none of these are present cp is a NULL- > pointer when the final check in line 207 is reached. So > error(EFTYPE) is called. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 07:37:10 2008 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 3F66016A400; Wed, 20 Feb 2008 07:37:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id E5B3A13C46A; Wed, 20 Feb 2008 07:36:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id B122028454; Wed, 20 Feb 2008 15:36:22 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 75ECCEC4224; Wed, 20 Feb 2008 15:36:22 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id PKZE85EwkG3v; Wed, 20 Feb 2008 15:36:16 +0800 (CST) Received: from charlie.delphij.net (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id CE533EB662B; Wed, 20 Feb 2008 15:36:07 +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:x-enigmail-version:openpgp:content-type; b=Z/aTHOBQkGOHWQgplsjRDtCaxct9R3V1OtctCUcfl4D+cLnaLDylw6HY/Q42IXCtU 97d5wULXFfxJIhTJIJ7xg== Message-ID: <47BBD864.3070905@delphij.net> Date: Tue, 19 Feb 2008 23:36:04 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, FreeBSD Current X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------080801040108060000080409" Cc: Subject: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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: Wed, 20 Feb 2008 07:37:10 -0000 This is a multi-part message in MIME format. --------------080801040108060000080409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here is a patch that will help fsck_ffs(8) to recover from certain types of damages which is caused by some catastrophic damage seen in some disk arrays that does not detect data errors in time. Change summary: fsutil.c: - Really update standard superblock. fsck_ffs -b used to update the backup superblock which does not recover file systems which have bad master superblocks. - Instead of coredump, zero out whole cg if its signature is bad. inode.c: - Instead of coredump, zero out whole cg if its signature is bad. pass1.c: - If cg gives insane initediblk, use a fallback one which will not cause allocation failure. setup.c: - Really sanity check the superblock's fs_sbsize. With these changes, fsck_ffs will be able to check file systems with heavily damaged cylinder group information, and have a better chance surviving. Comments? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHu9hji+vbBBjt66ARAqSyAJ49q4uEIANxr4/ccaVKeLTDomiFVQCfVB0i kLZsrSPTifwvItwC3WMq40E= =vvkQ -----END PGP SIGNATURE----- --------------080801040108060000080409 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsck.diff" Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 20 Feb 2008 07:15:56 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } @@ -441,8 +441,13 @@ allocblk(long frags) } cg = dtog(&sblock, i + j); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + } baseblk = dtogd(&sblock, i + j); for (k = 0; k < frags; k++) { setbmap(i + j + k); Index: inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.38 diff -u -p -r1.38 inode.c --- inode.c 31 Oct 2006 22:06:56 -0000 1.38 +++ inode.c 20 Feb 2008 07:15:22 -0000 @@ -617,8 +617,13 @@ allocino(ino_t request, int type) return (0); cg = ino_to_cg(&sblock, ino); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + } setbit(cg_inosused(cgp), ino % sblock.fs_ipg); cgp->cg_cs.cs_nifree--; switch (type & IFMT) { Index: pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.43 diff -u -p -r1.43 pass1.c --- pass1.c 8 Oct 2004 20:44:47 -0000 1.43 +++ pass1.c 20 Feb 2008 07:13:53 -0000 @@ -93,9 +93,11 @@ pass1(void) inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); - if (sblock.fs_magic == FS_UFS2_MAGIC) + if (sblock.fs_magic == FS_UFS2_MAGIC) { inosused = cgrp.cg_initediblk; - else + if (inosused > sblock.fs_ipg) + inosused = sblock.fs_ipg; + } else inosused = sblock.fs_ipg; if (got_siginfo) { printf("%s: phase 1: cyl group %d of %d (%d%%)\n", Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.50 diff -u -p -r1.50 setup.c --- setup.c 31 Oct 2006 22:06:56 -0000 1.50 +++ setup.c 20 Feb 2008 07:13:27 -0000 @@ -349,7 +349,7 @@ readsb(int listerr) sblock.fs_sblockloc == sblock_try[i])) && sblock.fs_ncg >= 1 && sblock.fs_bsize >= MINBSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_sbsize >= roundup(sizeof(struct fs), dev_bsize)) break; } if (sblock_try[i] == -1) { --------------080801040108060000080409-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 07:40:28 2008 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 3727416A402 for ; Wed, 20 Feb 2008 07:40:28 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 026EF13C455 for ; Wed, 20 Feb 2008 07:40:27 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id EAEE12C2C71; Wed, 20 Feb 2008 01:23:18 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nBA1mq1rye4o; Wed, 20 Feb 2008 01:23:18 -0600 (CST) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 23B1B2C2C5F; Wed, 20 Feb 2008 01:23:18 -0600 (CST) Message-ID: <47BBD565.9040705@cs.rice.edu> Date: Wed, 20 Feb 2008 01:23:17 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070805 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kostik Belousov References: <20080219132455.GD57756@deviant.kiev.zoral.com.ua> In-Reply-To: <20080219132455.GD57756@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Michiel Boland , freebsd-current@freebsd.org Subject: Re: panic upon starting X in recent -CURRENTs (intel driver) 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, 20 Feb 2008 07:40:28 -0000 Kostik Belousov wrote: >What happen there is that munmap() do the split for the /dev/mem mapping. >This caused the OBJT_DEVICE ref_count to be bumped, and vm_map_entry_delete() >called vm_object_page_remove(). The later called pmap_remove_all() >unconditionally. > >pmap_remove_all has the KASSERT that fails exactly when supplied >fictitious page. It becomes KASSERT in the rev. 1.106 of i386/pmap.c, >committed 2008/01/08, it was under the PMAP_DIAGNOSTIC before. > >Since such page has md.pv_list empty anyway, this KASSERT seems to be >only the statement of intent. The change below would prevent the panic >by not calling pmap_remove_all from vm_object_page_remove for such pages. > > > In fact, md.pv_list is never initialized for fictitious pages. So, the invocation of pmap_remove_all() has only worked 'til now because the underlying memory is zeroed. >Alan, do you have objections ? [Alternative seems to be a removal of the >assertions from all pmap implementations, that also weaken the invariants >for other callers that do skip fictitious pages]. > > I want to think this over. I'll e-mail you this weekend. >diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >index 21c0ac6..21ee10d 100644 >--- a/sys/vm/vm_object.c >+++ b/sys/vm/vm_object.c >@@ -1884,7 +1884,8 @@ again: > */ > if ((wirings = p->wire_count) != 0 && > (wirings = pmap_page_wired_mappings(p)) != p->wire_count) { >- pmap_remove_all(p); >+ if ((p->flags & PG_FICTITIOUS) == 0) >+ pmap_remove_all(p); > /* Account for removal of managed, wired mappings. */ > p->wire_count -= wirings; > if (!clean_only) >@@ -1898,7 +1899,8 @@ again: > if (p->valid & p->dirty) > continue; > } >- pmap_remove_all(p); >+ if ((p->flags & PG_FICTITIOUS) == 0) >+ pmap_remove_all(p); > /* Account for removal of managed, wired mappings. */ > if (wirings != 0) > p->wire_count -= wirings; > > From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 07:53:09 2008 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 4CB5A16A406 for ; Wed, 20 Feb 2008 07:53:09 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id EBFB713C465 for ; Wed, 20 Feb 2008 07:53:08 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id 47D7EBFEC9E; Wed, 20 Feb 2008 07:53:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id MyLZCGM1uWng; Wed, 20 Feb 2008 07:52:58 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 7976CBFE830; Wed, 20 Feb 2008 07:52:58 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1K7qwSb058492; Wed, 20 Feb 2008 08:52:58 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1K7qvvB058489; Wed, 20 Feb 2008 08:52:57 +0100 (CET) (envelope-from rink) Date: Wed, 20 Feb 2008 08:52:57 +0100 From: Rink Springer To: d@delphij.net Message-ID: <20080220075257.GE43512@rink.nu> References: <47BBD864.3070905@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BBD864.3070905@delphij.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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, 20 Feb 2008 07:53:09 -0000 Hi Xin, On Tue, Feb 19, 2008 at 11:36:04PM -0800, Xin LI wrote: > Comments? This looks fine to me - I don't see anything obviously wrong in there. -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 08:11:45 2008 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 788BB16A401 for ; Wed, 20 Feb 2008 08:11:45 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3392313C43E for ; Wed, 20 Feb 2008 08:11:44 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRk3J-0003ak-W6 for freebsd-current@freebsd.org; Wed, 20 Feb 2008 08:11:42 +0000 Received: from dhcp100.ifado.de ([195.253.22.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2008 08:11:41 +0000 Received: from wb by dhcp100.ifado.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2008 08:11:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wilhelm B. Kloke" Date: Wed, 20 Feb 2008 08:11:34 +0000 (UTC) Organization: InstArbPhysUniDo Lines: 23 Message-ID: References: <47BADE07.9020402@gmx.de> <20080219180227.GC73371@dracon.ht-systems.ru> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp100.ifado.de User-Agent: slrn/0.9.8.1 (FreeBSD) Cache-Post-Path: vestein.arb-phys.uni-dortmund.de!unknown@localhost X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Sender: news Subject: mount order, Was: nfs mounts don't work through fstab 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, 20 Feb 2008 08:11:45 -0000 Stanislav Sedov schrieb: >> > >> I have a problem which is possibly related to this one. My FreeBSD7-amd64 >> system fails to boot, because the network device nfe0 cannot be >> configured by dhclient. Dhclient refuses to work because / is not >> yet writeable. So I have to mount_-u_-o_r_/ manually, start >> dhclient_nfe0 again, and quit single-user mode to get the >> system booted. >> > > Do you mount your / via nfs? No. The nfs mounts are not needed early. My idea about the problem was wrong, anyway. In my fstab there are nullfs mounts which depend on the nfs mounts. I did not find a way to delay these mounts. Giving them a higher mount pass number does not seem to work. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:50:35 2008 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 1D44216A402; Wed, 20 Feb 2008 09:50:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id C9AFA13C4D5; Wed, 20 Feb 2008 09:50:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1K9oX4v099758; Wed, 20 Feb 2008 04:50:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1K9oXtm070028; Wed, 20 Feb 2008 04:50:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 410F973039; Wed, 20 Feb 2008 04:50:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080220095033.410F973039@freebsd-current.sentex.ca> Date: Wed, 20 Feb 2008 04:50:33 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Wed, 20 Feb 2008 09:50:35 -0000 TB --- 2008-02-20 08:44:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-20 08:44:57 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-20 08:44:57 - cleaning the object tree TB --- 2008-02-20 08:45:31 - cvsupping the source tree TB --- 2008-02-20 08:45:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-20 08:45:37 - building world (CFLAGS=-O -pipe) TB --- 2008-02-20 08:45:37 - cd /src TB --- 2008-02-20 08:45:37 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 20 08:45:39 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 20 09:47:16 UTC 2008 TB --- 2008-02-20 09:47:16 - generating LINT kernel config TB --- 2008-02-20 09:47:16 - cd /src/sys/i386/conf TB --- 2008-02-20 09:47:16 - /usr/bin/make -B LINT TB --- 2008-02-20 09:47:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-20 09:47:16 - cd /src TB --- 2008-02-20 09:47:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 20 09:47:16 UTC 2008 >>> 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 [...] @ -> /src/sys machine -> /src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/src/sys/LINT /src/sys/modules/geom/geom_label/../../../geom/label/g_label.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ext2fs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_iso9660.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_msdosfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ntfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_reiserfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ufs.c ===> geom/geom_lvm (depend) @ -> /src/sys machine -> /src/sys/i386/include make: don't know how to make g_lvm.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-20 09:50:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-20 09:50:33 - ERROR: failed to build lint kernel TB --- 2008-02-20 09:50:33 - tinderbox aborted TB --- 2896.74 user 348.19 system 3935.86 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:56:29 2008 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 818DD16A400; Wed, 20 Feb 2008 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 3C22613C457; Wed, 20 Feb 2008 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55516.dip.t-dialin.net [84.165.85.22]) by redbull.bpaserver.net (Postfix) with ESMTP id 6024C2E068; Wed, 20 Feb 2008 10:56:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5371693C31; Wed, 20 Feb 2008 10:56:15 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m1K9uECI010729; Wed, 20 Feb 2008 10:56:14 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 20 Feb 2008 10:56:14 +0100 Message-ID: <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 20 Feb 2008 10:56:14 +0100 From: Alexander Leidinger To: d@delphij.net, Xin LI References: <47BBD864.3070905@delphij.net> In-Reply-To: <47BBD864.3070905@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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, 20 Feb 2008 09:56:29 -0000 Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 -0800): > Change summary: > > fsutil.c: > - Really update standard superblock. fsck_ffs -b used to update the > backup superblock which does not recover file systems which have bad > master superblocks. > - Instead of coredump, zero out whole cg if its signature is bad. > > inode.c: > - Instead of coredump, zero out whole cg if its signature is bad. Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask for confirmation? Bye, Alexander. -- I've been there. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:58:52 2008 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 612D516A403; Wed, 20 Feb 2008 09:58:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 349A413C45B; Wed, 20 Feb 2008 09:58:49 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 41DA32844D; Wed, 20 Feb 2008 17:58:48 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 0D253EC42E5; Wed, 20 Feb 2008 17:58:48 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id JDI7nKmHAiIP; Wed, 20 Feb 2008 17:58:43 +0800 (CST) Received: from charlie.delphij.net (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 55B9CEB0B5A; Wed, 20 Feb 2008 17:58:39 +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:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=hd0if4plfnipRsEqHEt3uSD1l2qoI0K8ALfwIavRtc3CmaeySeO30Uapp+2zmDKh8 VK82Ls8x8t2TRT6EorDHg== Message-ID: <47BBF9CC.4030404@delphij.net> Date: Wed, 20 Feb 2008 01:58:36 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: Alexander Leidinger References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> In-Reply-To: <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD Current , d@delphij.net Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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: Wed, 20 Feb 2008 09:58:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Leidinger wrote: > Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 > -0800): > >> Change summary: >> >> fsutil.c: >> - Really update standard superblock. fsck_ffs -b used to update the >> backup superblock which does not recover file systems which have bad >> master superblocks. >> - Instead of coredump, zero out whole cg if its signature is bad. >> >> inode.c: >> - Instead of coredump, zero out whole cg if its signature is bad. > > Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask > for confirmation? My assumption is that if a cylinder group's magic number is damaged, then the whole stuff can not be trusted at all, but yes, I think this should come with a prompt, will add tomorrow. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHu/nMi+vbBBjt66ARAqN9AJ4zRi6+h0f6R062vQyuEkET32saEACguKSs 4GxuVJdwFt7bIuKlGouO5Dk= =fMnQ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 10:51:24 2008 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 BC99316A402; Wed, 20 Feb 2008 10:51:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8EAA713C4E7; Wed, 20 Feb 2008 10:51:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KApNrN002075; Wed, 20 Feb 2008 05:51:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KApNg5022783; Wed, 20 Feb 2008 05:51:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 579E273039; Wed, 20 Feb 2008 05:51:23 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080220105123.579E273039@freebsd-current.sentex.ca> Date: Wed, 20 Feb 2008 05:51:23 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean 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: Wed, 20 Feb 2008 10:51:24 -0000 TB --- 2008-02-20 09:47:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-20 09:47:16 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-02-20 09:47:16 - cleaning the object tree TB --- 2008-02-20 09:47:45 - cvsupping the source tree TB --- 2008-02-20 09:47:45 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-02-20 09:47:52 - building world (CFLAGS=-O -pipe) TB --- 2008-02-20 09:47:52 - cd /src TB --- 2008-02-20 09:47:52 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 20 09:47:54 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 20 10:48:46 UTC 2008 TB --- 2008-02-20 10:48:46 - generating LINT kernel config TB --- 2008-02-20 10:48:46 - cd /src/sys/pc98/conf TB --- 2008-02-20 10:48:46 - /usr/bin/make -B LINT TB --- 2008-02-20 10:48:46 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-20 10:48:46 - cd /src TB --- 2008-02-20 10:48:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 20 10:48:46 UTC 2008 >>> 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 [...] i386 -> /src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -DPC98 -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/pc98/src/sys/LINT /src/sys/modules/geom/geom_label/../../../geom/label/g_label.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ext2fs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_iso9660.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_msdosfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ntfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_reiserfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ufs.c ===> geom/geom_lvm (depend) @ -> /src/sys machine -> /src/sys/pc98/include i386 -> /src/sys/i386/include make: don't know how to make g_lvm.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-20 10:51:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-20 10:51:23 - ERROR: failed to build lint kernel TB --- 2008-02-20 10:51:23 - tinderbox aborted TB --- 2859.32 user 352.86 system 3846.43 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:02:06 2008 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 73EBB16A40F for ; Wed, 20 Feb 2008 11:02:06 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id C6D5813C4FF for ; Wed, 20 Feb 2008 11:02:05 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so2865002fka.11 for ; Wed, 20 Feb 2008 03:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Qn4ZybDSOSNXwp3u5eesURAxCVMiNoACikIAsBVIFUI=; b=FnE6vxeiykL/qT3t+bqHMCYiIlIY0IxeTRqj8iAztY2nvWsAjnuDbuPugxvJ188lDUTSqRYbSRnwvKsS1moBVPVRIZ7mq25Vo6WqL0QfW2zBxdqJ2MW5K/d2IFgwzZGZfPUmqbmKnbFb2N2WWA3WwoR4z7f4rMPJlfE5NorkBWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lwCbUYjcJJl2p3UFzxIqyKeR9h/KnaVAcfYs2uuOBZT8/WgJHJk18SoZvAsIPGuoMnkpxaFsresqza/Tze59g1gbJfFWCS2c7uI3LwEDK2DwAwz+7QD5nKi4EbQYXrRT3dXOiFQp34Fgx0QdHBvjUZ90410dy6h5uOGreas2+pA= Received: by 10.78.97.7 with SMTP id u7mr13096400hub.50.1203505324317; Wed, 20 Feb 2008 03:02:04 -0800 (PST) Received: by 10.78.16.10 with HTTP; Wed, 20 Feb 2008 03:02:04 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 14:02:04 +0300 From: pluknet To: "haro@kgt.co.jp" In-Reply-To: <20080217.131600.57967065.haro@kgt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080217.131600.57967065.haro@kgt.co.jp> Cc: freebsd-current@freebsd.org Subject: Re: 7 LOR with resent -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, 20 Feb 2008 11:02:06 -0000 Hello, On 17/02/2008, haro@kgt.co.jp wrote: > Hi all, > > As I've seen few reports regarding new LORs with resent -current, > I checked my notebook and found 7 LOR in one session. ;-) Same here :) though it somewhat different. > Some are old well known, but mostly are fairly new. > This is from -current of few days old. > > Regards, > Haro > [7 haro's LORs snipped] 7 LORs with new two (these are ffs_snapshot related). I got all of them while booting except "ffs_snapshot". These two after I ran kgdb with kernel dump (see another mail). Included with dmesg to show LORs in order they appear: Copyright (c) 1992-2008 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 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008 root@pl.h3:/var/obj/usr/src/sys/MYKERNEL WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193364 Hz quality 0 CPU: AMD Athlon(tm) XP (1152.80-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480800 real memory = 536805376 (511 MB) avail memory = 516317184 (492 MB) mptable_probe: MP Config Table has bad signature: ACPI APIC Table: ioapic0 irqs 0-23 on motherboard ichwd module loaded kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: on hostb0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xe2003000-0xe2003fff irq 20 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe2004000-0xe2004fff irq 21 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe2000000-0xe20000ff irq 22 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered nfe0: port 0xe000-0xe007 mem 0xe2001000-0xe2001fff irq 20 at device 4.0 on pci0 miibus0: on nfe0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nfe0: Ethernet address: 00:04:61:6c:76:b1 nfe0: [FILTER] pcib1: at device 8.0 on pci0 pci1: on pcib1 pcm0: port 0xd000-0xd01f,0xd400-0xd47f irq 16 at device 8.0 on pci1 pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x3632 XIN2 Clock Source: 49.152MHz(192kHz*256) MPU-401 UART(s) #: 1 ADC #: 1 and SPDIF receiver connected DAC #: 1 Multi-track converter type: I2S(with volume, 192KHz support, 24bit resolution, ID#0x0) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0x45/0x7fffba/0x4000b5 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcib2: at device 30.0 on pci0 pci2: on pcib2 vgapci0: mem 0xe0000000-0xe0ffffff,0xd8000000-0xdfffffff irq 19 at device 0.0 on pci2 acpi_tz0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] Timecounter "TSC" frequency 1152797874 Hz quality 800 Timecounters tick every 1.000 msec ad0: 38146MB at ata0-master UDMA100 acd0: DVDR at ata1-slave UDMA66 WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad0s2 is ntfs/Local Disk. lock order reversal: 1st 0xc2aa5e28 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2061 2nd 0xc2b7f9d4 devfsmount (devfsmount) @ /usr/src/sys/fs/devfs/devfs_vnops.c:201 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d3ac6bbc,c0570e56,c0767dd3,c2b7f9d4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dd3,c2b7f9d4,c075975e,c075975e,c075979f,...) at kdb_backtrace+0x29 witness_checkorder(c2b7f9d4,9,c075979f,c9,c7,...) at witness_checkorder+0x6d6 _sx_xlock(c2b7f9d4,0,c075979f,c9,c2b7f9d4,...) at _sx_xlock+0x7d devfs_allocv(c2b94900,c2bbb000,d3ac6c28,c28eccc0,c076db66,...) at devfs_allocv+0x142 devfs_root(c2bbb000,2,c0831af8,c28eccc0,ca,...) at devfs_root+0x51 set_rootvnode(c0831ae0,0,c076db66,5ed,c05ae090,...) at set_rootvnode+0x2b vfs_mountroot(c07e6410,4,c075d9f4,260,0,...) at vfs_mountroot+0x356 start_init(0,d3ac6d38,c075f34d,30c,c28e9ab0,...) at start_init+0x65 fork_exit(c0501d90,0,d3ac6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd3ac6d70, ebp = 0 --- Trying to mount root from ufs:/dev/ad0s4a WARNING: / was not properly dismounted lock order reversal: 1st 0xc2aa59e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2061 2nd 0xc2bbb000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d3ac69e4,c0570e56,c0767dd3,c2bbb000,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dd3,c2bbb000,c076dc64,c076dc64,c076e201,...) at kdb_backtrace+0x29 witness_checkorder(c2bbb000,1,c076e201,16c,d3ac6a24,...) at witness_checkorder+0x6d6 _lockmgr(c2bbb000,2001,c2bbb030,c076e201,16c,...) at _lockmgr+0x1e5 vfs_busy(c2bbb000,0,0,c28eccc0,d3ac6b58,...) at vfs_busy+0x198 lookup(d3ac6b44,c076d914,c6,bf,c28cea2c,...) at lookup+0x7d4 namei(d3ac6b44,c28ecd54,c07a7a84,c076db66,c2bbb030,...) at namei+0x348 kern_unlink(c28eccc0,c076dfa3,1,628,0,...) at kern_unlink+0x40 vfs_mountroot_try(c076e15d,c075c95a,c0757abf,1,c05ae090,...) at vfs_mountroot_try+0x470 vfs_mountroot(c07e6410,4,c075d9f4,260,0,...) at vfs_mountroot+0x412 start_init(0,d3ac6d38,c075f34d,30c,c28e9ab0,...) at start_init+0x65 fork_exit(c0501d90,0,d3ac6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xd3ac6d70, ebp = 0 --- lock order reversal: 1st 0xc28f3044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3111 2nd 0xc2aa57c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2061 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d3ac69cc,c0570e56,c0767dd3,c2aa57c8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dd3,c2aa57c8,c075d212,c075d212,c076e201,...) at kdb_backtrace+0x29 witness_checkorder(c2aa57c8,1,c076e201,80d,d3ac6a00,...) at witness_checkorder+0x6d6 _lockmgr(c2aa57c8,3041,c2aa57f8,c076e201,80d,...) at _lockmgr+0x1e5 ffs_lock(d3ac6a74,c052b154,c07eb374,3041,3041,...) at ffs_lock+0x8a VOP_LOCK1_APV(c07bf4c0,d3ac6a74,c075c958,3,c2aa57f8,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2aa5770,3041,c076e201,80d,0,...) at _vn_lock+0xe8 vget(c2aa5770,3041,c28eccc0,4a9,c1045580,...) at vget+0x109 vnode_pager_lock(c1045400,0,c077e10a,127,d3ac6be8,...) at vnode_pager_lock+0x1ad vm_fault(c28f3000,80d2000,2,8,80d2a60,...) at vm_fault+0x1df trap_pfault(5,0,c0789a42,2c8,c,...) at trap_pfault+0xf8 trap(d3ac6d38) at trap+0x258 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfef10, ebp = 0xbfbfef30 --- acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 0x00 0x01 cd0 at ata1 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. WARNING: /usr was not properly dismounted lock order reversal: 1st 0xc2c28d18 tmpfs (tmpfs) @ /usr/src/sys/kern/vfs_subr.c:2061 2nd 0xc2bba7d4 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d5fc4a24,c0570e56,c0767dd3,c2bba7d4,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dd3,c2bba7d4,c076dc64,c076dc64,c076e201,...) at kdb_backtrace+0x29 witness_checkorder(c2bba7d4,1,c076e201,16c,d5fc4a64,...) at witness_checkorder+0x6d6 _lockmgr(c2bba7d4,2001,c2bba804,c076e201,16c,...) at _lockmgr+0x1e5 vfs_busy(c2bba7d4,10,0,c2b7d880,8,...) at vfs_busy+0x198 vfs_donmount(810e080,c,d5fc4c70,c2e8eb80,810b6a0,...) at vfs_donmount+0xdd7 nmount(c2b7d880,d5fc4cfc,c,c0768aa5,c07a3890,...) at nmount+0xb1 syscall(d5fc4d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280dfd53, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- lock order reversal: 1st 0xc2c29388 msdosfs (msdosfs) @ /usr/src/sys/kern/vfs_subr.c:2061 2nd 0xc2bba29c vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:364 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d5fc4a24,c0570e56,c0767dd3,c2bba29c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dd3,c2bba29c,c076dc64,c076dc64,c076e201,...) at kdb_backtrace+0x29 witness_checkorder(c2bba29c,1,c076e201,16c,d5fc4a64,...) at witness_checkorder+0x6d6 _lockmgr(c2bba29c,2001,c2bba2cc,c076e201,16c,...) at _lockmgr+0x1e5 vfs_busy(c2bba29c,10,0,c2b7d880,8,...) at vfs_busy+0x198 vfs_donmount(810e080,c,d5fc4c70,c2e8e180,810ba50,...) at vfs_donmount+0xdd7 nmount(c2b7d880,d5fc4cfc,c,c0768aa5,c07a3890,...) at nmount+0xb1 syscall(d5fc4d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280dfd53, esp = 0xbfbfe97c, ebp = 0xbfbfedd8 --- lock order reversal: 1st 0xc2f0d498 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:416 2nd 0xcced5884 getblk (bufwait) @ /usr/src/sys/sys/buf.h:301 3rd 0xc2c28af8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:537 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d60115b0,c0570e56,c0767dec,c2c28af8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dec,c2c28af8,c075d212,c075d212,c077a89f,...) at kdb_backtrace+0x29 witness_checkorder(c2c28af8,9,c077a89f,219,d60115e4,...) at witness_checkorder+0x6d6 _lockmgr(c2c28af8,2002,c2c28b28,c077a89f,219,...) at _lockmgr+0x4fd ffs_lock(d6011658,d6011650,c057063c,2002,c2c28aa0,...) at ffs_lock+0x8a VOP_LOCK1_APV(c07bf4c0,d6011658,205,c077a89f,c2c28b28,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c2c28aa0,2002,c077a89f,219,c28cd800,...) at _vn_lock+0xe8 ffs_snapshot(c2bba538,c2a81420,c077c162,14f,c077d8d9,...) at ffs_snapshot+0x14dc ffs_mount(c2bba538,c2f16880,c076db66,3e9,d6011bd4,...) at ffs_mount+0x1561 vfs_donmount(810a040,8,d6011c70,c2f01980,1211000,...) at vfs_donmount+0x13a9 nmount(c2f16880,d6011cfc,c,d6011d38,c07a3890,...) at nmount+0xb1 syscall(d6011d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e2d53, esp = 0xbfbfeb3c, ebp = 0xbfbfee98 --- lock order reversal: 1st 0xc2f01694 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:290 2nd 0xc2f0d498 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1594 KDB: stack backtrace: db_trace_self_wrapper(c0765ade,d6011988,c0570e56,c0767dd3,c2f0d498,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0767dd3,c2f0d498,c075d212,c075d212,c077a89f,...) at kdb_backtrace+0x29 witness_checkorder(c2f0d498,9,c077a89f,63a,c077a89f,...) at witness_checkorder+0x6d6 _lockmgr(c2f0d498,2,0,c077a89f,63a,...) at _lockmgr+0x4fd ffs_snapremove(c2f0d440,c2bba568,0,c076eefa,434,...) at ffs_snapremove+0x113 softdep_releasefile(c2f13c60,d6011ab0,2,c2f16914,c07a7a84,...) at softdep_releasefile+0x3b ufs_inactive(d6011af0,c2f0d4c8,c2f0d440,c2f0d4c8,d6011b08,...) at ufs_inactive+0x1ca VOP_INACTIVE_APV(c07bf4c0,d6011af0,c076e201,8fd,c07cf4e0,...) at VOP_INACTIVE_APV+0xa5 vinactive(c07bf4c0,d6011b24,c076e201,889,129,...) at vinactive+0x91 vput(c2f0d440,d6011b5c,c076eefa,122,c07cf260,...) at vput+0x1e2 vn_close(c2f0d440,1,c28ce900,c2f16880,c07e6e34,...) at vn_close+0xec vn_closefile(c2bc971c,c2f16880,6db,0,c2bc971c,...) at vn_closefile+0xe9 _fdrop(c2bc971c,c2f16880,c0570727,c08312f8,0,...) at _fdrop+0x43 closef(c2bc971c,c2f16880,419,3fe,c2bc971c,...) at closef+0x276 kern_close(c2f16880,4,d6011d2c,c0727903,c2f16880,...) at kern_close+0x11c close(c2f16880,d6011cfc,4,c0768aa5,c07a15b0,...) at close+0x1a syscall(d6011d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x28177ddb, esp = 0xbfbfeb3c, ebp = 0xbfbfee98 --- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:02:46 2008 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 6EDE216A409; Wed, 20 Feb 2008 11:02:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 27E7213C508; Wed, 20 Feb 2008 11:02:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KB2jsV002536; Wed, 20 Feb 2008 06:02:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KB2jTe029175; Wed, 20 Feb 2008 06:02:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4FAF973039; Wed, 20 Feb 2008 06:02:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080220110245.4FAF973039@freebsd-current.sentex.ca> Date: Wed, 20 Feb 2008 06:02:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner4 X-Virus-Status: Clean 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: Wed, 20 Feb 2008 11:02:46 -0000 TB --- 2008-02-20 09:50:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-20 09:50:33 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-20 09:50:33 - cleaning the object tree TB --- 2008-02-20 09:51:05 - cvsupping the source tree TB --- 2008-02-20 09:51:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-20 09:51:14 - building world (CFLAGS=-O -pipe) TB --- 2008-02-20 09:51:14 - cd /src TB --- 2008-02-20 09:51:14 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 20 09:51:15 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 20 11:00:28 UTC 2008 TB --- 2008-02-20 11:00:28 - generating LINT kernel config TB --- 2008-02-20 11:00:28 - cd /src/sys/ia64/conf TB --- 2008-02-20 11:00:28 - /usr/bin/make -B LINT TB --- 2008-02-20 11:00:28 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-20 11:00:28 - cd /src TB --- 2008-02-20 11:00:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 20 11:00:28 UTC 2008 >>> 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 [...] @ -> /src/sys machine -> /src/sys/ia64/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/ia64/src/sys/LINT /src/sys/modules/geom/geom_label/../../../geom/label/g_label.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ext2fs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_iso9660.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_msdosfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ntfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_reiserfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ufs.c ===> geom/geom_lvm (depend) @ -> /src/sys machine -> /src/sys/ia64/include make: don't know how to make g_lvm.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-20 11:02:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-20 11:02:45 - ERROR: failed to build lint kernel TB --- 2008-02-20 11:02:45 - tinderbox aborted TB --- 3297.27 user 349.77 system 4331.96 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:27:54 2008 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 7C36316A40D for ; Wed, 20 Feb 2008 11:27:54 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57008.mail.re3.yahoo.com (web57008.mail.re3.yahoo.com [66.196.97.112]) by mx1.freebsd.org (Postfix) with SMTP id 16D6313C465 for ; Wed, 20 Feb 2008 11:27:53 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 39629 invoked by uid 60001); 20 Feb 2008 11:27:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ooJUIVxXgnCubZTQZmlwzTT9eqtBiy2kHwai86vP+L64UxL1QZYOzsgNMv73RnLZbhfyOwfZ4fuNTNF2TASfGIwI54urQJmLokpmAYY2f9jO0fnGntjyRD+vts4A7kZ/VBI2mAXuovCCDarG5MbvwzYXoH9bltlnfCsZ/M4ugug=; X-YMail-OSG: E.1uJ8wVM1maEt27STqzXaqN1OzFKNAjq6fcTIToCaF37N01KPYIJIA0kt5fXuclSIxBeP5PjZZX.1FNctGCQZjPS4QmfAQ3jfJ3XdOK36BD0KlRF4.G1qsX0O840cMEDFjl04T3aI4d54w- Received: from [165.21.155.93] by web57008.mail.re3.yahoo.com via HTTP; Wed, 20 Feb 2008 03:27:53 PST Date: Wed, 20 Feb 2008 03:27:53 -0800 (PST) From: Unga To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <235549.36535.qm@web57008.mail.re3.yahoo.com> Subject: Frequent network access freeze (in 7.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, 20 Feb 2008 11:27:54 -0000 Hi all I'm running 7.0-PRERELEASE (RC2, dated 15/02/2008), compiled from sources on i386 machine (512MB RAM, 3.0GHz, tx0: ). Network access freezes very frequently. Cannot ping to any ip address. The only way to get networking working again is reboot. I'm having this problem on 7.0 ever since I tried it from BETA4. I have reported also to this list before but sadly nobody was interested on it. If somebody is interested to look into this problem, I could furnish with more detail and participate in testing. Thank you. Best regards Unga ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:29:01 2008 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 CED0416A406 for ; Wed, 20 Feb 2008 11:29:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 6085913C469 for ; Wed, 20 Feb 2008 11:29:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2095075fgg.35 for ; Wed, 20 Feb 2008 03:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=jLdSbZZwaBL+edYGKCo4d6j2CpYoq+tdmYCP8pWlKbc=; b=Hs4/HkhfYXG5T/rYb09M6TWMrbylCewOuB1MV3yHJ0dSfM2d/Jnea8OhddO20KCfbEgScAUV3gaeeCbLUW+h4bTeZJa6VJ5kVTITbAMK2De9as/StMLUoReW9DLAKrn8KCQI5DagnH3/y2aHeeBY1UE6ltSgAi2kT+uctfyhLWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=uroRdSMfBNvHAic9ducr+flYWVstWEUj4xjpgiBHckPIkF/N786koCYGDVdv1j/4B8qyeEJvhjEdm35Fu3+Dt5+kt7IRVtVuEQV3tJvnuvwy2WPPm5BROFLKWUmJrcbybz6AivtkYmufp/Bevz8K+agCgEEgY9zRwrcpfV91Z+Q= Received: by 10.78.97.7 with SMTP id u7mr13147161hub.50.1203506939384; Wed, 20 Feb 2008 03:28:59 -0800 (PST) Received: by 10.78.16.10 with HTTP; Wed, 20 Feb 2008 03:28:59 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 14:28:59 +0300 From: pluknet To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: panic: mutex Giant owned at nfs_syscalls.c:556 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, 20 Feb 2008 11:29:01 -0000 I got this assertion while attempting to remove file on nfs mounted ffs filesystem. NFS client on 7.0-PRERELEASE and NFS server on 8-CURRENT. FreeBSD 7.0-PRERELEASE #1: Wed Feb 6 18:09:18 MSK 2008 FreeBSD 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008 Unread portion of the kernel message buffer: panic: mutex Giant owned at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 KDB: enter: panic exclusive sleep mutex nfsd_mtx r = 0 (0xc41d1660) locked @ /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501 exclusive sleep mutex Giant r = 0 (0xc07e6410) locked @ /usr/src/sys/kern/vfs_lookup.c:663 ... #9 0xc053959d in panic (fmt=0xc076181d "mutex %s owned at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:555 #10 0xc052adf7 in _mtx_assert (m=0xc07e6410, what=0, file=0xc41cb7b2 "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c", line=556) at /usr/src/sys/kern/kern_mutex.c:652 #11 0xc41c9e82 in nfssvc (td=0xc2e68000, uap=0xd600dcfc) at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 #12 0xc0727903 in syscall (frame=0xd600dd38) at /usr/src/sys/i386/i386/trap.c:1034 #13 0xc0711630 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203 ---Type to continue, or q to quit--- #14 0x00000033 in ?? () Looks somewhat strange because nfs_syscalls.c:556 is not in nfssvc(), it's in nfssvc_nfsd(). Kernel and world synchronized on 8-CUR though. wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:33:02 2008 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 4802616A40A for ; Wed, 20 Feb 2008 11:33:02 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 0614B13C4EF for ; Wed, 20 Feb 2008 11:33:01 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id CB8CC405486; Wed, 20 Feb 2008 12:33:00 +0100 (CET) Message-ID: <47BC0FEC.2050409@bsdforen.de> Date: Wed, 20 Feb 2008 12:33:00 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Unga References: <235549.36535.qm@web57008.mail.re3.yahoo.com> In-Reply-To: <235549.36535.qm@web57008.mail.re3.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Frequent network access freeze (in 7.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, 20 Feb 2008 11:33:02 -0000 Unga wrote: > Hi all > > I'm running 7.0-PRERELEASE (RC2, dated 15/02/2008), > compiled from sources on i386 machine (512MB RAM, > 3.0GHz, tx0: ). > > Network access freezes very frequently. Cannot ping to > any ip address. The only way to get networking working > again is reboot. > > I'm having this problem on 7.0 ever since I tried it > from BETA4. I have reported also to this list before > but sadly nobody was interested on it. > > If somebody is interested to look into this problem, I > could furnish with more detail and participate in > testing. > > Thank you. > > Best regards > Unga Show us the output of the commands "ifconfig" and "netstat -r" while your network works and after it stopped working. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:35:35 2008 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 3B5D116A40E for ; Wed, 20 Feb 2008 11:35:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE7B13C4EF for ; Wed, 20 Feb 2008 11:35:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 871A846B06; Wed, 20 Feb 2008 06:35:34 -0500 (EST) Date: Wed, 20 Feb 2008 11:35:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Unga In-Reply-To: <235549.36535.qm@web57008.mail.re3.yahoo.com> Message-ID: <20080220112911.W44565@fledge.watson.org> References: <235549.36535.qm@web57008.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mux@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: Frequent network access freeze (in 7.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, 20 Feb 2008 11:35:35 -0000 On Wed, 20 Feb 2008, Unga wrote: > I'm running 7.0-PRERELEASE (RC2, dated 15/02/2008), compiled from sources on > i386 machine (512MB RAM, 3.0GHz, tx0: ). > > Network access freezes very frequently. Cannot ping to any ip address. The > only way to get networking working again is reboot. > > I'm having this problem on 7.0 ever since I tried it from BETA4. I have > reported also to this list before but sadly nobody was interested on it. > > If somebody is interested to look into this problem, I could furnish with > more detail and participate in testing. This sort of problem frequently turns out to be a bug in a device driver or a problem with interrupt probing/configuration, so my first guess would be a problem with the if_tx driver. The usual starting diagnostics when ping fails are to try to use tcpdump to determine whether it's receive or transmit failing (or both). Quiet the network between two endpoints as much as you can so you can avoid noise from making the dumps more complex, and dump arp and icmp at both endpoints. Now try to ping from each end point to the other. One potential source of confusion is that ping requires ARP to work, and ARP can be a slightly confusing protocol as it usually resolves actively (query, response) but sometimes it receives passive updates or extends existing entries. What you want to look for is a packet sent by one side that isn't received by the other. You might find, for example, that your host receives packets fine, but the packets it transmits are never received. This would be indicative of a driver bug in which it fails to properly handle (for example) transmit queues filling, and might only trigger under very high load. Or, you might find that your host never receives anything the other side transmits, but can send fine. This might be indicative of a driver bug involving the receive code, or a problem with how interrupts are being handled more generally. It looks like the last non-routine maintenance to the driver was done by Maxime in about 2003; the more recent changes have all been updates to newbus/busdma infrastructure, ifnet changes, locking changes, etc. I've CC'd him as it sounds like he may have hardware... My advice would be to do the above tests and see if you can narrow down whether it's transmit, receive, or both failing. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:44:09 2008 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 3A48716A404 for ; Wed, 20 Feb 2008 11:44:09 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57004.mail.re3.yahoo.com (web57004.mail.re3.yahoo.com [66.196.97.108]) by mx1.freebsd.org (Postfix) with SMTP id CC31413C44B for ; Wed, 20 Feb 2008 11:44:08 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 29742 invoked by uid 60001); 20 Feb 2008 11:44:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SRTgezY/FTie40/nRCnDWYwg9KWzRwVEAd74BAl02998zgW/qqYsQUhqlU+yrloJzj78Zp9jA1dpo/39ambf4YC/Mk/VsKUnDdPgTxucAnl32Kw7Gg4GPbpIvZy00ZNPpT6bIMLIgt+UD+3olgvOj3jmvX5V4qmxu15MjFfFi+o=; X-YMail-OSG: 0XF_xOwVM1kM90MK2RkSsgESRE1BhE0xGnesmkewkZzrR1AN.EPgoee91hHgdDXVm1PNX5BsZFaN3s._O6W.jew0tosLma3JtV7C Received: from [165.21.155.93] by web57004.mail.re3.yahoo.com via HTTP; Wed, 20 Feb 2008 03:44:08 PST Date: Wed, 20 Feb 2008 03:44:08 -0800 (PST) From: Unga To: freebsd-current@freebsd.org In-Reply-To: <47BC0FEC.2050409@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <81227.27916.qm@web57004.mail.re3.yahoo.com> Subject: Re: Frequent network access freeze (in 7.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, 20 Feb 2008 11:44:09 -0000 --- Dominic Fandrey wrote: > Unga wrote: > > Hi all > > > > I'm running 7.0-PRERELEASE (RC2, dated > 15/02/2008), > > compiled from sources on i386 machine (512MB RAM, > > 3.0GHz, tx0: ). > > > > Network access freezes very frequently. Cannot > ping to > > any ip address. The only way to get networking > working > > again is reboot. > > > > I'm having this problem on 7.0 ever since I tried > it > > from BETA4. I have reported also to this list > before > > but sadly nobody was interested on it. > > > > If somebody is interested to look into this > problem, I > > could furnish with more detail and participate in > > testing. > > > > Thank you. > > > > Best regards > > Unga > > Show us the output of the commands "ifconfig" and > "netstat -r" while your > network works and after it stopped working. > Thank you for the reply. Sure will send outputs as soon as network access stops again. Unga ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:49:00 2008 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 D6E6A16A496 for ; Wed, 20 Feb 2008 11:49:00 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 929BE13C467 for ; Wed, 20 Feb 2008 11:49:00 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (F7263.f.ppp-pool.de [195.4.114.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id D2BCE128844; Wed, 20 Feb 2008 12:23:23 +0100 (CET) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 0C9483F43C; Wed, 20 Feb 2008 12:21:39 +0100 (CET) Message-ID: <47BC0D9A.1070201@vwsoft.com> Date: Wed, 20 Feb 2008 12:23:06 +0100 From: Volker User-Agent: Thunderbird 2.0.0.9 (X11/20080125) MIME-Version: 1.0 To: "Wilhelm B. Kloke" References: <47BADE07.9020402@gmx.de> <20080219180227.GC73371@dracon.ht-systems.ru> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1204111305.33615@NORQbeLrQK6UK37PhgUvZw X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-current@freebsd.org Subject: Re: mount order, Was: nfs mounts don't work through fstab 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, 20 Feb 2008 11:49:00 -0000 On 12/23/-58 20:59, Wilhelm B. Kloke wrote: > Stanislav Sedov schrieb: >>> I have a problem which is possibly related to this one. My FreeBSD7-amd64 >>> system fails to boot, because the network device nfe0 cannot be >>> configured by dhclient. Dhclient refuses to work because / is not >>> yet writeable. So I have to mount_-u_-o_r_/ manually, start >>> dhclient_nfe0 again, and quit single-user mode to get the >>> system booted. >>> >> Do you mount your / via nfs? > > No. The nfs mounts are not needed early. > > My idea about the problem was wrong, anyway. In my fstab there are > nullfs mounts which depend on the nfs mounts. I did not find a way > to delay these mounts. Giving them a higher mount pass number does > not seem to work. Wilhelm, what about the 'late' option? Volker From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 11:55:02 2008 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 1C9AF16A405; Wed, 20 Feb 2008 11:55:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id DE70A13C468; Wed, 20 Feb 2008 11:55:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KBt1Ul006523; Wed, 20 Feb 2008 06:55:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KBt0tv080523; Wed, 20 Feb 2008 06:55:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AB4A973039; Wed, 20 Feb 2008 06:55:00 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080220115500.AB4A973039@freebsd-current.sentex.ca> Date: Wed, 20 Feb 2008 06:55:00 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean 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: Wed, 20 Feb 2008 11:55:02 -0000 TB --- 2008-02-20 10:51:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-20 10:51:23 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-20 10:51:23 - cleaning the object tree TB --- 2008-02-20 10:51:50 - cvsupping the source tree TB --- 2008-02-20 10:51:50 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-20 10:51:57 - building world (CFLAGS=-O -pipe) TB --- 2008-02-20 10:51:57 - cd /src TB --- 2008-02-20 10:51:57 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 20 10:51:59 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 20 11:53:08 UTC 2008 TB --- 2008-02-20 11:53:08 - generating LINT kernel config TB --- 2008-02-20 11:53:08 - cd /src/sys/powerpc/conf TB --- 2008-02-20 11:53:08 - /usr/bin/make -B LINT TB --- 2008-02-20 11:53:08 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-20 11:53:08 - cd /src TB --- 2008-02-20 11:53:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 20 11:53:09 UTC 2008 >>> 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 [...] @ -> /src/sys machine -> /src/sys/powerpc/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/powerpc/src/sys/LINT /src/sys/modules/geom/geom_label/../../../geom/label/g_label.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ext2fs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_iso9660.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_msdosfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ntfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_reiserfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ufs.c ===> geom/geom_lvm (depend) @ -> /src/sys machine -> /src/sys/powerpc/include make: don't know how to make g_lvm.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-20 11:55:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-20 11:55:00 - ERROR: failed to build lint kernel TB --- 2008-02-20 11:55:00 - tinderbox aborted TB --- 2878.34 user 340.17 system 3816.88 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:03:30 2008 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 3154F16A400; Wed, 20 Feb 2008 12:03:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DD0FE13C46B; Wed, 20 Feb 2008 12:03:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KC3T4L029392; Wed, 20 Feb 2008 07:03:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KC3TEN053183; Wed, 20 Feb 2008 07:03:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CE94E73039; Wed, 20 Feb 2008 07:03:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080220120328.CE94E73039@freebsd-current.sentex.ca> Date: Wed, 20 Feb 2008 07:03:28 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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: Wed, 20 Feb 2008 12:03:30 -0000 TB --- 2008-02-20 11:02:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-20 11:02:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-20 11:02:45 - cleaning the object tree TB --- 2008-02-20 11:03:17 - cvsupping the source tree TB --- 2008-02-20 11:03:17 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-20 11:03:23 - building world (CFLAGS=-O -pipe) TB --- 2008-02-20 11:03:23 - cd /src TB --- 2008-02-20 11:03:23 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 20 11:03:25 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 20 12:01:31 UTC 2008 TB --- 2008-02-20 12:01:31 - generating LINT kernel config TB --- 2008-02-20 12:01:31 - cd /src/sys/sparc64/conf TB --- 2008-02-20 12:01:31 - /usr/bin/make -B LINT TB --- 2008-02-20 12:01:31 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-20 12:01:31 - cd /src TB --- 2008-02-20 12:01:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 20 12:01:31 UTC 2008 >>> 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 [...] @ -> /src/sys machine -> /src/sys/sparc64/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sparc64/src/sys/LINT /src/sys/modules/geom/geom_label/../../../geom/label/g_label.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ext2fs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_iso9660.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_msdosfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ntfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_reiserfs.c /src/sys/modules/geom/geom_label/../../../geom/label/g_label_ufs.c ===> geom/geom_lvm (depend) @ -> /src/sys machine -> /src/sys/sparc64/include make: don't know how to make g_lvm.c. Stop *** Error code 2 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-20 12:03:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-20 12:03:28 - ERROR: failed to build lint kernel TB --- 2008-02-20 12:03:28 - tinderbox aborted TB --- 2695.18 user 331.40 system 3643.30 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 08:51:24 2008 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 60A8816A402 for ; Wed, 20 Feb 2008 08:51:24 +0000 (UTC) (envelope-from walter.franzini@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.246]) by mx1.freebsd.org (Postfix) with ESMTP id 18F7D13C465 for ; Wed, 20 Feb 2008 08:51:23 +0000 (UTC) (envelope-from walter.franzini@gmail.com) Received: by ag-out-0708.google.com with SMTP id 5so3897715agb.7 for ; Wed, 20 Feb 2008 00:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references:from:date:message-id:user-agent:mime-version:content-type:sender; bh=Rw5l1iOIhomvVl0Q5BDYJe4KYcq7KBgJwxT/czEQ37o=; b=t87JrWLEJytkHDlgQBYu5FT9M3PC/PwVSzSw7I8VuqaQ86PcdteMHq4tpEC0zHhK2Ewf0/SltTOy/xwf/tbTBh/mtyJV4jSFsgSP8RPcPmCZgYwqpB8lb4u2YkFlmp7BPag/tT0VaI/3Vfyu5DvNs5JYrmVBLbSv46KjFybiTwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:from:date:message-id:user-agent:mime-version:content-type:sender; b=tzWqEZtZcZNFx4aEv+C803FrE3aX+3/3hKdACiyqr6mUUGjIo4SrwdH/CE3ViWf1AEGf4xsmHjXev8ZbhXHBuB8r3j8GbqdhuUQq7VKefoOYv0a0/yk04snerlpDq4HX1SpzdRjK0INCWUmn9X2vFtBpPQi0UFiFRTECOvBtAy0= Received: by 10.100.202.9 with SMTP id z9mr16548019anf.16.1203496569773; Wed, 20 Feb 2008 00:36:09 -0800 (PST) Received: from acer.nord-com.it ( [217.141.18.130]) by mx.google.com with ESMTPS id c28sm17295977anc.32.2008.02.20.00.36.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 00:36:08 -0800 (PST) To: "Aryeh M. Friedman" References: <47B8B57F.1080400@gmail.com> From: Walter Franzini Date: Wed, 20 Feb 2008 09:34:42 +0100 Message-ID: <86wsp0f2l9.fsf@acer.nord-com.it> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: "walter.franzini" X-Mailman-Approved-At: Wed, 20 Feb 2008 12:32:40 +0000 Cc: aegis-developers@lists.sourceforge.net, freebsd-current@freebsd.org Subject: Re: [Aegis-developers] strverscmp not detected missing 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, 20 Feb 2008 08:51:24 -0000 --=-=-= "Aryeh M. Friedman" writes: [...] > checking for strverscmp... yes > > This causes it to set HAVE_STRVERSCMP=1 and thus the build fails. Can you post the message gcc prints? -- Walter Franzini http://aegis.stepbuild.org/ PGP Public key ID: 1024D/CB3FEB43 Key fingerprint : FA26 C33B CAFF 7848 EFEB 7327 96AA 2D57 CB3F EB43 Key server : http://www.keyserver.net --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHu+YllqotV8s/60MRAsAWAJ0S5fSpue4/RBf1qcsC/651QD8WfQCfWS5a hnI+NRUwsU9KDB8dTI2DQNM= =9JJT -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:36:16 2008 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 1987F16A402 for ; Wed, 20 Feb 2008 12:36:16 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id BDF2713C4F9 for ; Wed, 20 Feb 2008 12:36:15 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=RuvbTMNKP+AjdbOjLLChzHdBmGwXO/J9vjnQ+HXbqpOu1Gkud5KuKOmSjlHd4THRfyXhtW8lCLMVchymTjCeh2s8OY1RMrCQxuHheYY0Zb+d3hA47RhMl+GIBXFrF1nUwxwzg/PaUEWvA4Gp1T9bZ3KFLmagjJB1mzlCauDD/BI=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRoBJ-000B73-3o; Wed, 20 Feb 2008 15:36:13 +0300 Date: Wed, 20 Feb 2008 15:36:12 +0300 From: Eygene Ryabinkin To: Sean , Dominic Fandrey Message-ID: References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.3 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_05 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 12:36:16 -0000 Me again. Wed, Feb 20, 2008 at 12:15:57PM +1100, Sean wrote: > From FreeBSD 5.5 (the earliest I can check readily) > > fstab(5) > > The fourth field, (fs_mntops), describes the mount options associated > with the file system. It is formatted as a comma separated list of > options. It contains at least the type of mount (see fs_type below) > plus > any additional options appropriate to the file system type. See the [...] > So the fs_type (rw, ro, etc.) has always been documented as obligatory, > though in slightly less than obvious wording. Good point. Moreover, I can not make it work even on 6.2-STABLE: ----- $ tail -1 /etc/fstab test:/usr/src /usr/src nfs noauto 0 0 $ mount /usr/src fstab: /etc/fstab:13: Inappropriate file type or format fstab: /etc/fstab:13: Inappropriate file type or format mount: /usr/src: unknown special file or file system $ mount -t nfs -a fstab: /etc/fstab:13: Inappropriate file type or format $ uname -a FreeBSD XXX 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Feb 12 16:31:48 MSK 2007 root@XXX:/usr/obj/usr/src/sys/XXX i386 ----- >> These 2 lines have been in use since 6.0 release: >> >> mobileKamikaze:/usr/src /usr/src nfs -b,-T,-R=5,noauto 0 0 >> mobileKamikaze:/usr/obj /usr/obj nfs -b,-T,-R=5,noauto 0 0 >> >> They stopped working with the switch to RELENG_7. >> >> # mount /usr/src/ 0 /root >> fstab: /etc/fstab:27: Inappropriate file type or format >> fstab: /etc/fstab:28: Inappropriate file type or format >> fstab: /etc/fstab:27: Inappropriate file type or format >> fstab: /etc/fstab:28: Inappropriate file type or format >> >> mount: /usr/src: unknown special file or file system >> >> fstabscan() is the place where the "Inappropriate file type or format" >> error is printed. The pointer char* cp either points to a string "rw", >> "ro" or "sw". If none of these are present cp is a NULL-pointer when the >> final check in line 207 is reached. So error(EFTYPE) is called. So, Dominic, something might had changed in your fstab. Because the code that checks for options exists in the fstab.c since revision 1.1, see http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/fstab.c?rev=1.1;content-type=text%2Fplain And the code in question had not been changed substantially since revision 1.3, see http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/fstab.c?annotate=1.15 May be some other utility (like mount) had extracted NFS mounts from the /etc/fstab by itself, but 1. it is silly, especially when fstab parsing functions are in libc; 2. I can not find such changes on the transition path 6.2 -> 7. While both of the arguments are not very convincing ;)), it may be well that you missed something about your system. Could you, please, recheck? -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:43:59 2008 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 2184116A403 for ; Wed, 20 Feb 2008 12:43:59 +0000 (UTC) (envelope-from rpaulo@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 A2B7B13C4E5 for ; Wed, 20 Feb 2008 12:43:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2113584fgg.35 for ; Wed, 20 Feb 2008 04:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=7kGRPGSnFkoCCpo6C6qMp3VwnhYBhyt/zFY5WKuNFCw=; b=b+R1PHTZ+ZRZzgCBq16LQ9wuyV0loagXFZHI8YfASFYeufCOG6a7GLKkb1y3oWgqaRURKVyEnq7Aonk0Z1Fg/ykg/vPHCWlrIeY+SBBBPKNdiwVX81eZAIhPKSTy7Mw7wCly6QAiflmy5C0GHgrnu1z/pAflMVImBJyIV9/1b1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=NmVfYM7SHDNIcBYf03G1nwCgN4+e9/GRlQBKs/rbLkI2ni3SSeFq4YtcAgtYg4vjkp+vJ0I/SSu0kgWg6YdRkgVJ64kWLWHiKllgqkSBhJhSg9C/qbf3/NAdF3sqgCVqz3vclL8oI85tPC9vnALc7+QLWGZzpZBwx5dVx2hNCHI= Received: by 10.82.127.14 with SMTP id z14mr14535532buc.26.1203511437308; Wed, 20 Feb 2008 04:43:57 -0800 (PST) Received: from ?192.168.1.105? ( [83.132.36.233]) by mx.google.com with ESMTPS id b30sm15937503ika.11.2008.02.20.04.43.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 04:43:56 -0800 (PST) Message-Id: <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> From: Rui Paulo To: Anton Yuzhaninov In-Reply-To: <47BB4E5D.7010505@citrin.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 01:56:01 +0000 References: <47BB4E5D.7010505@citrin.ru> X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo Cc: freebsd-current@freebsd.org Subject: Re: tcsh in current-8.0 coredump 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, 20 Feb 2008 12:43:59 -0000 On Feb 19, 2008, at 9:47 PM, Anton Yuzhaninov wrote: > Problem was described here: > http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 > http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html > > This was fixed for RELENG_7: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c > Revision 1.1.1.8 (vendor branch): download - view: text, markup, > annotated - select for diffs > Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp > Branches: ZOULAS, MAIN > CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, > RELENG_7 > Diff to: previous 1.1.1.7: preferred, colored > Changes since revision 1.1.1.7: +2 -1 lines > > Import vendor patch to fix postcmd regression in tcsh-6.15.00. > ------- > > But this bug was not fixed in HEAD. > Are you sure? I seem to recall this was fixed even before RELENG_7 was tagged. Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:46:35 2008 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 B17FF16A400 for ; Wed, 20 Feb 2008 12:46:35 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6124A13C474 for ; Wed, 20 Feb 2008 12:46:35 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=Tm6xU7YwSxco77MWOSwD+FpjOyQir8G86zU/ECwu4gw0/RWMABV8oZlK9bDbqTsrj1hyMYg1WGvA4ygc+eYmjWPtRoOZoZxfAS4HQU1dQKYnOt/IEsu+EHvNSZ2SLwqaI6qCYBNUQrLN+bNcFyKHPKGubdFB9lrOQr5QcHbTHa0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRoLH-000BB2-Pa; Wed, 20 Feb 2008 15:46:31 +0300 Date: Wed, 20 Feb 2008 15:46:30 +0300 From: Eygene Ryabinkin To: Volker , "Wilhelm B. Kloke" Message-ID: References: <47BADE07.9020402@gmx.de> <20080219180227.GC73371@dracon.ht-systems.ru> <47BC0D9A.1070201@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BC0D9A.1070201@vwsoft.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: mount order, Was: nfs mounts don't work through fstab 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, 20 Feb 2008 12:46:35 -0000 Wilhelm, Volker, good day. Wed, Feb 20, 2008 at 12:23:06PM +0100, Volker wrote: > what about the 'late' option? You can also try the 'extra_netfs_types' option in /etc/rc.conf. Setting it to something like "nullfs:NULLFS" will mount all your nullfs mountpoints after nfs (via /etc/rc.d/mountcritremote). 'late' option should also work: it permits per-mountpoint control. What to choose is up to you: if you want to delay only the specified mountpoint, use 'late'. If you want to make all mountpoints of a known type to be mounted after nfs & others -- use extra_netfs_types. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 12:54:05 2008 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 3B6AA16A407 for ; Wed, 20 Feb 2008 12:54:05 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id AECA513C461 for ; Wed, 20 Feb 2008 12:54:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 37144405486; Wed, 20 Feb 2008 13:54:03 +0100 (CET) Message-ID: <47BC22EA.4020708@bsdforen.de> Date: Wed, 20 Feb 2008 13:54:02 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Eygene Ryabinkin References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 12:54:05 -0000 Eygene Ryabinkin wrote: > Me again. > > Wed, Feb 20, 2008 at 12:15:57PM +1100, Sean wrote: >> From FreeBSD 5.5 (the earliest I can check readily) >> >> fstab(5) >> >> The fourth field, (fs_mntops), describes the mount options associated >> with the file system. It is formatted as a comma separated list of >> options. It contains at least the type of mount (see fs_type below) >> plus >> any additional options appropriate to the file system type. See the > [...] >> So the fs_type (rw, ro, etc.) has always been documented as obligatory, >> though in slightly less than obvious wording. > > Good point. Moreover, I can not make it work even on 6.2-STABLE: > ----- > $ tail -1 /etc/fstab > test:/usr/src /usr/src nfs noauto 0 0 > > $ mount /usr/src > fstab: /etc/fstab:13: Inappropriate file type or format > fstab: /etc/fstab:13: Inappropriate file type or format > mount: /usr/src: unknown special file or file system > > $ mount -t nfs -a > fstab: /etc/fstab:13: Inappropriate file type or format > > $ uname -a > FreeBSD XXX 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Feb 12 16:31:48 MSK 2007 root@XXX:/usr/obj/usr/src/sys/XXX i386 > ----- > >>> These 2 lines have been in use since 6.0 release: >>> >>> mobileKamikaze:/usr/src /usr/src nfs -b,-T,-R=5,noauto 0 0 >>> mobileKamikaze:/usr/obj /usr/obj nfs -b,-T,-R=5,noauto 0 0 >>> >>> They stopped working with the switch to RELENG_7. >>> >>> # mount /usr/src/ 0 /root >>> fstab: /etc/fstab:27: Inappropriate file type or format >>> fstab: /etc/fstab:28: Inappropriate file type or format >>> fstab: /etc/fstab:27: Inappropriate file type or format >>> fstab: /etc/fstab:28: Inappropriate file type or format >>> >>> mount: /usr/src: unknown special file or file system >>> >>> fstabscan() is the place where the "Inappropriate file type or format" >>> error is printed. The pointer char* cp either points to a string "rw", >>> "ro" or "sw". If none of these are present cp is a NULL-pointer when the >>> final check in line 207 is reached. So error(EFTYPE) is called. > > So, Dominic, something might had changed in your fstab. Because > the code that checks for options exists in the fstab.c since revision > 1.1, see http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/fstab.c?rev=1.1;content-type=text%2Fplain > And the code in question had not been changed substantially since > revision 1.3, see http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/fstab.c?annotate=1.15 > > May be some other utility (like mount) had extracted NFS mounts from > the /etc/fstab by itself, but > 1. it is silly, especially when fstab parsing functions are in libc; > 2. I can not find such changes on the transition path 6.2 -> 7. > While both of the arguments are not very convincing ;)), it may be > well that you missed something about your system. > > Could you, please, recheck? I'm quite certain that I used to not need this. I have checked the history of Wiki articles where I documented this. The mount command has undergone significant changes with the switch to nmount, I suppose whatever happened, happened there. Apparently nobody else had this problem. I interpreted the error message in a way that I thought mount had problems with the host:/mountpoint syntax for nfs mounts. A clearer error message might be appropriate. Inappropriate file type or format doesn't make me consider options. Only by tracking it down in the code was I able to determine what's going on. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 09:40:34 2008 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 109E316A407 for ; Wed, 20 Feb 2008 09:40:34 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (host3.dynacom.ondsl.gr [62.103.35.211]) by mx1.freebsd.org (Postfix) with ESMTP id 5EECE13C465 for ; Wed, 20 Feb 2008 09:40:33 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.14.2/8.14.2) with ESMTP id m1K9BGD7077205 for ; Wed, 20 Feb 2008 11:11:16 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Received: from localhost (localhost [[UNIX: localhost]]) by smadev.internal.net (8.14.2/8.14.2/Submit) id m1K9BGrn077204 for freebsd-current@freebsd.org; Wed, 20 Feb 2008 11:11:16 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: freebsd-current@freebsd.org Date: Wed, 20 Feb 2008 11:11:15 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802201111.16340.achill@matrix.gatewaynet.com> X-Mailman-Approved-At: Wed, 20 Feb 2008 13:00:34 +0000 Subject: Problem with various ports 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, 20 Feb 2008 09:40:34 -0000 I had trouble building textproc/docbook-utils (docbook-utils-0.6.14_3) in a fresh new 7.0-RC2 FreeBSD 7.0-RC2 #5 the problem starts at the begining of config: configure.in:4: warning: underquoted definition of AC_FIND_PROGRAM^M run info '(automake)Extending aclocal'^M or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal^M /usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of AM_PATH_LINC^M /usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of AM_PATH_LIBFAME^M /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE^M /usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB^M also with grub i get /usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of AM_PATH_LINC^M run info '(automake)Extending aclocal'^M or see http://sources.redhat.com/automake/automake.html#Extending-aclocal^M /usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of AM_PATH_LIBFAME^M /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE^M /usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB^M Since i am doing the install for some 4 days now, i had no time to investigate furthur and installed the binary packages when needed, to go on with my install. If some one could take a look, that would be great, since its the only problem i got with 7.0, (better than previous experiences with 5,6-STABLE) Thanks! --Achilleas Mantzios KOSOVO IS SERBIA FOR EVER From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:27:43 2008 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 3343916A400 for ; Wed, 20 Feb 2008 13:27:43 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id DD90413C46E for ; Wed, 20 Feb 2008 13:27:42 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [81.19.90.80] (unknown [81.19.90.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTP id 6016D1700E for ; Wed, 20 Feb 2008 16:27:41 +0300 (MSK) Message-ID: <47BC2AAB.5090605@citrin.ru> Date: Wed, 20 Feb 2008 16:27:07 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <47BB4E5D.7010505@citrin.ru> <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> In-Reply-To: <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: tcsh in current-8.0 coredump 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, 20 Feb 2008 13:27:43 -0000 On 20.02.2008 4:56, Rui Paulo wrote: > > On Feb 19, 2008, at 9:47 PM, Anton Yuzhaninov wrote: > >> Problem was described here: >> http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 >> http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html >> >> This was fixed for RELENG_7: >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c >> Revision 1.1.1.8 (vendor branch): download - view: text, markup, >> annotated - select for diffs >> Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp >> Branches: ZOULAS, MAIN >> CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, RELENG_7 >> Diff to: previous 1.1.1.7: preferred, colored >> Changes since revision 1.1.1.7: +2 -1 lines >> >> Import vendor patch to fix postcmd regression in tcsh-6.15.00. >> ------- >> >> But this bug was not fixed in HEAD. >> > > Are you sure? I seem to recall this was fixed even before RELENG_7 was > tagged. > $ cvs up $ cvs diff -r HEAD -r RELENG_7 contrib/tcsh/sh.lex.c Index: contrib/tcsh/sh.lex.c =================================================================== RCS file: /home/ncvs/src/contrib/tcsh/sh.lex.c,v retrieving revision 1.1.1.9 retrieving revision 1.1.1.8 diff -u -r1.1.1.9 -r1.1.1.8 --- contrib/tcsh/sh.lex.c 15 Oct 2007 16:54:07 -0000 1.1.1.9 +++ contrib/tcsh/sh.lex.c 3 Apr 2007 15:51:53 -0000 1.1.1.8 @@ -851,7 +851,8 @@ return (en); } slhs.len = 0; - Strbuf_append(&slhs, lhsb.s); + if (lhsb.s != NULL && lhsb.len != 0) + Strbuf_append(&slhs, lhsb.s); Strbuf_terminate(&slhs); if (exclc) en = dosub(sc, en, global); As you can see from cvs diff, null pointer check present in RELENG_7. but absent in HEAD -- WBR, Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:28:13 2008 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 C6A9216A402 for ; Wed, 20 Feb 2008 13:28:13 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6B55613C4CC for ; Wed, 20 Feb 2008 13:28:13 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=cn6VlnjF1seSYhTuO29mYAo7Q2DpijWHRZlJUG3UlcZy3p9oyUA+rmNJ70FjjaP1rbGwe/kX1+V2Qb4BjtdXJRhxTlct4OvfqO162h0CbMwm5gpwhrqAzsiaDXsD7XVSvVcUL2pBjpTRR7EnxSaHdLEIAmjUsmiagP6PB5E8hfE=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRozc-000BPl-4e; Wed, 20 Feb 2008 16:28:12 +0300 Date: Wed, 20 Feb 2008 16:28:11 +0300 From: Eygene Ryabinkin To: Dominic Fandrey Message-ID: References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BC22EA.4020708@bsdforen.de> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 13:28:13 -0000 Dominic, Wed, Feb 20, 2008 at 01:54:02PM +0100, Dominic Fandrey wrote: >> May be some other utility (like mount) had extracted NFS mounts from >> the /etc/fstab by itself, but >> 1. it is silly, especially when fstab parsing functions are in libc; >> 2. I can not find such changes on the transition path 6.2 -> 7. >> While both of the arguments are not very convincing ;)), it may be >> well that you missed something about your system. >> >> Could you, please, recheck? > > I'm quite certain that I used to not need this. I have checked the history > of Wiki articles where I documented this. OK, what version of the system you had before the problems started to show? -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:32:59 2008 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 AA8BB16A404 for ; Wed, 20 Feb 2008 13:32:59 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 5E00913C455 for ; Wed, 20 Feb 2008 13:32:58 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 783CA40592F; Wed, 20 Feb 2008 14:32:57 +0100 (CET) Message-ID: <47BC2C08.4040109@bsdforen.de> Date: Wed, 20 Feb 2008 14:32:56 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Eygene Ryabinkin References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 13:32:59 -0000 Eygene Ryabinkin wrote: > Dominic, > > Wed, Feb 20, 2008 at 01:54:02PM +0100, Dominic Fandrey wrote: >>> May be some other utility (like mount) had extracted NFS mounts from >>> the /etc/fstab by itself, but >>> 1. it is silly, especially when fstab parsing functions are in libc; >>> 2. I can not find such changes on the transition path 6.2 -> 7. >>> While both of the arguments are not very convincing ;)), it may be >>> well that you missed something about your system. >>> >>> Could you, please, recheck? >> I'm quite certain that I used to not need this. I have checked the history >> of Wiki articles where I documented this. > > OK, what version of the system you had before the problems started > to show? I switched from RELENG_6 to RELENG_7 shortly after RELENG_8 was branched. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:39:44 2008 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 0C43F16A402 for ; Wed, 20 Feb 2008 13:39:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B101913C442 for ; Wed, 20 Feb 2008 13:39:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=jorqXMQjWy6EV3adJAau0pXH0vunCymXB/nuwboORloBnDdzZ1ZLlH3fwQOYLimELDWVPs8sgZ5qHbPmhFQXqqsz+d3tCMim5u5gCyYZn1rU+lFc/VqvVfPIj//GFy07+RC/r1WV0BHYD+G3lnV379YxM68zX55zuYE/70pVqRU=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRpAk-000BTr-AZ; Wed, 20 Feb 2008 16:39:42 +0300 Date: Wed, 20 Feb 2008 16:39:41 +0300 From: Eygene Ryabinkin To: Achilleas Mantzios Message-ID: References: <200802201111.16340.achill@matrix.gatewaynet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200802201111.16340.achill@matrix.gatewaynet.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50, WEIRD_PORT Cc: freebsd-current@freebsd.org Subject: Re: Problem with various ports 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, 20 Feb 2008 13:39:44 -0000 Achilleas, good day. Wed, Feb 20, 2008 at 11:11:15AM +0200, Achilleas Mantzios wrote: > I had trouble building textproc/docbook-utils (docbook-utils-0.6.14_3) in a fresh new > 7.0-RC2 FreeBSD 7.0-RC2 #5 > the problem starts at the begining of config: > > > configure.in:4: warning: underquoted definition of AC_FIND_PROGRAM^M > run info '(automake)Extending aclocal'^M > or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal^M > /usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of AM_PATH_LINC^M > /usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of AM_PATH_LIBFAME^M > /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE^M > /usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB^M And what is the trouble? The port builds, isn't it? 'configure.in' uses old syntax for AC_DEFUN and there are some other underquoteds, but it seems not to hurt anyone. The real problem is that file 'aclocal.m4' has rather distant timestamp (year 2004), so the Makefile and configure are rebuilt. But the port builds for me at 7.0-PRERELEASE though I have the warning messages as you. Or it does not build for you? -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:46:32 2008 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 E43E316A403 for ; Wed, 20 Feb 2008 13:46:32 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9119213C4FB for ; Wed, 20 Feb 2008 13:46:32 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=WokHKwPem/bhTkS8RMPRwmUc9SUsZiMvYLRsqEAoNKfVj+JR10eFsYhgkPTBw+YnzYxRMuqiw6nN2t9/El5UaMqOtxyxX69DP0Jpm2COIhan/NdS4D1RjphcPmifeZqZVU2pUDW8U9CEQT276+PeoU77hz6TmvT80VW9Bgiu3tE=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRpHL-000BWE-KS; Wed, 20 Feb 2008 16:46:31 +0300 Date: Wed, 20 Feb 2008 16:46:30 +0300 From: Eygene Ryabinkin To: Dominic Fandrey Message-ID: References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> <47BC2C08.4040109@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BC2C08.4040109@bsdforen.de> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 13:46:33 -0000 Wed, Feb 20, 2008 at 02:32:56PM +0100, Dominic Fandrey wrote: >> OK, what version of the system you had before the problems started >> to show? > > I switched from RELENG_6 to RELENG_7 shortly after RELENG_8 was branched. Could you please specify the time frame when you CVSupped your last RELENG_6: as I wrote before, I have the same problems as you have with RELENG_7, but with 6.2-STABLE from 12th February 2007. It means that the rather old RELENG_6 has the same behaviour as the 7.x. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:53:24 2008 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 CB62F16A400 for ; Wed, 20 Feb 2008 13:53:24 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 8043613C4CC for ; Wed, 20 Feb 2008 13:53:24 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 7C122405488; Wed, 20 Feb 2008 14:53:23 +0100 (CET) Message-ID: <47BC30D2.9030301@bsdforen.de> Date: Wed, 20 Feb 2008 14:53:22 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Eygene Ryabinkin References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> <47BC2C08.4040109@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 13:53:24 -0000 Eygene Ryabinkin wrote: > Wed, Feb 20, 2008 at 02:32:56PM +0100, Dominic Fandrey wrote: >>> OK, what version of the system you had before the problems started >>> to show? >> I switched from RELENG_6 to RELENG_7 shortly after RELENG_8 was branched. > > Could you please specify the time frame when you CVSupped your last > RELENG_6: as I wrote before, I have the same problems as you have > with RELENG_7, but with 6.2-STABLE from 12th February 2007. It > means that the rather old RELENG_6 has the same behaviour as the 7.x. I csupped the last RELENG_6 about two weeks before I switched to RELENG_7. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:54:49 2008 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 3894316A403 for ; Wed, 20 Feb 2008 13:54:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id D81B413C44B for ; Wed, 20 Feb 2008 13:54:48 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=ANmzsQGfpOsQBI+V9rDjOqoGIyzMJm69/d8nG+f2Jwc3rBChP1xE9v0NOyPSxzV0fIirS//vJkTQCXQXeCUxqRzZUQQMxktqP33DDSwSMn7HwRIj6Zt6tCpbkOhjJkxT6vaIBNS/n52e4dZNb9BWQmLi6lFtNUk9XLlRdMI+db0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRpPL-000BZC-GA; Wed, 20 Feb 2008 16:54:47 +0300 Date: Wed, 20 Feb 2008 16:54:46 +0300 From: Eygene Ryabinkin To: Dominic Fandrey Message-ID: References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> <47BC2C08.4040109@bsdforen.de> <47BC30D2.9030301@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BC30D2.9030301@bsdforen.de> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 13:54:49 -0000 Wed, Feb 20, 2008 at 02:53:22PM +0100, Dominic Fandrey wrote: >> Could you please specify the time frame when you CVSupped your last >> RELENG_6: as I wrote before, I have the same problems as you have >> with RELENG_7, but with 6.2-STABLE from 12th February 2007. It >> means that the rather old RELENG_6 has the same behaviour as the 7.x. > > I csupped the last RELENG_6 about two weeks before I switched to RELENG_7. And the calendar week and day were? -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 14:09:22 2008 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 2A1D216A408 for ; Wed, 20 Feb 2008 14:09:22 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id D0C1113C4E5 for ; Wed, 20 Feb 2008 14:09:21 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id B1134405488; Wed, 20 Feb 2008 15:09:20 +0100 (CET) Message-ID: <47BC348F.5080300@bsdforen.de> Date: Wed, 20 Feb 2008 15:09:19 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Eygene Ryabinkin References: <47BADE07.9020402@gmx.de> <7CZsNG/ix1SXULta6Bdgf51ZwDE@TqmFlxFMySuiJ36EgnrGRgt6KQ8> <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> <47BC2C08.4040109@bsdforen.de> <47BC30D2.9030301@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 14:09:22 -0000 Eygene Ryabinkin wrote: > Wed, Feb 20, 2008 at 02:53:22PM +0100, Dominic Fandrey wrote: >>> Could you please specify the time frame when you CVSupped your last >>> RELENG_6: as I wrote before, I have the same problems as you have >>> with RELENG_7, but with 6.2-STABLE from 12th February 2007. It >>> means that the rather old RELENG_6 has the same behaviour as the 7.x. >> I csupped the last RELENG_6 about two weeks before I switched to RELENG_7. > > And the calendar week and day were? I'm not going to check the CVS logs to find out when exactly RELENG_8 was branched. It's not like this is an important issue. Just an error message that doesn't make much sense. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 14:20:08 2008 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 3019B16A400 for ; Wed, 20 Feb 2008 14:20:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id CFEB113C469 for ; Wed, 20 Feb 2008 14:20:07 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=qmp5NrYePeUQd1RdTRqd1sDBkk+7KG08gEvFRSMFEIkNs3S+oLTGsqC0Wv7dMUxL1dN0IjYHtSFHVro7B+Z5fuFX2w6fn26JiQk2JT/XL6Xt9V+8/LR2ukXDCKyUOXsGIRPoeUYjxk5oFGbubqW/lLltsJnDi2pWCaFsgiqW588=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRpnq-000BlA-Jf; Wed, 20 Feb 2008 17:20:06 +0300 Date: Wed, 20 Feb 2008 17:20:05 +0300 From: Eygene Ryabinkin To: Dominic Fandrey Message-ID: References: <47BB01BE.4010309@gmx.de> <0FD9F726-6E45-4A81-9DE1-E3F0AAF3668B@gothic.net.au> <47BC22EA.4020708@bsdforen.de> <47BC2C08.4040109@bsdforen.de> <47BC30D2.9030301@bsdforen.de> <47BC348F.5080300@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BC348F.5080300@bsdforen.de> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: nfs mounts don't work through fstab 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, 20 Feb 2008 14:20:08 -0000 Wed, Feb 20, 2008 at 03:09:19PM +0100, Dominic Fandrey wrote: >> And the calendar week and day were? > > I'm not going to check the CVS logs to find out when exactly RELENG_8 was > branched. > > It's not like this is an important issue. Just an error message that > doesn't make much sense. OK, as you want. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 14:31:31 2008 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 49EE616A403 for ; Wed, 20 Feb 2008 14:31:31 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id EBF7513C458 for ; Wed, 20 Feb 2008 14:31:30 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=EOG5MtOxKm4esxtQsgqykj9D46tYdnWGQXRSUfISu8sYC2WgocKXY1X7fPvA0ywkhH4aZtc1rIaehPhF3Ff6Ovm0JcYZQRaHuaJ5G8XLSUxdByEvMOcP1UVSWjUVkgir9n9nRIM7rfefCeiAmoNRcX9PLDtIC4T55e5fTjkE0Uk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRpyr-000Bpe-JJ; Wed, 20 Feb 2008 17:31:29 +0300 Date: Wed, 20 Feb 2008 17:31:28 +0300 From: Eygene Ryabinkin To: Achilleas Mantzios Message-ID: References: <200802201111.16340.achill@matrix.gatewaynet.com> <200802201547.17360.achill@matrix.gatewaynet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200802201547.17360.achill@matrix.gatewaynet.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: Problem with various ports 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, 20 Feb 2008 14:31:31 -0000 Achilleas, Wed, Feb 20, 2008 at 03:47:16PM +0200, Achilleas Mantzios wrote: > The below build, later complains about not existing /usr/local/share/xml/sdocbook/4.1.2.5/catalog, > creating it by hand just reincarnated the problem. > here is the whole original output: > [...] > SGML_CATALOG_FILES=/usr/local/share/sgml/catalog \ > SGML_SEARCH_PATH=../..:../../doc:.. \ > jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ > -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml > jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/share/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) I bet that your '/usr/local/share/sgml/catalog.ports' has entry for '/usr/local/share/xml/sdocbook/4.1.2.5/catalog'. Do you have sdocbook-xml port version 4.1.2.5 installed? Will it solve the problem if you'll remove this line from /usr/local/share/sgml/catalog.ports? -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 13:47:49 2008 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 34BE016A400 for ; Wed, 20 Feb 2008 13:47:49 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (host3.dynacom.ondsl.gr [62.103.35.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1C63D13C53A for ; Wed, 20 Feb 2008 13:47:42 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.14.2/8.14.2) with ESMTP id m1KDlMha078508; Wed, 20 Feb 2008 15:47:22 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Received: from localhost (localhost [[UNIX: localhost]]) by smadev.internal.net (8.14.2/8.14.2/Submit) id m1KDlHWm078507; Wed, 20 Feb 2008 15:47:17 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: Eygene Ryabinkin Date: Wed, 20 Feb 2008 15:47:16 +0200 User-Agent: KMail/1.9.7 References: <200802201111.16340.achill@matrix.gatewaynet.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802201547.17360.achill@matrix.gatewaynet.com> X-Mailman-Approved-At: Wed, 20 Feb 2008 15:12:24 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Problem with various ports 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, 20 Feb 2008 13:47:49 -0000 =D3=F4=E9=F2 Wednesday 20 February 2008 15:39:41 =EF/=E7 Eygene Ryabinkin = =DD=E3=F1=E1=F8=E5: > Achilleas, good day. >=20 > Wed, Feb 20, 2008 at 11:11:15AM +0200, Achilleas Mantzios wrote: > > I had trouble building textproc/docbook-utils (docbook-utils-0.6.14_3) = in a fresh new > > 7.0-RC2 FreeBSD 7.0-RC2 #5 > > the problem starts at the begining of config: > >=20 > >=20 > > configure.in:4: warning: underquoted definition of AC_FIND_PROGRAM^M > > run info '(automake)Extending aclocal'^M > > or see http://sources.redhat.com/automake/automake.html#Extending%20a= clocal^M > > /usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of = AM_PATH_LINC^M > > /usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition = of AM_PATH_LIBFAME^M > > /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definiti= on of AM_PATH_AUDIOFILE^M > > /usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition o= f AM_PATH_AALIB^M >=20 > And what is the trouble? The port builds, isn't it? 'configure.in' > uses old syntax for AC_DEFUN and there are some other underquoteds, > but it seems not to hurt anyone. >=20 > The real problem is that file 'aclocal.m4' has rather distant > timestamp (year 2004), so the Makefile and configure are rebuilt. > But the port builds for me at 7.0-PRERELEASE though I have the > warning messages as you. >=20 > Or it does not build for you? Hi Eygene, thanx for contacting. The below build, later complains about not existing /usr/local/share/xml/sd= ocbook/4.1.2.5/catalog, creating it by hand just reincarnated the problem. here is the whole original output: Script started on Wed Feb 20 10:38:03 2008 doroot@smadev:/usr/ports/textproc/docbook-utils# make =3D=3D=3D> Vulnerability check disabled, database not found =3D=3D=3D> Extracting for docbook-utils-0.6.14_3 =3D> MD5 Checksum OK for docbook-utils-0.6.14.tar.gz. =3D> SHA256 Checksum OK for docbook-utils-0.6.14.tar.gz. =3D=3D=3D> Patching for docbook-utils-0.6.14_3 =3D=3D=3D> Applying FreeBSD patches for docbook-utils-0.6.14_3 =3D=3D=3D> docbook-utils-0.6.14_3 depends on executable: nsgmls - found =3D=3D=3D> docbook-utils-0.6.14_3 depends on file: /usr/local/share/sgml/= docbook/3.1/docbook.dtd - found =3D=3D=3D> docbook-utils-0.6.14_3 depends on file: /usr/local/share/sgml/= docbook/dsssl - found =3D=3D=3D> docbook-utils-0.6.14_3 depends on executable: gmake - found =3D=3D=3D> Configuring for docbook-utils-0.6.14_3 /bin/rm -f /usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/conf= ig.cache configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c -o root -g whe= el checking whether build environment is sane... yes checking for gawk... gawk checking whether gmake sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating docbook-utils.spec config.status: creating bin/Makefile config.status: creating bin/jw config.status: creating bin/sgmldiff config.status: creating backends/Makefile config.status: creating backends/man config.status: creating backends/texi config.status: creating frontends/Makefile config.status: creating frontends/docbook config.status: creating helpers/Makefile config.status: creating doc/Makefile config.status: creating doc/version config.status: creating doc/refentry/Makefile config.status: creating doc/man/Makefile config.status: creating doc/HTML/Makefile =3D=3D=3D> Building for docbook-utils-0.6.14_3 cd . && /bin/sh /usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14= /missing --run aclocal-1.8=20 configure.in:4: warning: underquoted definition of AC_FIND_PROGRAM run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20acloc= al /usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of AM_P= ATH_LINC /usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of A= M_PATH_LIBFAME /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition o= f AM_PATH_AUDIOFILE /usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of AM= _PATH_AALIB cd . && /bin/sh /usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.1= 4/missing --run automake-1.8 --gnu=20 cd . && /bin/sh /usr/ports/textproc/docbook-utils/work/docbook-utils-0.6.14= /missing --run autoconf /bin/sh ./config.status --recheck running /bin/sh ./configure --prefix=3D/usr/local --mandir=3D/usr/local/ma= n --infodir=3D/usr/local/info/ i386-portbld-freebsd7.0 build_alias=3Di386-p= ortbld-freebsd7.0 host_alias=3Di386-portbld-freebsd7.0 target_alias=3Di386-= portbld-freebsd7.0 --no-create --no-recursion configure: WARNING: you should use --build, --host, --target checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile config.status: creating docbook-utils.spec config.status: creating bin/Makefile config.status: creating bin/jw config.status: creating bin/sgmldiff config.status: creating backends/Makefile config.status: creating backends/man config.status: creating backends/texi config.status: creating frontends/Makefile config.status: creating frontends/docbook config.status: creating helpers/Makefile config.status: creating doc/Makefile config.status: creating doc/version config.status: creating doc/refentry/Makefile config.status: creating doc/man/Makefile config.status: creating doc/HTML/Makefile Making all in backends gmake[1]: Entering directory `/usr/ports/textproc/docbook-utils/work/docboo= k-utils-0.6.14/backends' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook= =2Dutils-0.6.14/backends' Making all in bin gmake[1]: Entering directory `/usr/ports/textproc/docbook-utils/work/docboo= k-utils-0.6.14/bin' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook= =2Dutils-0.6.14/bin' Making all in doc gmake[1]: Entering directory `/usr/ports/textproc/docbook-utils/work/docboo= k-utils-0.6.14/doc' Making all in refentry gmake[2]: Entering directory `/usr/ports/textproc/docbook-utils/work/docboo= k-utils-0.6.14/doc/refentry' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook= =2Dutils-0.6.14/doc/refentry' Making all in man gmake[2]: Entering directory `/usr/ports/textproc/docbook-utils/work/docboo= k-utils-0.6.14/doc/man' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook= =2Dutils-0.6.14/doc/man' Making all in HTML gmake[2]: Entering directory `/usr/ports/textproc/docbook-utils/work/docboo= k-utils-0.6.14/doc/HTML' SGML_CATALOG_FILES=3D/usr/local/share/sgml/catalog \ SGML_SEARCH_PATH=3D../..:../../doc:.. \ jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:8:19:E: "X21B6" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:9:19:E: "X21B7" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:10:17:E: "X21D3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:11:18:E: "X21CA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:12:18:E: "X21C3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:13:18:E: "X21C2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:14:18:E: "X21DA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:15:17:E: "X219E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:16:18:E: "X21C7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:17:19:E: "X21A9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:18:19:E: "X21AB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:19:19:E: "X21A2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:20:18:E: "X21BD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:21:18:E: "X21BC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:22:17:E: "X21D4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:23:17:E: "X2194" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:24:19:E: "X21C6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:25:19:E: "X21C4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:26:18:E: "X21AD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:27:19:E: "X21CC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:28:19:E: "X21CB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:29:16:E: "X21B0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:30:16:E: "X21A6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:31:18:E: "X22B8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:32:18:E: "X2197" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:33:18:E: "X21CD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:34:18:E: "X219A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:35:18:E: "X21CE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:36:18:E: "X21AE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:37:18:E: "X219B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:38:18:E: "X21CF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:39:18:E: "X2196" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:40:18:E: "X21BA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:41:18:E: "X21BB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:42:18:E: "X21DB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:43:17:E: "X21A0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:44:18:E: "X21C9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:45:19:E: "X21AA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:46:19:E: "X21AC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:47:19:E: "X21A3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:48:18:E: "X219D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:49:18:E: "X21C1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:50:18:E: "X21C0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:51:16:E: "X21B1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:52:18:E: "X2198" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:53:18:E: "X2199" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:54:17:E: "X21D1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:55:18:E: "X21C8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:56:17:E: "X21D5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:57:17:E: "X2195" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:58:18:E: "X21BF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:59:18:E: "X21BE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:60:18:E: "X21D0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:61:18:E: "X2194" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:62:18:E: "X2194" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:63:18:E: "X21D2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:8:18:E: "X2210" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:9:19:E: "X2306" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:10:19:E: "X22BC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:11:16:E: "X22D2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:12:16:E: "X22D3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:13:18:E: "X22CE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:14:18:E: "X22CF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:15:17:E: "X22C4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:16:19:E: "X22C7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:17:19:E: "X22BA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:18:19:E: "X22CB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:19:19:E: "X22C9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:20:19:E: "X229F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:21:17:E: "X229B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:22:17:E: "X229A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:23:18:E: "X229D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:24:17:E: "X2299" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:25:19:E: "X2296" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:26:18:E: "X2295" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:27:17:E: "X2298" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:28:19:E: "X2297" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:29:18:E: "X229E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:30:19:E: "X2214" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:31:19:E: "X22CC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:32:19:E: "X22CA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:33:17:E: "X22C5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:34:18:E: "X22A1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:35:18:E: "X2216" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:36:18:E: "X2293" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:37:18:E: "X2294" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:38:19:E: "X2216" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:39:19:E: "X22C6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:40:19:E: "X22A0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:41:16:E: "X22A4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:42:18:E: "X228E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:43:19:E: "X2240" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:44:18:E: "X25CB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:45:18:E: "X25BD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:46:18:E: "X25B3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:47:19:E: "X2210" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:48:17:E: "X220F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsb.ent:49:16:E: "X2211" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:6:18:E: "X2309" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:7:19:E: "X230B" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:8:19:E: "XE291" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:9:19:E: "X231D" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:10:19:E: "X231F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:11:18:E: "X2308" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:12:19:E: "X230A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:14:19:E: "X231C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsc.ent:15:19:E: "X231E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:8:17:E: "XE411" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:9:16:E: "X2269" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:10:16:E: "X2269" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:11:18:E: "X22E7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:12:17:E: "X2269" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:13:17:E: "XE2A2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:14:16:E: "X2268" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:15:16:E: "X2268" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:16:18:E: "X22E6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:17:17:E: "X2268" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:18:16:E: "X2249" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:19:18:E: "X2247" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:20:19:E: "X2262" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:21:16:E: "X2271" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:22:16:E: "X2271" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:23:17:E: "X2271" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:24:16:E: "X226F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:25:16:E: "X2270" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:26:16:E: "X2270" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:27:17:E: "X2270" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:28:16:E: "X226E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:29:18:E: "X22EA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:30:19:E: "X22EC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:31:17:E: "X2224" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:32:17:E: "X2226" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:33:16:E: "X2280" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:34:17:E: "X22E0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:35:18:E: "X22EB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:36:19:E: "X22ED" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:37:16:E: "X2281" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:38:17:E: "X22E1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:39:17:E: "X2241" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:40:18:E: "X2244" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:41:18:E: "XE2AA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:42:18:E: "X2226" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:43:17:E: "X2284" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:44:18:E: "X2288" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:45:18:E: "X2288" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:46:17:E: "X2285" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:47:18:E: "X2289" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:48:18:E: "X2289" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:49:19:E: "X22AC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:50:19:E: "X22AD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:51:19:E: "X22AF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:52:19:E: "X22AE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:53:18:E: "X22E8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:54:17:E: "XE2B3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:55:19:E: "X22E8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:56:18:E: "X22E9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:57:17:E: "XE2B5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:58:19:E: "X22E9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:59:18:E: "X228A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:60:18:E: "X228A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:61:18:E: "X228B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:62:18:E: "X228B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:63:19:E: "XE2B8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:64:19:E: "X228A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:65:19:E: "X228B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsn.ent:66:19:E: "X228B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:8:16:E: "X2220" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:9:19:E: "X2221" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:10:17:E: "X2136" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:11:19:E: "X2035" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:12:17:E: "X2201" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:13:19:E: "X2138" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:14:16:E: "X2113" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:15:18:E: "X2205" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:16:18:E: "X2137" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:17:18:E: "X2111" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:18:19:E: "X0131" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:20:19:E: "X2204" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:21:15:E: "X24C8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:22:19:E: "X210F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:23:17:E: "X211C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:24:18:E: "XFE68" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:25:19:E: "X2032" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amso.ent:26:19:E: "X2118" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:8:16:E: "X224A" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:9:18:E: "X224D" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:10:18:E: "X224C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:11:18:E: "X220D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:12:19:E: "X22C8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:13:17:E: "X223D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:14:18:E: "X22CD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:15:17:E: "X224E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:16:18:E: "X224F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:17:17:E: "X2257" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:18:19:E: "X2254" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:19:18:E: "X22DE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:20:18:E: "X22DF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:21:18:E: "X227C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsr.ent:22:18:E: "X22A3" i= s not a function name jade:I: maximum number of errors (200) reached; change with -E option jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:6:16:E: "X0430" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:7:16:E: "X0410" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:8:16:E: "X0431" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:9:16:E: "X0411" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:10:16:E: "X0432" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:11:16:E: "X0412" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:12:16:E: "X0433" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:13:16:E: "X0413" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:14:16:E: "X0434" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:15:16:E: "X0414" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:16:17:E: "X0435" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:17:17:E: "X0415" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:18:17:E: "X0451" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:19:17:E: "X0401" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:20:17:E: "X0436" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:21:17:E: "X0416" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:22:16:E: "X0437" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:23:16:E: "X0417" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:24:16:E: "X0438" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:25:16:E: "X0418" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:26:16:E: "X0439" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:27:16:E: "X0419" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:28:16:E: "X043A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:29:16:E: "X041A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:30:16:E: "X043B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:31:16:E: "X041B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:32:16:E: "X043C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:33:16:E: "X041C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:34:16:E: "X043D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:35:16:E: "X041D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:36:16:E: "X043E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:37:16:E: "X041E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:38:16:E: "X043F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:39:16:E: "X041F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:40:16:E: "X0440" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:41:16:E: "X0420" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:42:16:E: "X0441" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:43:16:E: "X0421" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:44:16:E: "X0442" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:45:16:E: "X0422" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:46:16:E: "X0443" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:47:16:E: "X0423" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:48:16:E: "X0444" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:49:16:E: "X0424" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:50:17:E: "X0445" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:51:17:E: "X0425" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:52:17:E: "X0446" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:53:17:E: "X0426" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:54:17:E: "X0447" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:55:17:E: "X0427" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:56:17:E: "X0448" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:57:17:E: "X0428" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:58:19:E: "X0449" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:59:19:E: "X0429" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:60:19:E: "X044A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:61:19:E: "X042A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:62:16:E: "X044B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:63:16:E: "X042B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:64:19:E: "X044C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:65:19:E: "X042C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:66:16:E: "X044D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:67:16:E: "X042D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:68:17:E: "X044E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:69:17:E: "X042E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:70:17:E: "X044F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:71:17:E: "X042F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:72:19:E: "X2116" i= s not a function name jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:6:19:E: "X00E1" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:7:19:E: "X00C1" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:8:18:E: "X00E2" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:9:18:E: "X00C2" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:10:19:E: "X00E0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:11:19:E: "X00C0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:12:18:E: "X00E5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:13:18:E: "X00C5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:14:19:E: "X00E3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:15:19:E: "X00C3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:16:17:E: "X00E4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:17:17:E: "X00C4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:18:18:E: "X00E6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:19:18:E: "X00C6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:20:19:E: "X00E7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:21:19:E: "X00C7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:22:16:E: "X00F0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:23:16:E: "X00D0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:24:19:E: "X00E9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:25:19:E: "X00C9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:26:18:E: "X00EA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:27:18:E: "X00CA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:28:19:E: "X00E8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:29:19:E: "X00C8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:30:17:E: "X00EB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:31:17:E: "X00CB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:32:19:E: "X00ED" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:33:19:E: "X00CD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:34:18:E: "X00EE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:35:18:E: "X00CE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:36:19:E: "X00EC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:37:19:E: "X00CC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:38:17:E: "X00EF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:39:17:E: "X00CF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:40:19:E: "X00F1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:41:19:E: "X00D1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:42:19:E: "X00F3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:43:19:E: "X00D3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:44:18:E: "X00F4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:45:18:E: "X00D4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:46:19:E: "X00F2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:47:19:E: "X00D2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:48:19:E: "X00F8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:49:19:E: "X00D8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:50:19:E: "X00F5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:51:19:E: "X00D5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:52:17:E: "X00F6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:53:17:E: "X00D6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:54:18:E: "X00DF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:55:18:E: "X00FE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:56:18:E: "X00DE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:57:19:E: "X00FA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:58:19:E: "X00DA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:59:18:E: "X00FB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:60:18:E: "X00DB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:61:19:E: "X00F9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:62:19:E: "X00D9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:63:17:E: "X00FC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:64:17:E: "X00DC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:65:19:E: "X00FD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:66:19:E: "X00DD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:67:17:E: "X00FF" i= s not a function name jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:6:19:E: "X00E1" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:7:19:E: "X00C1" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:8:18:E: "X00E2" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:9:18:E: "X00C2" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:10:19:E: "X00E0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:11:19:E: "X00C0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:12:18:E: "X00E5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:13:18:E: "X00C5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:14:19:E: "X00E3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:15:19:E: "X00C3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:16:17:E: "X00E4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:17:17:E: "X00C4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:18:18:E: "X00E6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:19:18:E: "X00C6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:20:19:E: "X00E7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:21:19:E: "X00C7" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:22:16:E: "X00F0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:23:16:E: "X00D0" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:24:19:E: "X00E9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:25:19:E: "X00C9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:26:18:E: "X00EA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:27:18:E: "X00CA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:28:19:E: "X00E8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:29:19:E: "X00C8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:30:17:E: "X00EB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:31:17:E: "X00CB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:32:19:E: "X00ED" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:33:19:E: "X00CD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:34:18:E: "X00EE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:35:18:E: "X00CE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:36:19:E: "X00EC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:37:19:E: "X00CC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:38:17:E: "X00EF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:39:17:E: "X00CF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:40:19:E: "X00F1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:41:19:E: "X00D1" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:42:19:E: "X00F3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:43:19:E: "X00D3" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:44:18:E: "X00F4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:45:18:E: "X00D4" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:46:19:E: "X00F2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:47:19:E: "X00D2" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:48:19:E: "X00F8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:49:19:E: "X00D8" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:50:19:E: "X00F5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:51:19:E: "X00D5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:52:17:E: "X00F6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:53:17:E: "X00D6" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:54:18:E: "X00DF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:55:18:E: "X00FE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:56:18:E: "X00DE" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:57:19:E: "X00FA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:58:19:E: "X00DA" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:59:18:E: "X00FB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:60:18:E: "X00DB" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:61:19:E: "X00F9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:62:19:E: "X00D9" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:63:17:E: "X00FC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:64:17:E: "X00DC" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:65:19:E: "X00FD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:66:19:E: "X00DD" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat1.ent:67:17:E: "X00FF" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:6:19:E: "X0103" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:7:19:E: "X0102" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:8:18:E: "X0101" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:9:18:E: "X0100" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:10:18:E: "X0105" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:11:18:E: "X0104" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:12:19:E: "X0107" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:13:19:E: "X0106" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:14:19:E: "X010D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:15:19:E: "X010C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:16:18:E: "X0109" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:17:18:E: "X0108" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:18:17:E: "X010B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:19:17:E: "X010A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:20:19:E: "X010F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:21:19:E: "X010E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:22:19:E: "X0111" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:23:19:E: "X0110" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:24:19:E: "X011B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:25:19:E: "X011A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:26:17:E: "X0117" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:27:17:E: "X0116" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:28:18:E: "X0113" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:29:18:E: "X0112" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:30:18:E: "X0119" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:31:18:E: "X0118" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:32:19:E: "X01F5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:33:19:E: "X011F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:34:19:E: "X011E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:35:19:E: "X0122" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:36:18:E: "X011D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:37:18:E: "X011C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:38:17:E: "X0121" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:39:17:E: "X0120" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:40:18:E: "X0125" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:41:18:E: "X0124" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:42:19:E: "X0127" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:43:19:E: "X0126" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:44:17:E: "X0130" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:45:18:E: "X012A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:46:18:E: "X012B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:47:18:E: "X0133" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:48:18:E: "X0132" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:49:19:E: "X0131" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:50:18:E: "X012F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:51:18:E: "X012E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:52:19:E: "X0129" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:53:19:E: "X0128" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:54:18:E: "X0135" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:55:18:E: "X0134" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:56:19:E: "X0137" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:57:19:E: "X0136" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:58:19:E: "X0138" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:59:19:E: "X013A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:60:19:E: "X0139" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:61:19:E: "X013E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:62:19:E: "X013D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:63:19:E: "X013C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:64:19:E: "X013B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:65:19:E: "X0140" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:66:19:E: "X013F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:67:19:E: "X0142" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:68:19:E: "X0141" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:69:19:E: "X0144" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:70:19:E: "X0143" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:71:16:E: "X014B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:72:16:E: "X014A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:73:18:E: "X0149" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:74:19:E: "X0148" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:75:19:E: "X0147" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:76:19:E: "X0146" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:77:19:E: "X0145" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:78:19:E: "X0151" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:79:19:E: "X0150" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:80:18:E: "X014C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:81:18:E: "X014D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:82:18:E: "X0153" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:83:18:E: "X0152" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:84:19:E: "X0155" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:85:19:E: "X0154" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:86:19:E: "X0159" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:87:19:E: "X0158" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:88:19:E: "X0157" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:89:19:E: "X0156" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:90:19:E: "X015B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:91:19:E: "X015A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:92:19:E: "X0161" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:93:19:E: "X0160" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:94:19:E: "X015F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:95:19:E: "X015E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:96:18:E: "X015D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:97:18:E: "X015C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:98:19:E: "X0165" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:99:19:E: "X0164" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:100:19:E: "X0163" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:101:19:E: "X0162" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:102:19:E: "X0167" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:103:19:E: "X0166" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:104:19:E: "X016D" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:105:19:E: "X016C" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:106:19:E: "X0171" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:107:19:E: "X0170" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:108:18:E: "X016B" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:109:18:E: "X016A" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:110:18:E: "X0173" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:111:18:E: "X0172" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:112:18:E: "X016F" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:113:18:E: "X016E" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:114:19:E: "X0169" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:115:19:E: "X0168" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:116:18:E: "X0175" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:117:18:E: "X0174" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:118:18:E: "X0177" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:119:18:E: "X0176" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:120:17:E: "X0178" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:121:19:E: "X017A" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:122:19:E: "X0179" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:123:19:E: "X017E" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:124:19:E: "X017D" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:125:17:E: "X017C" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:126:17:E: "X017B" = is not a function name jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:6:16:E: "X0430" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:7:16:E: "X0410" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:8:16:E: "X0431" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:9:16:E: "X0411" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:10:16:E: "X0432" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:11:16:E: "X0412" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:12:16:E: "X0433" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:13:16:E: "X0413" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:14:16:E: "X0434" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:15:16:E: "X0414" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:16:17:E: "X0435" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:17:17:E: "X0415" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:18:17:E: "X0451" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:19:17:E: "X0401" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:20:17:E: "X0436" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:21:17:E: "X0416" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:22:16:E: "X0437" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:23:16:E: "X0417" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:24:16:E: "X0438" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:25:16:E: "X0418" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:26:16:E: "X0439" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:27:16:E: "X0419" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:28:16:E: "X043A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:29:16:E: "X041A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:30:16:E: "X043B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:31:16:E: "X041B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:32:16:E: "X043C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:33:16:E: "X041C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:34:16:E: "X043D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:35:16:E: "X041D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:36:16:E: "X043E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:37:16:E: "X041E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:38:16:E: "X043F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:39:16:E: "X041F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:40:16:E: "X0440" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:41:16:E: "X0420" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:42:16:E: "X0441" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:43:16:E: "X0421" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:44:16:E: "X0442" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:45:16:E: "X0422" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:46:16:E: "X0443" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:47:16:E: "X0423" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:48:16:E: "X0444" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:49:16:E: "X0424" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:50:17:E: "X0445" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:51:17:E: "X0425" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:52:17:E: "X0446" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:53:17:E: "X0426" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:54:17:E: "X0447" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:55:17:E: "X0427" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:56:17:E: "X0448" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:57:17:E: "X0428" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:58:19:E: "X0449" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:59:19:E: "X0429" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:60:19:E: "X044A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:61:19:E: "X042A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:62:16:E: "X044B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:63:16:E: "X042B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:64:19:E: "X044C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:65:19:E: "X042C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:66:16:E: "X044D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:67:16:E: "X042D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:68:17:E: "X044E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:69:17:E: "X042E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:70:17:E: "X044F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:71:17:E: "X042F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-cyr1.ent:72:19:E: "X2116" i= s not a function name jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:6:19:E: "X0103" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:7:19:E: "X0102" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:8:18:E: "X0101" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:9:18:E: "X0100" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:10:18:E: "X0105" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:11:18:E: "X0104" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:12:19:E: "X0107" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:13:19:E: "X0106" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:14:19:E: "X010D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:15:19:E: "X010C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:16:18:E: "X0109" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:17:18:E: "X0108" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:18:17:E: "X010B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:19:17:E: "X010A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:20:19:E: "X010F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:21:19:E: "X010E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:22:19:E: "X0111" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:23:19:E: "X0110" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:24:19:E: "X011B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:25:19:E: "X011A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:26:17:E: "X0117" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:27:17:E: "X0116" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:28:18:E: "X0113" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:29:18:E: "X0112" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:30:18:E: "X0119" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:31:18:E: "X0118" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:32:19:E: "X01F5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:33:19:E: "X011F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:34:19:E: "X011E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:35:19:E: "X0122" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:36:18:E: "X011D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:37:18:E: "X011C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:38:17:E: "X0121" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:39:17:E: "X0120" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:40:18:E: "X0125" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:41:18:E: "X0124" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:42:19:E: "X0127" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:43:19:E: "X0126" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:44:17:E: "X0130" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:45:18:E: "X012A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:46:18:E: "X012B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:47:18:E: "X0133" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:48:18:E: "X0132" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:49:19:E: "X0131" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:50:18:E: "X012F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:51:18:E: "X012E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:52:19:E: "X0129" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:53:19:E: "X0128" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:54:18:E: "X0135" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:55:18:E: "X0134" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:56:19:E: "X0137" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:57:19:E: "X0136" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:58:19:E: "X0138" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:59:19:E: "X013A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:60:19:E: "X0139" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:61:19:E: "X013E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:62:19:E: "X013D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:63:19:E: "X013C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:64:19:E: "X013B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:65:19:E: "X0140" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:66:19:E: "X013F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:67:19:E: "X0142" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:68:19:E: "X0141" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:69:19:E: "X0144" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:70:19:E: "X0143" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:71:16:E: "X014B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:72:16:E: "X014A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:73:18:E: "X0149" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:74:19:E: "X0148" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:75:19:E: "X0147" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:76:19:E: "X0146" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:77:19:E: "X0145" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:78:19:E: "X0151" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:79:19:E: "X0150" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:80:18:E: "X014C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:81:18:E: "X014D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:82:18:E: "X0153" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:83:18:E: "X0152" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:84:19:E: "X0155" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:85:19:E: "X0154" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:86:19:E: "X0159" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:87:19:E: "X0158" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:88:19:E: "X0157" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:89:19:E: "X0156" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:90:19:E: "X015B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:91:19:E: "X015A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:92:19:E: "X0161" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:93:19:E: "X0160" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:94:19:E: "X015F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:95:19:E: "X015E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:96:18:E: "X015D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:97:18:E: "X015C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:98:19:E: "X0165" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:99:19:E: "X0164" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:100:19:E: "X0163" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:101:19:E: "X0162" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:102:19:E: "X0167" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:103:19:E: "X0166" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:104:19:E: "X016D" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:105:19:E: "X016C" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:106:19:E: "X0171" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:107:19:E: "X0170" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:108:18:E: "X016B" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:109:18:E: "X016A" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:110:18:E: "X0173" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:111:18:E: "X0172" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:112:18:E: "X016F" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:113:18:E: "X016E" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:114:19:E: "X0169" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:115:19:E: "X0168" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:116:18:E: "X0175" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:117:18:E: "X0174" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:118:18:E: "X0177" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:119:18:E: "X0176" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:120:17:E: "X0178" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:121:19:E: "X017A" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:122:19:E: "X0179" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:123:19:E: "X017E" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:124:19:E: "X017D" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:125:17:E: "X017C" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:126:17:E: "X017B" = is not a function name jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:6:19:E: "X0103" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:7:19:E: "X0102" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:8:18:E: "X0101" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:9:18:E: "X0100" is= not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:10:18:E: "X0105" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:11:18:E: "X0104" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:12:19:E: "X0107" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:13:19:E: "X0106" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:14:19:E: "X010D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:15:19:E: "X010C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:16:18:E: "X0109" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:17:18:E: "X0108" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:18:17:E: "X010B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:19:17:E: "X010A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:20:19:E: "X010F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:21:19:E: "X010E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:22:19:E: "X0111" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:23:19:E: "X0110" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:24:19:E: "X011B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:25:19:E: "X011A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:26:17:E: "X0117" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:27:17:E: "X0116" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:28:18:E: "X0113" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:29:18:E: "X0112" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:30:18:E: "X0119" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:31:18:E: "X0118" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:32:19:E: "X01F5" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:33:19:E: "X011F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:34:19:E: "X011E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:35:19:E: "X0122" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:36:18:E: "X011D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:37:18:E: "X011C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:38:17:E: "X0121" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:39:17:E: "X0120" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:40:18:E: "X0125" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:41:18:E: "X0124" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:42:19:E: "X0127" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:43:19:E: "X0126" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:44:17:E: "X0130" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:45:18:E: "X012A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:46:18:E: "X012B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:47:18:E: "X0133" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:48:18:E: "X0132" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:49:19:E: "X0131" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:50:18:E: "X012F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:51:18:E: "X012E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:52:19:E: "X0129" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:53:19:E: "X0128" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:54:18:E: "X0135" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:55:18:E: "X0134" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:56:19:E: "X0137" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:57:19:E: "X0136" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:58:19:E: "X0138" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:59:19:E: "X013A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:60:19:E: "X0139" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:61:19:E: "X013E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:62:19:E: "X013D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:63:19:E: "X013C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:64:19:E: "X013B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:65:19:E: "X0140" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:66:19:E: "X013F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:67:19:E: "X0142" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:68:19:E: "X0141" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:69:19:E: "X0144" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:70:19:E: "X0143" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:71:16:E: "X014B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:72:16:E: "X014A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:73:18:E: "X0149" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:74:19:E: "X0148" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:75:19:E: "X0147" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:76:19:E: "X0146" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:77:19:E: "X0145" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:78:19:E: "X0151" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:79:19:E: "X0150" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:80:18:E: "X014C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:81:18:E: "X014D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:82:18:E: "X0153" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:83:18:E: "X0152" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:84:19:E: "X0155" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:85:19:E: "X0154" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:86:19:E: "X0159" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:87:19:E: "X0158" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:88:19:E: "X0157" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:89:19:E: "X0156" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:90:19:E: "X015B" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:91:19:E: "X015A" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:92:19:E: "X0161" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:93:19:E: "X0160" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:94:19:E: "X015F" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:95:19:E: "X015E" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:96:18:E: "X015D" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:97:18:E: "X015C" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:98:19:E: "X0165" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:99:19:E: "X0164" i= s not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:100:19:E: "X0163" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:101:19:E: "X0162" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:102:19:E: "X0167" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:103:19:E: "X0166" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:104:19:E: "X016D" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:105:19:E: "X016C" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:106:19:E: "X0171" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:107:19:E: "X0170" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:108:18:E: "X016B" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:109:18:E: "X016A" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:110:18:E: "X0173" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:111:18:E: "X0172" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:112:18:E: "X016F" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:113:18:E: "X016E" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:114:19:E: "X0169" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:115:19:E: "X0168" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:116:18:E: "X0175" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:117:18:E: "X0174" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:118:18:E: "X0177" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:119:18:E: "X0176" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:120:17:E: "X0178" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:121:19:E: "X017A" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:122:19:E: "X0179" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:123:19:E: "X017E" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:124:19:E: "X017D" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:125:17:E: "X017C" = is not a function name jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-lat2.ent:126:17:E: "X017B" = is not a function name jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local/sha= re/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) gmake[2]: *** [api.html] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook= =2Dutils-0.6.14/doc/HTML' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/textproc/docbook-utils/work/docbook= =2Dutils-0.6.14/doc' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/ports/textproc/docbook-utils. doroot@smadev:/usr/ports/textproc/docbook-utils# ^D =20 Script done on Wed Feb 20 10:38:21 2008 =2D-=20 Achilleas Mantzios KOSOVO IS SERBIA FOR EVER From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:27:15 2008 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 131E416A400; Wed, 20 Feb 2008 15:27:15 +0000 (UTC) (envelope-from mythtv@logic-q.nl) Received: from viefep23-int.chello.at (viefep18-int.chello.at [213.46.255.22]) by mx1.freebsd.org (Postfix) with ESMTP id 28F4E13C43E; Wed, 20 Feb 2008 15:27:13 +0000 (UTC) (envelope-from mythtv@logic-q.nl) Received: from mail.logic-q.nl ([77.249.130.138]) by viefep31-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080220151039.UHGP21497.viefep31-int.chello.at@mail.logic-q.nl>; Wed, 20 Feb 2008 16:10:39 +0100 Received: from localhost (localhost.logic-q.nl [127.0.0.1]) by mail.logic-q.nl (Postfix) with ESMTP id 3D02F176A5; Wed, 20 Feb 2008 16:10:37 +0100 (CET) X-Virus-Scanned: amavisd-new at logic-q.nl Received: from mail.logic-q.nl ([127.0.0.1]) by localhost (mail.logic-q.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2+s7rWIxRH7; Wed, 20 Feb 2008 16:10:34 +0100 (CET) Received: from kotsbak (kotsbak.logic-q.loc [192.168.0.199]) by mail.logic-q.nl (Postfix) with SMTP id 3F96217694; Wed, 20 Feb 2008 16:10:34 +0100 (CET) From: "Hansa" To: , Date: Wed, 20 Feb 2008 16:10:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: Subject: Upgrading from FreeBSD 6.2 to FreeBSD 7.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, 20 Feb 2008 15:27:15 -0000 Hi, On a test system, I'm trying to upgrade FreeBSD 6.2 to 7.0 using the instructions from Ralf Engelschall. http://people.freebsd.org/~rse/upgrade/freebsd-upgrade-6x-7x.txt I'm stuck at compiling the new kernel. Here are the steps I took: - install backward compatibility files localedata-5.4.tbz compat6x-i386-6.x.xxxxxx.yyyymm.tbz from: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7-current/All also tried upgrading with the files from: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7.0-release/All Same result however - install latest FreeBSD Upgrade Toolkit http://people.freebsd.org/~rse/dist/freebsd-adm-1.2.2.tar.gz - upgrade /usr/src $ cd /usr/src && make cleandir reports an error if there is nothing to clean $ cd /usr/adm && make update runs just fine. - upgrade kernel configuration I've added/checked if the options with ">>" in rse's howto are in /sys/i386/conf/GENERIC (or in my case 'hostname -s' /sys/i386/conf/TESTRABIT) I've removed/checked that the options with "<<" are not in TESTRABIT - prepare the upgrade $ mergemaster -p - build new system $ cd /usr/adm && make world-build runs without problems $ make kernel-build ==== PROBS ==== Building kernel+modules (TESTRABIT) -------------------------------------------------------------- >>> Kernel build for TESTRABIT started on Wed Feb 20 16:03:46 CET 2008 -------------------------------------------------------------- ===> TESTRABIT mkdir -p /usr/obj/usr/src/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bi n:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/o bj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/ usr/bin config -d /usr/obj/usr/src/sys/TESTRABIT /usr/src/sys/i386/conf/TESTRABIT /usr/src/sys/i386/conf/TESTRABIT: unknown option "IPSEC_ESP" *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. kernel build duration: 00:00:00 ==== STUCK ==== My guess is that the ipsec (crypto?) source code is missing? Is this correct? If so, where can I find it and where should I put it? Best regards, Hansa From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:34:21 2008 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 DC96016A404; Wed, 20 Feb 2008 15:34:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 999FF13C455; Wed, 20 Feb 2008 15:34:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1KFYJXY033296; Wed, 20 Feb 2008 10:34:20 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m1KFYJfx016149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 10:34:19 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802201534.m1KFYJfx016149@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Feb 2008 10:34:19 -0500 To: "Hansa" , , From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Upgrading from FreeBSD 6.2 to FreeBSD 7.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, 20 Feb 2008 15:34:22 -0000 At 10:10 AM 2/20/2008, Hansa wrote: >/usr/src/sys/i386/conf/TESTRABIT: unknown option "IPSEC_ESP" >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. >kernel build duration: 00:00:00 >==== STUCK ==== > >My guess is that the ipsec (crypto?) source code is missing? Is this >correct? If so, where can I find it and where should I put it? Hi, The options for IPSEC are different in RELENG_7. The KAME implementation is no longer there as its just FAST_IPSEC. So get rid of IPSEC_ESP and just have options IPSEC device crypto in your kernel. ---Mike From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:36:36 2008 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 DC37716A419; Wed, 20 Feb 2008 15:36:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A08B13C45D; Wed, 20 Feb 2008 15:36:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1KFaYR4092986; Wed, 20 Feb 2008 16:36:34 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1KFaY1C092985; Wed, 20 Feb 2008 16:36:34 +0100 (CET) (envelope-from olli) Date: Wed, 20 Feb 2008 16:36:34 +0100 (CET) Message-Id: <200802201536.m1KFaY1C092985@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, mythtv@logic-q.nl In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 20 Feb 2008 16:36:35 +0100 (CET) Cc: Subject: Re: Upgrading from FreeBSD 6.2 to FreeBSD 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-questions@FreeBSD.ORG, mythtv@logic-q.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:36:37 -0000 Crossposting to -current and -questions is usually not a good idea. This question belongs to -questions only. Hansa wrote: > On a test system, I'm trying to upgrade FreeBSD 6.2 to 7.0 using the > instructions from Ralf Engelschall. > http://people.freebsd.org/~rse/upgrade/freebsd-upgrade-6x-7x.txt > I'm stuck at compiling the new kernel. > [...] > /usr/src/sys/i386/conf/TESTRABIT: unknown option "IPSEC_ESP" The option IPSEC_ESP was removed when KAME was replaced with the FAST_IPSEC implementation. Please remove that line from your kernel config file. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I learned Java 3 years before Python. It was my language of choice. It took me two weekends with Python before I was more productive with it than with Java." -- Anthony Roberts From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:50:40 2008 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 1C84616A40E for ; Wed, 20 Feb 2008 15:50:40 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C2C3313C4EA for ; Wed, 20 Feb 2008 15:50:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRrDN-0001nm-F2 for freebsd-current@freebsd.org; Wed, 20 Feb 2008 15:50:35 +0000 Received: from dhcp100.ifado.de ([195.253.22.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2008 15:50:33 +0000 Received: from wb by dhcp100.ifado.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2008 15:50:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Wilhelm B. Kloke" Date: Wed, 20 Feb 2008 15:50:24 +0000 (UTC) Organization: InstArbPhysUniDo Lines: 21 Message-ID: References: <47BADE07.9020402@gmx.de> <20080219180227.GC73371@dracon.ht-systems.ru> <47BC0D9A.1070201@vwsoft.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp100.ifado.de User-Agent: slrn/0.9.8.1 (FreeBSD) Cache-Post-Path: vestein.arb-phys.uni-dortmund.de!unknown@localhost X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Sender: news Subject: Re: mount order, Was: nfs mounts don't work through fstab 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, 20 Feb 2008 15:50:40 -0000 Eygene Ryabinkin schrieb: > Wilhelm, Volker, good day. > > Wed, Feb 20, 2008 at 12:23:06PM +0100, Volker wrote: >> what about the 'late' option? > > 'late' option should also work: it permits per-mountpoint control. > What to choose is up to you: if you want to delay only the specified > mountpoint, use 'late'. If you want to make all mountpoints of > a known type to be mounted after nfs & others -- use extra_netfs_types. Thanks. The 'late' option seems not to be documented in fstab(5). It looks, as if my error analysis was wrong, again. I missed to really read the error messages. They are about not finding fsck_nfs and fsck_nullfs. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 16:29:25 2008 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 E5E0416A401 for ; Wed, 20 Feb 2008 16:29:25 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF4513C46E for ; Wed, 20 Feb 2008 16:29:25 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=YotZZNmBYvVinGbVQdyPbKNgKE8avjgBrAgQ2/cPgTkvQJHlCWVnzz38L2WWXlNNYJ2n65WgauKAuysKVTcON1FClsLTQ2jqodzLQwsPIoLCrT+z7BUr2f5cl90jq7Lej29FMbJBS5ES+zA4E2aJ8fdrjCVXjxg8bREMaSud/Ak=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRroy-000CVb-0s; Wed, 20 Feb 2008 19:29:24 +0300 Date: Wed, 20 Feb 2008 19:29:22 +0300 From: Eygene Ryabinkin To: "Wilhelm B. Kloke" Message-ID: References: <47BADE07.9020402@gmx.de> <20080219180227.GC73371@dracon.ht-systems.ru> <47BC0D9A.1070201@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-current@freebsd.org Subject: Re: mount order, Was: nfs mounts don't work through fstab 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, 20 Feb 2008 16:29:26 -0000 Wilhelm, Wed, Feb 20, 2008 at 03:50:24PM +0000, Wilhelm B. Kloke wrote: > > 'late' option should also work: it permits per-mountpoint control. > > What to choose is up to you: if you want to delay only the specified > > mountpoint, use 'late'. If you want to make all mountpoints of > > a known type to be mounted after nfs & others -- use extra_netfs_types. > > Thanks. The 'late' option seems not to be documented in fstab(5). But it is in the mount(8) manual. > It looks, as if my error analysis was wrong, again. I missed to > really read the error messages. They are about not finding fsck_nfs > and fsck_nullfs. Then you have non-null pass number for these filesystems in your fstab? If so, why? You should not check them -- they are not fsck'able (sorry for the rude word ;)). -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 15:54:46 2008 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 1D85316A403 for ; Wed, 20 Feb 2008 15:54:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id A9D9613C46B for ; Wed, 20 Feb 2008 15:54:45 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2223899wri.3 for ; Wed, 20 Feb 2008 07:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:from; bh=m3NznsaYK+rJGimXcjFqmuit6KPD+XrlFlT+rb/XhS0=; b=AkZq7TUR/dbRNNtqUSQh/WUb6EqNKfk4gEx3zYpBQMy64d7LhWJEIeKBvvmEjG+AqhRAaagfjxXcotC/WdQNRHBdPaNYLPXzXUpLINe2SzzcDQk7HzCipHS92d8QjOqDJ+PvKkgDwlCX9tAg7Qj3c6hOK/zKI7Xmevg5q6ciouY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:from; b=VAfgggEZpbMbb37BHGKiV0Tb5KWUIbYqX3hizq4YOs6TgmR7KE8FIbfD3F4KA6eJ1e+oZh6+tHb0fjBtv/lfQB6pxqGk68PFCSXXPY0pDb42fnTf9DgRlR4khxj38Qv0uzwffJbXYxIZVRBs5xlhyZh0cQJAd1arXrHhH08DRCE= Received: by 10.114.93.17 with SMTP id q17mr2747368wab.70.1203521165039; Wed, 20 Feb 2008 07:26:05 -0800 (PST) Received: from ?10.0.0.19? ( [71.92.133.50]) by mx.google.com with ESMTPS id q18sm19882426pog.12.2008.02.20.07.26.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 07:26:02 -0800 (PST) Message-Id: To: Achilleas Mantzios In-Reply-To: <200802201547.17360.achill@matrix.gatewaynet.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 07:26:31 -0800 References: <200802201111.16340.achill@matrix.gatewaynet.com> <200802201547.17360.achill@matrix.gatewaynet.com> X-Mailer: Apple Mail (2.919.2) From: Garrett Cooper X-Mailman-Approved-At: Wed, 20 Feb 2008 16:40:50 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Problem with various ports 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, 20 Feb 2008 15:54:46 -0000 On Feb 20, 2008, at 5:47 AM, Achilleas Mantzios wrote: > =CE=A3=CF=84=CE=B9=CF=82 Wednesday 20 February 2008 15:39:41 =CE=BF/=CE=B7= Eygene Ryabinkin =20 > =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5: >> Achilleas, good day. >> >> Wed, Feb 20, 2008 at 11:11:15AM +0200, Achilleas Mantzios wrote: >>> I had trouble building textproc/docbook-utils (docbook-=20 >>> utils-0.6.14_3) in a fresh new >>> 7.0-RC2 FreeBSD 7.0-RC2 #5 >>> the problem starts at the begining of config: >>> >>> >>> configure.in:4: warning: underquoted definition of AC_FIND_PROGRAM^M >>> run info '(automake)Extending aclocal'^M >>> or see = http://sources.redhat.com/automake/automake.html#Extending%20aclocal=20 >>> ^M >>> /usr/local/share/aclocal/linc.m4:1: warning: underquoted =20 >>> definition of AM_PATH_LINC^M >>> /usr/local/share/aclocal/libfame.m4:6: warning: underquoted =20 >>> definition of AM_PATH_LIBFAME^M >>> /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted =20 >>> definition of AM_PATH_AUDIOFILE^M >>> /usr/local/share/aclocal/aalib.m4:12: warning: underquoted =20 >>> definition of AM_PATH_AALIB^M >> >> And what is the trouble? The port builds, isn't it? 'configure.in' >> uses old syntax for AC_DEFUN and there are some other underquoteds, >> but it seems not to hurt anyone. >> >> The real problem is that file 'aclocal.m4' has rather distant >> timestamp (year 2004), so the Makefile and configure are rebuilt. >> But the port builds for me at 7.0-PRERELEASE though I have the >> warning messages as you. >> >> Or it does not build for you? > > Hi Eygene, thanx for contacting. > The below build, later complains about not existing /usr/local/share/=20= > xml/sdocbook/4.1.2.5/catalog, > creating it by hand just reincarnated the problem. > here is the whole original output: > > Script started on Wed Feb 20 10:38:03 2008 > doroot@smadev:/usr/ports/textproc/docbook-utils# make When was the last time you've rebuilt your ports? I think Alex =20= Leidinger or Mark Linimon did a fully encompassing restructure with =20 the autotools, but that was some months ago (July? August?). Cheers, -Garrett= From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 16:05:14 2008 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 E368516A400 for ; Wed, 20 Feb 2008 16:05:14 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 56EC713C442 for ; Wed, 20 Feb 2008 16:05:14 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so2075200mue.6 for ; Wed, 20 Feb 2008 08:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=L1bZdkxokXgERXxkvMkj/D3f7YfPajTaiLBUwRO1/cQ=; b=H7SGJMbHRgaUS5gpgXBsCjCqnlG7J+v60FfPUX/WDrSp6LufABXJUAIRsOlAGmsr7JPg6NKofqdB52la9zS+tmEo8lTqujkE1DCNmB7sSo7y21wRad1NrTqPJORo0Xh9oEbCGwi4m7NCmYN/jeFnqoVNxZb3aNPsU2A8SFkQ5rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=ruFE1X6uiaNfwn0GfShAdWqhFyaAGBYdxoSsLi/0hXa8y5q7rkC+31+AVfV9NthcA2iLJOBkVQeM3ya8MBotxQTuH+/CyxY3dY8+kcpNZikb1SY+bzg4Ecc6+L432o/IoJEfW9e7YFF5qOtlmoU58u7LXhG40JySx0ndukwVXdo= Received: by 10.78.134.2 with SMTP id h2mr13675492hud.17.1203523512988; Wed, 20 Feb 2008 08:05:12 -0800 (PST) Received: from Epsilon.local ( [193.126.196.169]) by mx.google.com with ESMTPS id i3sm19440975nfh.28.2008.02.20.08.05.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 08:05:12 -0800 (PST) Message-Id: From: Rui Paulo To: Anton Yuzhaninov In-Reply-To: <47BC2AAB.5090605@citrin.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 16:05:07 +0000 References: <47BB4E5D.7010505@citrin.ru> <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> <47BC2AAB.5090605@citrin.ru> X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo X-Mailman-Approved-At: Wed, 20 Feb 2008 16:46:30 +0000 Cc: freebsd-current@freebsd.org, re@freebsd.org Subject: Re: tcsh in current-8.0 coredump 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, 20 Feb 2008 16:05:15 -0000 On Feb 20, 2008, at 1:27 PM, Anton Yuzhaninov wrote: > On 20.02.2008 4:56, Rui Paulo wrote: >> On Feb 19, 2008, at 9:47 PM, Anton Yuzhaninov wrote: >>> Problem was described here: >>> http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 >>> http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html >>> >>> This was fixed for RELENG_7: >>> >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c >>> Revision 1.1.1.8 (vendor branch): download - view: text, markup, >>> annotated - select for diffs >>> Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp >>> Branches: ZOULAS, MAIN >>> CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, >>> RELENG_7 >>> Diff to: previous 1.1.1.7: preferred, colored >>> Changes since revision 1.1.1.7: +2 -1 lines >>> >>> Import vendor patch to fix postcmd regression in tcsh-6.15.00. >>> ------- >>> >>> But this bug was not fixed in HEAD. >>> >> Are you sure? I seem to recall this was fixed even before RELENG_7 >> was tagged. > > $ cvs up > $ cvs diff -r HEAD -r RELENG_7 contrib/tcsh/sh.lex.c > Index: contrib/tcsh/sh.lex.c > =================================================================== > RCS file: /home/ncvs/src/contrib/tcsh/sh.lex.c,v > retrieving revision 1.1.1.9 > retrieving revision 1.1.1.8 > diff -u -r1.1.1.9 -r1.1.1.8 > --- contrib/tcsh/sh.lex.c 15 Oct 2007 16:54:07 -0000 > 1.1.1.9 > +++ contrib/tcsh/sh.lex.c 3 Apr 2007 15:51:53 -0000 > 1.1.1.8 > @@ -851,7 +851,8 @@ > return (en); > } > slhs.len = 0; > - Strbuf_append(&slhs, lhsb.s); > + if (lhsb.s != NULL && lhsb.len != 0) > + Strbuf_append(&slhs, lhsb.s); > Strbuf_terminate(&slhs); > if (exclc) > en = dosub(sc, en, global); > > As you can see from cvs diff, null pointer check present in > RELENG_7. but absent in HEAD Oh, you are right. This was never MFC'ed, but the log says: revision 1.1.1.9 date: 2007/10/15 16:54:07; author: mp; state: Exp; lines: +1 -2 Import two vendor fixes from tcsh-6.15.01 for MFC to 7.0. The fixes are: - Fix pty detection for autologout setting - kill `foo` got stuck because sigchld was disabled too soon Requested by: re Maybe we should MFC this now. Regards. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 17:57:19 2008 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 37E4716A404 for ; Wed, 20 Feb 2008 17:57:19 +0000 (UTC) (envelope-from mp@FreeBSD.org) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id C899113C459 for ; Wed, 20 Feb 2008 17:57:18 +0000 (UTC) (envelope-from mp@FreeBSD.org) Received: (qmail 66748 invoked by uid 0); 20 Feb 2008 17:30:36 -0000 Received: from unknown (HELO mp.local) (unknown) by unknown with SMTP; 20 Feb 2008 17:30:36 -0000 X-pair-Authenticated: 63.251.108.100 Message-ID: <47BC63BC.4080003@FreeBSD.org> Date: Wed, 20 Feb 2008 09:30:36 -0800 From: Mark Peek User-Agent: Thunderbird 2.0.0.0pre (Macintosh/20070419) MIME-Version: 1.0 To: Rui Paulo References: <47BB4E5D.7010505@citrin.ru> <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> <47BC2AAB.5090605@citrin.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, re@freebsd.org, Anton Yuzhaninov Subject: Re: tcsh in current-8.0 coredump 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, 20 Feb 2008 17:57:19 -0000 On 2/20/08 8:05 AM, Rui Paulo wrote: > > On Feb 20, 2008, at 1:27 PM, Anton Yuzhaninov wrote: > >> On 20.02.2008 4:56, Rui Paulo wrote: >>> On Feb 19, 2008, at 9:47 PM, Anton Yuzhaninov wrote: >>>> Problem was described here: >>>> http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 >>>> http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html >>>> >>>> This was fixed for RELENG_7: >>>> >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c >>>> Revision 1.1.1.8 (vendor branch): download - view: text, markup, >>>> annotated - select for diffs >>>> Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp >>>> Branches: ZOULAS, MAIN >>>> CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, RELENG_7 >>>> Diff to: previous 1.1.1.7: preferred, colored >>>> Changes since revision 1.1.1.7: +2 -1 lines >>>> >>>> Import vendor patch to fix postcmd regression in tcsh-6.15.00. >>>> ------- >>>> >>>> But this bug was not fixed in HEAD. >>>> >>> Are you sure? I seem to recall this was fixed even before RELENG_7 >>> was tagged. >> >> $ cvs up >> $ cvs diff -r HEAD -r RELENG_7 contrib/tcsh/sh.lex.c >> Index: contrib/tcsh/sh.lex.c >> =================================================================== >> RCS file: /home/ncvs/src/contrib/tcsh/sh.lex.c,v >> retrieving revision 1.1.1.9 >> retrieving revision 1.1.1.8 >> diff -u -r1.1.1.9 -r1.1.1.8 >> --- contrib/tcsh/sh.lex.c 15 Oct 2007 16:54:07 -0000 1.1.1.9 >> +++ contrib/tcsh/sh.lex.c 3 Apr 2007 15:51:53 -0000 1.1.1.8 >> @@ -851,7 +851,8 @@ >> return (en); >> } >> slhs.len = 0; >> - Strbuf_append(&slhs, lhsb.s); >> + if (lhsb.s != NULL && lhsb.len != 0) >> + Strbuf_append(&slhs, lhsb.s); >> Strbuf_terminate(&slhs); >> if (exclc) >> en = dosub(sc, en, global); >> >> As you can see from cvs diff, null pointer check present in RELENG_7. >> but absent in HEAD > > Oh, you are right. This was never MFC'ed, but the log says: > > revision 1.1.1.9 > date: 2007/10/15 16:54:07; author: mp; state: Exp; lines: +1 -2 > Import two vendor fixes from tcsh-6.15.01 for MFC to 7.0. The fixes are: > - Fix pty detection for autologout setting > - kill `foo` got stuck because sigchld was disabled too soon > > Requested by: re > > Maybe we should MFC this now. That's really odd. I thought RELENG_7 didn't branch until 10/10/2007 but the postcmd fix was imported on 4/3/2007. In other words, I thought it was already in RELENG_7. But CVS still thinks the two are different. I can MFC it whenever re@ approves it given we're at 7.0-RC2. Mark From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 18:13:00 2008 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 BE6BF16A40B; Wed, 20 Feb 2008 18:13:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9DF13C4E7; Wed, 20 Feb 2008 18:13:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1KIBmo6071609; Wed, 20 Feb 2008 11:11:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 20 Feb 2008 11:11:47 -0700 (MST) Message-Id: <20080220.111147.48474600.imp@bsdimp.com> To: comfooc@gmail.com From: Warner Losh In-Reply-To: <4f38f5cf0802200940w2b558bb1v4ace1c7062887790@mail.gmail.com> References: <4f38f5cf0802200940w2b558bb1v4ace1c7062887790@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: upkhy ed driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 18:13:00 -0000 looks like somebody took out my bogus filter for mii addresses. Grump. Will track this down. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 18:05:45 2008 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 BC4AF16A404 for ; Wed, 20 Feb 2008 18:05:45 +0000 (UTC) (envelope-from comfooc@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0877413C4E1 for ; Wed, 20 Feb 2008 18:05:44 +0000 (UTC) (envelope-from comfooc@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2285267wri.3 for ; Wed, 20 Feb 2008 10:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=FoGPOC+Cj1kRLq6HaiOEeMzYqAxndPvpuGYzg5f3c6w=; b=ekDuOvZj+pJyl0BHPn3BbDCTKh0HGwtABYsJlq7clJMKLS1HZwq+ZESev6CJk5eEAcGTmr7iJLMzmv/tdjNrd2dCcECqJ7QuFzFEWN03sAP48MdLmzbI90moEHzlRAEm5w01xWwXYSyZydiuk6iE7Nz0ipTfc2Ku0ZkQKWA3Dbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fsx1+OQEATsQRIWfcVPfgIwDTPZLMqe8dQJs3S0UP1mmpD9CByqpTjn4T2Xkf+ooSGtN5ZdpgvO+13kYU9kNuq3py3iu85JkhoSaWj6Q/24bNJsyKMpBvhBI+DbpMFQDDb6MpyUHViQna2ge2VeX9g/9llCXJKcmJhZkJh/6tFw= Received: by 10.115.54.1 with SMTP id g1mr5564791wak.133.1203529235049; Wed, 20 Feb 2008 09:40:35 -0800 (PST) Received: by 10.115.111.7 with HTTP; Wed, 20 Feb 2008 09:40:35 -0800 (PST) Message-ID: <4f38f5cf0802200940w2b558bb1v4ace1c7062887790@mail.gmail.com> Date: Wed, 20 Feb 2008 18:40:35 +0100 From: comfooc To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Wed, 20 Feb 2008 18:19:21 +0000 Cc: Subject: upkhy ed driver problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 18:05:45 -0000 Hi, I've problem with upkhy at ed - my pcmcia card don't work. I'm using FreeBSD 8.0-CURRENT-200801 but I noticed issue in 5, 6 and 7 branch. My dmesg: Copyright (c) 1992-2008 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 8.0-CURRENT-200801 #1: Sat Jan 26 18:24:09 UTC 2008 root@:/usr/src/sys/i386/compile/TEST WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (747.70-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 335462400 (319 MB) avail memory = 314515456 (299 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 26 2008 16:08:15) acpi0: on motherboard acpi0: [ITHREAD] acpi0: reservation of 0, 9fc00 (3) failed acpi0: reservation of 100000, 13ef0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xec00-0xecff mem 0xfd000000-0xfdffffff,0xfcfff000-0xfcffffff irq 11 at device 0.0 on pci1 acpi_video0: on vgapci0 drm0: on vgapci0 info: [drm] AGP at 0xf4000000 64MB info: [drm] Initialized mach64 1.0.0 20020904 cbb0: at device 3.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] cbb1: at device 3.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [ITHREAD] isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x860-0x86f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 8.0 (no driver attached) acpi_tz0: on acpi0 acpi_dock0: on acpi0 acpi_dock0: _EJ0 failed atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 747704647 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. pccard0: chip_socket_enable pccard0: read_cis cis mem map 0xce95a000 (resource: 0x88000000) pccard0: CIS tuple chain: CISTPL_DEVICE type=funcspec speed=100ns 01 03 d4 0a ff CISTPL_DEVICE_A type=eeprom speed=250ns 17 03 41 00 ff CISTPL_MANFID 20 04 49 01 ab c1 CISTPL_VERS_1 15 2c 04 01 46 61 73 74 20 45 74 68 65 72 6e 65 74 00 31 36 2d 62 69 74 20 50 43 20 43 61 72 64 00 33 2e 30 00 41 58 38 38 31 39 30 00 ff CISTPL_CONFIG 1a 05 01 fd c0 03 01 CISTPL_CFTABLE_ENTRY 1b 07 fd 81 18 45 30 fc be CISTPL_CFTABLE_ENTRY 1b 07 05 08 ca 60 00 03 1f CISTPL_CFTABLE_ENTRY 1b 07 0d 08 ca 60 20 03 1f CISTPL_CFTABLE_ENTRY 1b 07 15 08 ca 60 40 03 1f CISTPL_CFTABLE_ENTRY 1b 07 1d 08 ca 60 80 03 1f CISTPL_CFTABLE_ENTRY 1b 07 25 08 ca 60 00 02 1f CISTPL_CFTABLE_ENTRY 1b 07 2d 08 ca 60 20 02 1f CISTPL_CFTABLE_ENTRY 1b 07 35 08 ca 60 40 02 1f CISTPL_FUNCID 21 02 06 00 unhandled CISTPL 14 CISTPL_NO_LINK 14 00 CISTPL_END ff pccard0: check_cis_quirks pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Fast Ethernet, 16-bit PC Card, 3.0, AX88190 pccard0: Manufacturer code 0x149, product 0xc1ab pccard0: function 0: network adapter, ccr addr 3c0 mask 1 pccard0: function 0, config table entry 61: I/O card; irq mask befc; iomask 5, iospace 0-1f; mwait_required io16 irqlevel pccard0: function 0, config table entry 5: I/O card; irq mask befc; iomask a, iospace 300-31f; mwait_required io16 irqlevel pccard0: function 0, config table entry 13: I/O card; irq mask befc; iomask a, iospace 320-33f; mwait_required io16 irqlevel pccard0: function 0, config table entry 21: I/O card; irq mask befc; iomask a, iospace 340-35f; mwait_required io16 irqlevel pccard0: function 0, config table entry 29: I/O card; irq mask befc; iomask a, iospace 380-39f; mwait_required io16 irqlevel pccard0: function 0, config table entry 37: I/O card; irq mask befc; iomask a, iospace 200-21f; mwait_required io16 irqlevel pccard0: function 0, config table entry 45: I/O card; irq mask befc; iomask a, iospace 220-23f; mwait_required io16 irqlevel pccard0: function 0, config table entry 53: I/O card; irq mask befc; iomask a, iospace 240-25f; mwait_required io16 irqlevel pccard0: functions scanning pccard0: Card has 1 functions. pccard_mfc is 0 pccard0: I/O rid 0 start 0 end ffffffff pccard0: ccr_res == 88000000-880003ff, base=3c0 pccard0: function 0 CCR at 0 offset 3c0: 7d 0 40 40, 40 2 0 0, 0 ed1: at port 0x100-0x11f irq 11 function 0 config 61 on pccard0 ed1: ccr_write of 0 to 0xa (0x3c0) ed1: ccr_write of 0x1 to 0xc (0x3c0) ed1: ccr_write of 0x4 to 0x2 (0x3c0) ed1: [ITHREAD] ed1: using obsoleted if_watchdog interface ed1: Ethernet address: 00:e0:98:be:42:e6 miibus0: on ed1 ukphy0: PHY 0 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy1: PHY 1 on miibus0 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy2: PHY 2 on miibus0 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy3: PHY 3 on miibus0 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy4: PHY 4 on miibus0 ukphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy5: PHY 5 on miibus0 ukphy5: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy6: PHY 6 on miibus0 ukphy6: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy7: PHY 7 on miibus0 ukphy7: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy8: PHY 8 on miibus0 ukphy8: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy9: PHY 9 on miibus0 ukphy9: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy10: PHY 10 on miibus0 ukphy10: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy11: PHY 11 on miibus0 ukphy11: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy12: PHY 12 on miibus0 ukphy12: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy13: PHY 13 on miibus0 ukphy13: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy14: PHY 14 on miibus0 ukphy14: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy15: PHY 15 on miibus0 ukphy15: 10baseT, 10baseT-FDX, 100baseTX, 100baseT4, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX ukphy16: PHY 16 on miibus0 ukphy16: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pccard0: function 0 CCR at 0 offset 3c0 mask 1: 7d 4 0 0, 0 1 7d 7d, 7d ad0: 57231MB at ata0-master UDMA33 acd0: CDROM at ata1-master UDMA33 WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad0s2 is ext2fs/denatka. GEOM_LABEL: Label for provider ad0s4 is ext2fs//home. Trying to mount root from ufs:/dev/ad0s1a GEOM_LABEL: Label ext2fs//home removed. From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 18:25:29 2008 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 BE37B16A402; Wed, 20 Feb 2008 18:25:29 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 41A4613C442; Wed, 20 Feb 2008 18:25:28 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m1KIP0Lq075577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 13:25:00 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Mark Peek In-Reply-To: <47BC63BC.4080003@FreeBSD.org> References: <47BB4E5D.7010505@citrin.ru> <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> <47BC2AAB.5090605@citrin.ru> <47BC63BC.4080003@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6fEk2p1qMiSAHeVbY0EQ" Organization: U. Buffalo CSE Department Date: Wed, 20 Feb 2008 13:25:00 -0500 Message-Id: <1203531900.99240.16.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=1.8 required=5.0 tests=MIME_QP_LONG_LINE autolearn=no version=3.2.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Rui Paulo , freebsd-current@FreeBSD.org, re@FreeBSD.org, Anton Yuzhaninov Subject: Re: tcsh in current-8.0 coredump 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, 20 Feb 2008 18:25:29 -0000 --=-6fEk2p1qMiSAHeVbY0EQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-02-20 at 09:30 -0800, Mark Peek wrote: > On 2/20/08 8:05 AM, Rui Paulo wrote: > >=20 > > On Feb 20, 2008, at 1:27 PM, Anton Yuzhaninov wrote: > >=20 > >> On 20.02.2008 4:56, Rui Paulo wrote: > >>> On Feb 19, 2008, at 9:47 PM, Anton Yuzhaninov wrote: > >>>> Problem was described here: > >>>> http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 > >>>> http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html > >>>> > >>>> This was fixed for RELENG_7: > >>>> > >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c > >>>> Revision 1.1.1.8 (vendor branch): download - view: text, markup,=20 > >>>> annotated - select for diffs > >>>> Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp > >>>> Branches: ZOULAS, MAIN > >>>> CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, RELEN= G_7 > >>>> Diff to: previous 1.1.1.7: preferred, colored > >>>> Changes since revision 1.1.1.7: +2 -1 lines > >>>> > >>>> Import vendor patch to fix postcmd regression in tcsh-6.15.00. > >>>> ------- > >>>> > >>>> But this bug was not fixed in HEAD. > >>>> > >>> Are you sure? I seem to recall this was fixed even before RELENG_7=20 > >>> was tagged. > >> > >> $ cvs up > >> $ cvs diff -r HEAD -r RELENG_7 contrib/tcsh/sh.lex.c > >> Index: contrib/tcsh/sh.lex.c > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> RCS file: /home/ncvs/src/contrib/tcsh/sh.lex.c,v > >> retrieving revision 1.1.1.9 > >> retrieving revision 1.1.1.8 > >> diff -u -r1.1.1.9 -r1.1.1.8 > >> --- contrib/tcsh/sh.lex.c 15 Oct 2007 16:54:07 -0000 1.1.1.= 9 > >> +++ contrib/tcsh/sh.lex.c 3 Apr 2007 15:51:53 -0000 1.1.1.= 8 > >> @@ -851,7 +851,8 @@ > >> return (en); > >> } > >> slhs.len =3D 0; > >> - Strbuf_append(&slhs, lhsb.s); > >> + if (lhsb.s !=3D NULL && lhsb.len !=3D 0) > >> + Strbuf_append(&slhs, lhsb.s); > >> Strbuf_terminate(&slhs); > >> if (exclc) > >> en =3D dosub(sc, en, global); > >> > >> As you can see from cvs diff, null pointer check present in RELENG_7.=20 > >> but absent in HEAD > >=20 > > Oh, you are right. This was never MFC'ed, but the log says: > >=20 > > revision 1.1.1.9 > > date: 2007/10/15 16:54:07; author: mp; state: Exp; lines: +1 -2 > > Import two vendor fixes from tcsh-6.15.01 for MFC to 7.0. The fixes are= : > > - Fix pty detection for autologout setting > > - kill `foo` got stuck because sigchld was disabled too soon > >=20 > > Requested by: re > >=20 > > Maybe we should MFC this now. >=20 > That's really odd. I thought RELENG_7 didn't branch until 10/10/2007 but = the=20 > postcmd fix was imported on 4/3/2007. In other words, I thought it was al= ready=20 > in RELENG_7. But CVS still thinks the two are different. I can MFC it whe= never=20 > re@ approves it given we're at 7.0-RC2. >=20 > Mark I *think* the original message above has it correct and you (Mark and Rui) have it reversed. Mark, I think when re@ requested this you might have done the commit straight to RELENG_7 and didn't do HEAD. So as things stand right now this is what's in RELENG_7 and RELENG_7_0: slhs.len =3D 0; if (lhsb.s !=3D NULL && lhsb.len !=3D 0) Strbuf_append(&slhs, lhsb.s); Strbuf_terminate(&slhs); (which I believe is what you want) but this is what's in HEAD: slhs.len =3D 0; Strbuf_append(&slhs, lhsb.s); Strbuf_terminate(&slhs); If I'm wrong about that let me know. Otherwise you don't need approval for what needs to be done from re@, just commit the fix to HEAD whenever you want. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-6fEk2p1qMiSAHeVbY0EQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHvHB0/G14VSmup/YRAreuAJ4y84j+DgGbxgjyfE1EG9jdgxnc/QCeJEPU ouYqrcG2JLMoNotJro63Src= =gEpb -----END PGP SIGNATURE----- --=-6fEk2p1qMiSAHeVbY0EQ-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 18:32:03 2008 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 4E23016A403 for ; Wed, 20 Feb 2008 18:32:03 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id 0298713C458 for ; Wed, 20 Feb 2008 18:32:02 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from [81.19.90.80] (unknown [81.19.90.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTP id 03D1917013 for ; Wed, 20 Feb 2008 21:32:02 +0300 (MSK) Message-ID: <47BC71FF.4020200@citrin.ru> Date: Wed, 20 Feb 2008 21:31:27 +0300 From: Anton Yuzhaninov User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <47BB4E5D.7010505@citrin.ru> <7F7C8315-AB96-425E-B942-0DB55BFDBCF3@FreeBSD.org> <47BC2AAB.5090605@citrin.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: tcsh in current-8.0 coredump 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, 20 Feb 2008 18:32:03 -0000 On 20.02.2008 19:05, Rui Paulo wrote: > > On Feb 20, 2008, at 1:27 PM, Anton Yuzhaninov wrote: > >> On 20.02.2008 4:56, Rui Paulo wrote: >>> On Feb 19, 2008, at 9:47 PM, Anton Yuzhaninov wrote: >>>> Problem was described here: >>>> http://docs.freebsd.org/cgi/mid.cgi?131632274.20070319100945 >>>> http://mx.gw.com/pipermail/tcsh-bugs/2007-March/000481.html >>>> >>>> This was fixed for RELENG_7: >>>> >>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcsh/sh.lex.c >>>> Revision 1.1.1.8 (vendor branch): download - view: text, markup, >>>> annotated - select for diffs >>>> Tue Apr 3 15:51:53 2007 UTC (10 months, 2 weeks ago) by mp >>>> Branches: ZOULAS, MAIN >>>> CVS tags: tcsh_6_15p1, RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0, RELENG_7 >>>> Diff to: previous 1.1.1.7: preferred, colored >>>> Changes since revision 1.1.1.7: +2 -1 lines >>>> >>>> Import vendor patch to fix postcmd regression in tcsh-6.15.00. >>>> ------- >>>> >>>> But this bug was not fixed in HEAD. >>>> >>> Are you sure? I seem to recall this was fixed even before RELENG_7 >>> was tagged. >> >> $ cvs up >> $ cvs diff -r HEAD -r RELENG_7 contrib/tcsh/sh.lex.c >> Index: contrib/tcsh/sh.lex.c >> =================================================================== >> RCS file: /home/ncvs/src/contrib/tcsh/sh.lex.c,v >> retrieving revision 1.1.1.9 >> retrieving revision 1.1.1.8 >> diff -u -r1.1.1.9 -r1.1.1.8 >> --- contrib/tcsh/sh.lex.c 15 Oct 2007 16:54:07 -0000 1.1.1.9 >> +++ contrib/tcsh/sh.lex.c 3 Apr 2007 15:51:53 -0000 1.1.1.8 >> @@ -851,7 +851,8 @@ >> return (en); >> } >> slhs.len = 0; >> - Strbuf_append(&slhs, lhsb.s); >> + if (lhsb.s != NULL && lhsb.len != 0) >> + Strbuf_append(&slhs, lhsb.s); >> Strbuf_terminate(&slhs); >> if (exclc) >> en = dosub(sc, en, global); >> >> As you can see from cvs diff, null pointer check present in RELENG_7. >> but absent in HEAD > > Oh, you are right. This was never MFC'ed, but the log says: > > revision 1.1.1.9 > date: 2007/10/15 16:54:07; author: mp; state: Exp; lines: +1 -2 > Import two vendor fixes from tcsh-6.15.01 for MFC to 7.0. The fixes are: > - Fix pty detection for autologout setting > - kill `foo` got stuck because sigchld was disabled too soon > > Requested by: re > > Maybe we should MFC this now. As I can see postcmd fix should be merged from RELENG_7 to HEAD, not vice versa. -- WBR, Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 21:01:20 2008 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 8014E16A401; Wed, 20 Feb 2008 21:01:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3B55413C469; Wed, 20 Feb 2008 21:01:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m1KKXkiI054531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 12:33:50 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <47BC8E3E.2090706@FreeBSD.org> Date: Wed, 20 Feb 2008 12:31:58 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> <47BBF9CC.4030404@delphij.net> In-Reply-To: <47BBF9CC.4030404@delphij.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Alexander Leidinger , FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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, 20 Feb 2008 21:01:20 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alexander Leidinger wrote: >> Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 >> -0800): >> >>> Change summary: >>> >>> fsutil.c: >>> - Really update standard superblock. fsck_ffs -b used to update the >>> backup superblock which does not recover file systems which have bad >>> master superblocks. >>> - Instead of coredump, zero out whole cg if its signature is bad. >>> >>> inode.c: >>> - Instead of coredump, zero out whole cg if its signature is bad. >> Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask >> for confirmation? > > My assumption is that if a cylinder group's magic number is damaged, > then the whole stuff can not be trusted at all, but yes, I think this > should come with a prompt, will add tomorrow. Does it make sense to make this functionality only available if some special command-line flag has been specified? For example in the presence of silent data corruption (which as we all know now is real) it is possible that read would return incorrect data, while it's still perfectly OK on disk. Zeroing data would make an irreversible damage in such case. IMHO, fsck should bail by default in such case, since it can't tell for sure what the source of the error is. -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 21:04:56 2008 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 D71E916A404 for ; Wed, 20 Feb 2008 21:04:56 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 6D41E13C455 for ; Wed, 20 Feb 2008 21:04:55 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m1KL4jss076033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 16:04:46 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current.alex@trull.org In-Reply-To: <47BA882C.7090103@trull.org> References: 1202955279.6548.2.camel@section-8.internal.avioc.org <47BA10C1.5030701@trull.org> <47BA185C.6030703@samsco.org> <47BA882C.7090103@trull.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rGxeWtKiP/9iExvoACbs" Organization: U. Buffalo CSE Department Date: Wed, 20 Feb 2008 16:04:45 -0500 Message-Id: <1203541485.99240.39.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=1.8 required=5.0 tests=MIME_QP_LONG_LINE autolearn=no version=3.2.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: freebsd-current@freebsd.org Subject: Re: hptrr driver panics on 7.0-RC2 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, 20 Feb 2008 21:04:56 -0000 --=-rGxeWtKiP/9iExvoACbs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-02-19 at 07:41 +0000, Alex Trull wrote: > Scott Long wrote: > > Alex Trull wrote: > >> Issue also confirmed with the rocketraid 2310 / revision 2.2 firmware=20 > >> on amd64. > > > > Yeah, known issue that will be addressed shortly. Sorry for the=20 > > inconvenience. Does it work with RC1 for you? > > > > Scott > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to=20 > > "freebsd-current-unsubscribe@freebsd.org" > Yes - the quickest recovery was booting the rc1 livefs image followed by=20 > copying over that image's /boot/kernel. >=20 > Thanks. >=20 > -- > Alex The hptrr driver update that had been done between 7.0-RC1 and 7.0-RC2 has been backed out in the CVS repository. If you experienced problems caused by that driver and can do a cvsup based update (branch tag RELENG_7_0) to see if that solves the issues and let us know that would be appreciated. I'm currently uploading a "mini-RC3" that just has the amd64 and i386 architectures but it will be a while before the upload completes and it then propagates out to the mirrors. I'll send out an announcement about its availability once it's had a chance to propagate a bit. If you successfully update using cvsup the kernel should identify itself as 7.0-RC3. Thanks. Sorry for the inconvenience caused by the driver's update. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-rGxeWtKiP/9iExvoACbs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHvJXt/G14VSmup/YRAoF2AJ9G8X72L3jsbrEwALtUEf0yECV0ZQCgmA6B WNMh/Q7TSagOPnGzF5SfcIc= =Gdw9 -----END PGP SIGNATURE----- --=-rGxeWtKiP/9iExvoACbs-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 21:04:20 2008 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 8ACEE16A58D for ; Wed, 20 Feb 2008 21:04:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 69DF913C4EA for ; Wed, 20 Feb 2008 21:04:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id EB2748C098; Wed, 20 Feb 2008 15:04:19 -0600 (CST) Date: Wed, 20 Feb 2008 15:04:19 -0600 To: Garrett Cooper Message-ID: <20080220210419.GA6194@soaustin.net> References: <200802201111.16340.achill@matrix.gatewaynet.com> <200802201547.17360.achill@matrix.gatewaynet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Wed, 20 Feb 2008 21:27:18 +0000 Cc: freebsd-current@freebsd.org, Achilleas Mantzios Subject: Re: Problem with various ports 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, 20 Feb 2008 21:04:20 -0000 On Wed, Feb 20, 2008 at 07:26:31AM -0800, Garrett Cooper wrote: > When was the last time you've rebuilt your ports? I think Alex > Leidinger or Mark Linimon did a fully encompassing restructure with > the autotools, but that was some months ago (July? August?). date: 2007/07/28 06:33:47; author: ade; state: Exp; lines: +20 -25 Update to the autotools new world order. We did numerous regression tests on the package build cluster to prepare for all that. mcl From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 21:47:56 2008 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 668AA16A405; Wed, 20 Feb 2008 21:47:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8BC13C461; Wed, 20 Feb 2008 21:47:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 3192628486; Thu, 21 Feb 2008 05:47:55 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 4132EEC3AA4; Thu, 21 Feb 2008 05:47:54 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id J+XjWZNslbQ3; Thu, 21 Feb 2008 05:47:49 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id CD301EC3A96; Thu, 21 Feb 2008 05:47:48 +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:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=iD1W1z1N2XXnS4Oej5nXqGF1iMuRWTG6Suxk3kzpo6W7gT23L+0nOVfb6qWqryC0D 5VO8BUH5iWveNNSp+dTaA== Message-ID: <47BCA003.9030708@delphij.net> Date: Wed, 20 Feb 2008 13:47:47 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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: Wed, 20 Feb 2008 21:47:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > Ivan Voras wrote: > >> Updating the firmware didn't help. I generated a NMI and have the >> debugger running. Apparently it's stuck in DELAY; > > Hmm, new data! It works on 8-CURRENT! > > Something's fishy here. I'll try and investigate more, but if anyone has > more ideas about where to look, I'd appreciate them - I don't want to > run a -CURRENT system in production. Would you please try to see if the latest snapshot, say, a RC3 image would work? IIRC there was a known issue with ciss(4) which is widely used on HP servers in RC2, which was fixed (new code disabled by default) now. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvKACi+vbBBjt66ARAsjFAKCAyi47CwSgg3Mo3YAL8tyMvX8NzwCdHbsD XWPam/if/74bor3oevab9C4= =tlrW -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 22:55:44 2008 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 5F82216A404; Wed, 20 Feb 2008 22:55:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 53F2D13C43E; Wed, 20 Feb 2008 22:55:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0B6B7744007; Thu, 21 Feb 2008 00:55:37 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 99tCpyNppiy9; Thu, 21 Feb 2008 00:55:36 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id A7BCA744006; Thu, 21 Feb 2008 00:55:35 +0200 (EET) Message-ID: <47BCAFE3.9050703@icyb.net.ua> Date: Thu, 21 Feb 2008 00:55:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, freebsd-i386@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> In-Reply-To: <47BC7287.6000301@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: PIIX4 chipset: (non-)exit from CPU states C2, C3 on interrupt 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, 20 Feb 2008 22:55:44 -0000 This is a report on an issue that I had with using C2 CPU power state on a system based on PIIX4E chipset. I think that other users of the chipsets from PIIX4 family might be affected as well. Also, this might be an informative reading for hackers chasing similar problems. Reference material: Intel(R) 82371AB PCI-TO-ISA/IDE Xcelerator (PIIX4) Datasheet http://www.intel.com/design/intarch/datashts/290562.htm Intel® 82371AB PIIX4, Intel® 82371EB PIIX4E and Intel® 82371MB PIIX4M Specification Update http://www.intel.com/design/chipsets/specupdt/297738.htm Intel® 82371EB (PIIX4E) Specification Update http://www.intel.com/design/chipsets/specupdt/290635.htm Relevant information can be found in the following sections of the original document and in updates/corrections/errata for them: 11.2. Clock Control 7.2.3. PMCNTRL—POWER MANAGEMENT CONTROL REGISTER (IO) 7.1.16. DEVACTB—DEVICE ACTIVITY B (FUNCTION 3) My summarized understanding: To behave in ACPI-compliant way with respect to C2 and C3 states the chipset must generate "Stop Break" events on any interrupt. This is because ACPI specification says the following about C2 state: "The hardware can exit this state for any reason, but must always exit this state whenever an interrupt is to be presented to the processor." For C3 it repeats the same and adds the following: "or when BM_RLD is set and a bus master is attempting to gain access to memory." According to PIIX4 documents the chipset exits "clock control state" either on "Stop Break" event or on "Burst" event. I leave the latter out of consideration because it is not ACPI compliant, CPU state is controlled by hardware, not by OS. Here's an excerpt from description of DEVACTB register, 6 lower bits are described: 5 IRQ8# Clock Event Enable (BRLD_EN_IRQ8)—R/W. 1=Enable an unmasked IRQ8# to, when asserted, generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 4 PME Clock Event Enable (BRLD_EN_PME)—R/W. 1=Enable an asserted SMI#, GPI1#, PWRBTN#, or LID signal to generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 3 Undefined. Must be written as a 0. 2 Keyboard/Mouse Global Reload Enable (GRLD_EN_KBC_MS)—R/W. 1=Enable an assertion of IRQ1 or IRQ12/M to reload the Global Standby Timer. 0=Disable. 1 IRQ Clock Event Enable (BRLD_EN_IRQ)—R/W. 1=Enable an unmasked IRQ[1,3:7,9:15], NMI, or INIT to generate a Burst event or Stop Break event. 0=Disable. 0 IRQ0 Clock Event Enable (BRLD_EN_IRQ0)—R/W. 1=Enable an unmasked IRQ0 to generate a Burst event or Stop Break event. 0=Disable. In order for the hardware to behave in ACPI-compliant way, that is to generate "Stop Break" events on all interrupts, the following bits of this register must be set: 0 - for IRQ0, 5 - for IRQ8, 1 - for the rest of the maskable interrupts You can read a saga about my investigation of a C2 behavior of a FreeBSD 7.0-RC1 system installed on a hardware based on PIIX4E chipset: http://docs.FreeBSD.org/cgi/mid.cgi?479F0ED4.9030709 This is a long thread with a couple of side-branches that keeps you in suspense until the very end. For those without time to waste, the following link is a pointer to where the most interesting details appear: http://docs.FreeBSD.org/cgi/mid.cgi?47BB375C.5010208 In short: on this system bit 5 of the mentioned above register was reset (i.e. 0), so RTC/IRQ8 didn't cause exit from C2 state. Thus, with cx_lowest=C2, RTC interrupt was handled at the predictable times, usually back-to-back after IRQ0 handler. As a result statclock() gathered CPU usage information (user:nice:system:interrupt:idle) at quite deterministic moments, so the statics was very biased in favor of interrupt usage. This is what the register had after boot: $ pciconf -r pci0:0:7:3 0x58 03040c07 After doing the following CPU statics became reasonable: pciconf -w pci0:0:7:3 0x58 0x03040c27 >From pciconf -lv: intsmb0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class = bridge In the end, my suggestion is that acpi_cpu code should check value of those 3 bits and set them if necessary. I am not actually sure why I have bit 5 reset to 0. Maybe because this is a fault of a vendor of my motherboard/BIOS. Maybe I unwittingly caused this by changing some BIOS setting, but if this is the case, then the setting must appear under a name and description that I would never relate to this issue. Another possible resolution is to check the bits, but instead of changing them just refuse to use anything lower than C1. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 00:13:41 2008 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 00FB216A402 for ; Thu, 21 Feb 2008 00:13:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 79E8013C46A for ; Thu, 21 Feb 2008 00:13:40 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JRz49-00014L-US for freebsd-current@freebsd.org; Thu, 21 Feb 2008 00:13:33 +0000 Received: from 89-172-44-250.adsl.net.t-com.hr ([89.172.44.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 00:13:33 +0000 Received: from ivoras by 89-172-44-250.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 00:13:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 21 Feb 2008 01:13:16 +0100 Lines: 44 Message-ID: References: <47BCA003.9030708@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD80273E7F1D53ED1B8E7477" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-44-250.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <47BCA003.9030708@delphij.net> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Urgent problem - 7.x doesn't work on HP servers 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, 21 Feb 2008 00:13:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD80273E7F1D53ED1B8E7477 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Xin LI wrote: > Ivan Voras wrote: >> Ivan Voras wrote: >=20 >>> Updating the firmware didn't help. I generated a NMI and have the >>> debugger running. Apparently it's stuck in DELAY;=20 >> Hmm, new data! It works on 8-CURRENT! >=20 >> Something's fishy here. I'll try and investigate more, but if anyone h= as >> more ideas about where to look, I'd appreciate them - I don't want to >> run a -CURRENT system in production. >=20 > Would you please try to see if the latest snapshot, say, a RC3 image > would work? IIRC there was a known issue with ciss(4) which is widely > used on HP servers in RC2, which was fixed (new code disabled by > default) now. I cannot find RC3 images on ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/7.0/ but booting a RELENG_7 kernel works (!) so your it looks like you have found the problem! --------------enigAD80273E7F1D53ED1B8E7477 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHvMIildnAQVacBcgRAkQpAJMHyZYX4EF1drQcl8uCQ5vdcIa/AJ9KT/Ea PrnvCR5KhbW5nss+mIMAtw== =+zXH -----END PGP SIGNATURE----- --------------enigAD80273E7F1D53ED1B8E7477-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 01:28:34 2008 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 7D66916A40B for ; Thu, 21 Feb 2008 01:28:34 +0000 (UTC) (envelope-from robbak@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id 55B4513C45E for ; Thu, 21 Feb 2008 01:28:33 +0000 (UTC) (envelope-from robbak@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so1311257tid.3 for ; Wed, 20 Feb 2008 17:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=MH1/glCA9jjCH6F0b07HRZAUhqAx4XnI3iUvonJ2c9E=; b=HNQ4bXDJnZs19JpL9gFY6it806WyDE1RY1niISE1x2vlSlUvCm8yQhs3WZHaNJypPrHCJycsze8ptZif8jQviCD2th5QdQRtnG7XlLoRKDCShEyGEqexVlwvuFG61pO/0wkMgwKFqUXVVk22lnDkE5hPVj3qD9N4td20eJN+Edw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=B44Tc0JYsVmv4Yc3xb3toZikb/n9+1lbgWQz+r45EiNkFyb5Jg+8W+Su/fktqjOmlR5E/AK76EyMG/xExXluepv6rJPVupeNkYI6qQyhmK2EssTvRbnyx/w2o9W/eOac/ZhJ+fvzpcnRCqf73i8CTDl12YfbGw6BtbVUEbHEq3E= Received: by 10.110.28.2 with SMTP id b2mr6376467tib.39.1203555782161; Wed, 20 Feb 2008 17:03:02 -0800 (PST) Received: by 10.110.26.11 with HTTP; Wed, 20 Feb 2008 17:03:02 -0800 (PST) Message-ID: Date: Thu, 21 Feb 2008 11:03:02 +1000 From: "Robert Backhaus" Sender: robbak@gmail.com To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_349_32900395.1203555782162" X-Google-Sender-Auth: 2a4e7ec518443f00 Subject: Packet corruption in re0 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, 21 Feb 2008 01:28:34 -0000 ------=_Part_349_32900395.1203555782162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am experiencing roughly 15% packet corruption on the re interface on my freebsd 7/amd64 box. FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: Tue Feb 5 09:49:55 EST 2008 root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 The attached 3 files demonstrate the problem: "ping" shows the output of ping -c 100, and shows 15% packet loss. "tcpdump" shows the packets leaving, and some of the lost packets being returned with addresses, ports and data corrupted. The data in these packets seems to be coming from other packets passing through other interfaces at the time. "remote-tcpdump" shows the packets being received and returned from the other machine. Note that some packets are being corrupted on the way out, too. Just to make troubleshooting difficult, this problem only shows up after the system has been up for roughly 36 hours, depending on the amount of traffic. I am using the latest bios that I am aware of. The bios that I recently applied did include a firmware update for the realtek interface, but this did not affect the problem. ------=_Part_349_32900395.1203555782162 Content-Type: application/octet-stream; name=ping Content-Transfer-Encoding: base64 X-Attachment-Id: f_fcwlxts90 Content-Disposition: attachment; filename=ping U2NyaXB0IHN0YXJ0ZWQgb24gVGh1IEZlYiAyMSAwOTo1NjozMiAyMDA4CnJvYmJha0Bndzp+IDAg JCBwaW5nIC1jIDEwMCAxMC4xMC4xMS41MA0KUElORyAxMC4xMC4xMS41MCAoMTAuMTAuMTEuNTAp OiA1NiBkYXRhIGJ5dGVzDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0wIHR0 bD02NCB0aW1lPTAuNzQ1IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0x IHR0bD02NCB0aW1lPTAuMzAyIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3Nl cT0yIHR0bD02NCB0aW1lPTAuMjg0IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21w X3NlcT0zIHR0bD02NCB0aW1lPTAuMjk2IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBp Y21wX3NlcT00IHR0bD02NCB0aW1lPTAuMzA4IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUw OiBpY21wX3NlcT01IHR0bD02NCB0aW1lPTAuMjk5IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjEx LjUwOiBpY21wX3NlcT02IHR0bD02NCB0aW1lPTAuMjc3IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEw LjExLjUwOiBpY21wX3NlcT03IHR0bD02NCB0aW1lPTAuMjczIG1zDQo2NCBieXRlcyBmcm9tIDEw LjEwLjExLjUwOiBpY21wX3NlcT05IHR0bD02NCB0aW1lPTAuMzQ0IG1zDQo2NCBieXRlcyBmcm9t IDEwLjEwLjExLjUwOiBpY21wX3NlcT0xMCB0dGw9NjQgdGltZT0wLjMwNiBtcw0KNjQgYnl0ZXMg ZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9MTEgdHRsPTY0IHRpbWU9MC4zMDcgbXMNCjY0IGJ5 dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTEyIHR0bD02NCB0aW1lPTAuMjk3IG1zDQo2 NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0xMyB0dGw9NjQgdGltZT0wLjI4NCBt cw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9MTQgdHRsPTY0IHRpbWU9MC4z NDAgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTE1IHR0bD02NCB0aW1l PTAuMzEyIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0xNiB0dGw9NjQg dGltZT0wLjMxNCBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9MTcgdHRs PTY0IHRpbWU9MC4yOTYgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTE4 IHR0bD02NCB0aW1lPTAuMzAyIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3Nl cT0xOSB0dGw9NjQgdGltZT0wLjMyNSBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNt cF9zZXE9MjAgdHRsPTY0IHRpbWU9MC4yODggbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6 IGljbXBfc2VxPTIxIHR0bD02NCB0aW1lPTAuMjg4IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjEx LjUwOiBpY21wX3NlcT0yMiB0dGw9NjQgdGltZT0wLjI4NiBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4x MC4xMS41MDogaWNtcF9zZXE9MjMgdHRsPTY0IHRpbWU9MC4yNzUgbXMNCjY0IGJ5dGVzIGZyb20g MTAuMTAuMTEuNTA6IGljbXBfc2VxPTI0IHR0bD02NCB0aW1lPTAuMjg3IG1zDQo2NCBieXRlcyBm cm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0yNSB0dGw9NjQgdGltZT0wLjI3MCBtcw0KNjQgYnl0 ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9MjcgdHRsPTY0IHRpbWU9MC4zMDIgbXMNCjY0 IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTI4IHR0bD02NCB0aW1lPTAuMzI2IG1z DQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0yOSB0dGw9NjQgdGltZT0wLjMz NSBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9MzAgdHRsPTY0IHRpbWU9 MC4zMjAgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTMxIHR0bD02NCB0 aW1lPTAuMzM0IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT0zMiB0dGw9 NjQgdGltZT0wLjMwOSBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9MzMg dHRsPTY0IHRpbWU9MC4zMTAgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2Vx PTM0IHR0bD02NCB0aW1lPTAuMzIwIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21w X3NlcT0zNSB0dGw9NjQgdGltZT0wLjMyMCBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDog aWNtcF9zZXE9MzYgdHRsPTY0IHRpbWU9MC4zMjQgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEu NTA6IGljbXBfc2VxPTM3IHR0bD02NCB0aW1lPTAuMzIwIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEw LjExLjUwOiBpY21wX3NlcT0zOCB0dGw9NjQgdGltZT0wLjMxMCBtcw0KNjQgYnl0ZXMgZnJvbSAx MC4xMC4xMS41MDogaWNtcF9zZXE9NDAgdHRsPTY0IHRpbWU9MC4zMDYgbXMNCjY0IGJ5dGVzIGZy b20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTQxIHR0bD02NCB0aW1lPTAuMzEzIG1zDQo2NCBieXRl cyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT00MiB0dGw9NjQgdGltZT0wLjMxNSBtcw0KNjQg Ynl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NDMgdHRsPTY0IHRpbWU9MC4zMDYgbXMN CjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTQ0IHR0bD02NCB0aW1lPTAuMzE5 IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT00NiB0dGw9NjQgdGltZT0w LjMyMCBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NDcgdHRsPTY0IHRp bWU9MC4zMDMgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTQ4IHR0bD02 NCB0aW1lPTAuMzEwIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT00OSB0 dGw9NjQgdGltZT0wLjMzOCBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9 NTAgdHRsPTY0IHRpbWU9MC4zMTkgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBf c2VxPTUxIHR0bD02NCB0aW1lPTAuMzEyIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBp Y21wX3NlcT01MiB0dGw9NjQgdGltZT0wLjMxNSBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41 MDogaWNtcF9zZXE9NTMgdHRsPTY0IHRpbWU9MC4zMTMgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAu MTEuNTA6IGljbXBfc2VxPTU1IHR0bD02NCB0aW1lPTAuMzQ4IG1zDQo2NCBieXRlcyBmcm9tIDEw LjEwLjExLjUwOiBpY21wX3NlcT01NiB0dGw9NjQgdGltZT0wLjMzMiBtcw0KNjQgYnl0ZXMgZnJv bSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NTcgdHRsPTY0IHRpbWU9MC4zMjggbXMNCjY0IGJ5dGVz IGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTU4IHR0bD02NCB0aW1lPTAuMzMxIG1zDQo2NCBi eXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT01OSB0dGw9NjQgdGltZT0wLjM0NSBtcw0K NjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NjAgdHRsPTY0IHRpbWU9MC4zNjAg bXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTYxIHR0bD02NCB0aW1lPTAu MzI3IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT02MiB0dGw9NjQgdGlt ZT0wLjMwMCBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NjQgdHRsPTY0 IHRpbWU9MC4zNDAgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTY2IHR0 bD02NCB0aW1lPTAuMzAzIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT02 NyB0dGw9NjQgdGltZT0wLjI5NyBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9z ZXE9NjggdHRsPTY0IHRpbWU9MC4zMTEgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGlj bXBfc2VxPTcwIHR0bD02NCB0aW1lPTAuMzEwIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUw OiBpY21wX3NlcT03MSB0dGw9NjQgdGltZT0wLjMyMCBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4x MS41MDogaWNtcF9zZXE9NzIgdHRsPTY0IHRpbWU9MC4zMDYgbXMNCjY0IGJ5dGVzIGZyb20gMTAu MTAuMTEuNTA6IGljbXBfc2VxPTczIHR0bD02NCB0aW1lPTAuMzEzIG1zDQo2NCBieXRlcyBmcm9t IDEwLjEwLjExLjUwOiBpY21wX3NlcT03NCB0dGw9NjQgdGltZT0wLjMyOSBtcw0KNjQgYnl0ZXMg ZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NzUgdHRsPTY0IHRpbWU9MC4zMzcgbXMNCjY0IGJ5 dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTc2IHR0bD02NCB0aW1lPTAuMzA2IG1zDQo2 NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT03NyB0dGw9NjQgdGltZT0wLjMwMSBt cw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9NzkgdHRsPTY0IHRpbWU9MC4z MjMgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTgwIHR0bD02NCB0aW1l PTAuMjk5IG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT04MSB0dGw9NjQg dGltZT0wLjMxMyBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9ODMgdHRs PTY0IHRpbWU9MC4yOTMgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTg1 IHR0bD02NCB0aW1lPTAuMzAxIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3Nl cT04NiB0dGw9NjQgdGltZT0wLjMwOSBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNt cF9zZXE9ODggdHRsPTY0IHRpbWU9MC4zMTkgbXMNCjY0IGJ5dGVzIGZyb20gMTAuMTAuMTEuNTA6 IGljbXBfc2VxPTg5IHR0bD02NCB0aW1lPTAuMzMzIG1zDQo2NCBieXRlcyBmcm9tIDEwLjEwLjEx LjUwOiBpY21wX3NlcT05MSB0dGw9NjQgdGltZT0wLjMxNyBtcw0KNjQgYnl0ZXMgZnJvbSAxMC4x MC4xMS41MDogaWNtcF9zZXE9OTMgdHRsPTY0IHRpbWU9MC4zMjggbXMNCjY0IGJ5dGVzIGZyb20g MTAuMTAuMTEuNTA6IGljbXBfc2VxPTk0IHR0bD02NCB0aW1lPTEyLjQ3MSBtcw0KNjQgYnl0ZXMg ZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9OTUgdHRsPTY0IHRpbWU9MC4zMTcgbXMNCjY0IGJ5 dGVzIGZyb20gMTAuMTAuMTEuNTA6IGljbXBfc2VxPTk2IHR0bD02NCB0aW1lPTAuMzI2IG1zDQo2 NCBieXRlcyBmcm9tIDEwLjEwLjExLjUwOiBpY21wX3NlcT05NyB0dGw9NjQgdGltZT0wLjMxNSBt cw0KNjQgYnl0ZXMgZnJvbSAxMC4xMC4xMS41MDogaWNtcF9zZXE9OTggdHRsPTY0IHRpbWU9MC4z MDggbXMNCg0KLS0tIDEwLjEwLjExLjUwIHBpbmcgc3RhdGlzdGljcyAtLS0NCjEwMCBwYWNrZXRz IHRyYW5zbWl0dGVkLCA4NSBwYWNrZXRzIHJlY2VpdmVkLCAxNS4wJSBwYWNrZXQgbG9zcw0Kcm91 bmQtdHJpcCBtaW4vYXZnL21heC9zdGRkZXYgPSAwLjI3MC8wLjQ2MC8xMi40NzEvMS4zMTEgbXMN CnJvYmJha0Bndzp+IDAgJCANCnJvYmJha0Bndzp+IDEgJCBleGl0DQoKU2NyaXB0IGRvbmUgb24g VGh1IEZlYiAyMSAwOTo1OTozMyAyMDA4Cg== ------=_Part_349_32900395.1203555782162 Content-Type: application/octet-stream; name=tcpdump Content-Transfer-Encoding: base64 X-Attachment-Id: f_fcwly6961 Content-Disposition: attachment; filename=tcpdump U2NyaXB0IHN0YXJ0ZWQgb24gVGh1IEZlYiAyMSAwOTo1NjowMyAyMDA4CnJvYmJha0Bndzp+IDAg JCB0Y3BkdW1wIHJlMAgICAgICAgICAgIG1sxQHMbWzFAdRtbMUBkG1sxQG8bWzFAIA0KUGFzc3dv cmQ6DQp0Y3BkdW1wOiBzeW50YXggZXJyb3INCnJvYmJha0Bndzp+IDEgJCBzdWRvIHRjcGR1bXAg LWkgcmUwDQp0Y3BkdW1wOiB2ZXJib3NlIG91dHB1dCBzdXBwcmVzc2VkLCB1c2UgLXYgb3IgLXZ2 IGZvciBmdWxsIHByb3RvY29sIGRlY29kZQ0KbGlzdGVuaW5nIG9uIHJlMCwgbGluay10eXBlIEVO MTBNQiAoRXRoZXJuZXQpLCBjYXB0dXJlIHNpemUgOTYgYnl0ZXMNCjA5OjU2OjQ1LjEyODM3OSBh cnAgd2hvLWhhcyAxMC4xMC4xMS41MCB0ZWxsIDEwLjEwLjExLjENCjA5OjU2OjQ1LjEyODc4NiBh cnAgcmVwbHkgMTAuMTAuMTEuNTAgaXMtYXQgMDA6MTE6NWI6YjE6OWQ6YjEgKG91aSBVbmtub3du KQ0KMDk6NTY6NDUuMTI4Nzk2IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hv IHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMCwgbGVuZ3RoIDY0DQowOTo1Njo0NS4xMjkwNjEgSVAg MTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEg MCwgbGVuZ3RoIDY0DQowOTo1Njo0Ni4xMjk2MjQgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUw OiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxLCBsZW5ndGggNjQNCjA5OjU2OjQ2 LjEyOTg5OSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQg MTk4MDgsIHNlcSAxLCBsZW5ndGggNjQNCjA5OjU2OjQ3LjEzMDU5MCBJUCAxMC4xMC4xMS4xID4g MTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDIsIGxlbmd0aCA2 NA0KMDk6NTY6NDcuMTMwODUzIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hv IHJlcGx5LCBpZCAxOTgwOCwgc2VxIDIsIGxlbmd0aCA2NA0KMDk6NTY6NDguMTMxNTYxIElQIDEw LjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEg MywgbGVuZ3RoIDY0DQowOTo1Njo0OC4xMzE4MzggSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4x OiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMywgbGVuZ3RoIDY0DQowOTo1Njo0OS4x MzI1MzMgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQg MTk4MDgsIHNlcSA0LCBsZW5ndGggNjQNCjA5OjU2OjQ5LjEzMjgyMiBJUCAxMC4xMC4xMS41MCA+ IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA0LCBsZW5ndGggNjQN CjA5OjU2OjUwLjEzMzUxMSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyBy ZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDUsIGxlbmd0aCA2NA0KMDk6NTY6NTAuMTMzNzg3IElQIDEw LjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDUs IGxlbmd0aCA2NA0KMDk6NTY6NTEuMTM0NDc5IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDog SUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNiwgbGVuZ3RoIDY0DQowOTo1Njo1MS4x MzQ3MzYgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5 ODA4LCBzZXEgNiwgbGVuZ3RoIDY0DQowOTo1Njo1Mi4xMzU0NTcgSVAgMTAuMTAuMTEuMSA+IDEw LjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA3LCBsZW5ndGggNjQN CjA5OjU2OjUyLjEzNTcwOSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyBy ZXBseSwgaWQgMTk4MDgsIHNlcSA3LCBsZW5ndGggNjQNCjA5OjU2OjUzLjEzNjQyNCBJUCAxMC4x MC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDgs IGxlbmd0aCA2NA0KMDk6NTY6NTMuMTM2Njk2IDc1OjY1OjAwOmEwOmNjOjMwIChvdWkgVW5rbm93 bikgPiA0Nzo0NTo1NDoyMDoyZjo3MSAob3VpIFVua25vd24pLCBldGhlcnR5cGUgVW5rbm93biAo MHhmZmZmKSwgbGVuZ3RoIDk4OiANCgkweDAwMDA6ICAwMDE0IDZjYTggZWZhZSAwODAwIDQ1MDAg MjYwMyA3MjAyIDAwNDAgIC4ubC4uLi4uRS4mLnIuLkANCgkweDAwMTA6ICAzYjA2IGIyZmQgY2Jj ZSA4YjQ1IGMwYTggMDAwMiAwMDUwIGU5MTUgIDsuLi4uLi5FLi4uLi5QLi4NCgkweDAwMjA6ICA0 NTY5IGI3NDkgZTViYyA4MmI3IDgwMTggODAyMSAwMDAwIDAwMDAgIEVpLkkuLi4uLi4uIS4uLi4N CgkweDAwMzA6ICAwMTAxIDA4MGEgYTliMCAzMTEwIDQ1ZWYgZDMxOSA2ODg4IGZmNGYgIC4uLi4u LjEuRS4uLmguLk8NCgkweDAwNDA6ICA0YzMzIDAzOWUgYTc1MiBjMmI3IDlhNWYgNTdkMCAyMjBi IDU3ZGIgIEwzLi4uUi4uLl9XLiIuVy4NCgkweDAwNTA6ICA3ZjY2ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC5mDQowOTo1Njo1NC4xMzc0MDEgSVAgMTAuMTAuMTEuMSA+IDEw LjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA5LCBsZW5ndGggNjQN CjA5OjU2OjU0LjEzNzcyMCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyBy ZXBseSwgaWQgMTk4MDgsIHNlcSA5LCBsZW5ndGggNjQNCjA5OjU2OjU1LjEzODM3MiBJUCAxMC4x MC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDEw LCBsZW5ndGggNjQNCjA5OjU2OjU1LjEzODY1MyBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6 IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAxMCwgbGVuZ3RoIDY0DQowOTo1Njo1Ni4x MzkzNDYgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQg MTk4MDgsIHNlcSAxMSwgbGVuZ3RoIDY0DQowOTo1Njo1Ni4xMzk2MjUgSVAgMTAuMTAuMTEuNTAg PiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMTEsIGxlbmd0aCA2 NA0KMDk6NTY6NTcuMTQwMzE5IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hv IHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMTIsIGxlbmd0aCA2NA0KMDk6NTY6NTcuMTQwNTgxIElQ IDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2Vx IDEyLCBsZW5ndGggNjQNCjA5OjU2OjU4LjE0MTI5MSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEu NTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDEzLCBsZW5ndGggNjQNCjA5OjU2 OjU4LjE0MTU0OCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwg aWQgMTk4MDgsIHNlcSAxMywgbGVuZ3RoIDY0DQowOTo1Njo1OS4xNDIyNjggSVAgMTAuMTAuMTEu MSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxNCwgbGVu Z3RoIDY0DQowOTo1Njo1OS4xNDI1NzUgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01Q IGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMTQsIGxlbmd0aCA2NA0KMDk6NTc6MDAuMTQzMjM1 IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4 LCBzZXEgMTUsIGxlbmd0aCA2NA0KMDk6NTc6MDAuMTQzNTE5IElQIDEwLjEwLjExLjUwID4gMTAu MTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDE1LCBsZW5ndGggNjQNCjA5 OjU3OjAxLjE0NDIwNyBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1 ZXN0LCBpZCAxOTgwOCwgc2VxIDE2LCBsZW5ndGggNjQNCjA5OjU3OjAxLjE0NDQ5NCBJUCAxMC4x MC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAxNiwg bGVuZ3RoIDY0DQowOTo1NzowMi4xNDUxNzkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJ Q01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxNywgbGVuZ3RoIDY0DQowOTo1NzowMi4x NDU0NDYgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5 ODA4LCBzZXEgMTcsIGxlbmd0aCA2NA0KMDk6NTc6MDMuMTQ2MTUxIElQIDEwLjEwLjExLjEgPiAx MC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMTgsIGxlbmd0aCA2 NA0KMDk6NTc6MDMuMTQ2NDI2IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hv IHJlcGx5LCBpZCAxOTgwOCwgc2VxIDE4LCBsZW5ndGggNjQNCjA5OjU3OjA0LjE0NzEyNSBJUCAx MC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2Vx IDE5LCBsZW5ndGggNjQNCjA5OjU3OjA0LjE0NzQyMSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjEx LjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAxOSwgbGVuZ3RoIDY0DQowOTo1Nzow NS4xNDgwOTIgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwg aWQgMTk4MDgsIHNlcSAyMCwgbGVuZ3RoIDY0DQowOTo1NzowNS4xNDgzNTcgSVAgMTAuMTAuMTEu NTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMjAsIGxlbmd0 aCA2NA0KMDk6NTc6MDYuMTQ5MDY4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBl Y2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMjEsIGxlbmd0aCA2NA0KMDk6NTc6MDYuMTQ5MzMx IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwg c2VxIDIxLCBsZW5ndGggNjQNCjA5OjU3OjA3LjE1MDAzOCBJUCAxMC4xMC4xMS4xID4gMTAuMTAu MTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDIyLCBsZW5ndGggNjQNCjA5 OjU3OjA3LjE1MDI5OSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBs eSwgaWQgMTk4MDgsIHNlcSAyMiwgbGVuZ3RoIDY0DQowOTo1NzowOC4xNTEwMDcgSVAgMTAuMTAu MTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAyMywg bGVuZ3RoIDY0DQowOTo1NzowOC4xNTEyNTcgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJ Q01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMjMsIGxlbmd0aCA2NA0KMDk6NTc6MDkuMTUx OTgzIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5 ODA4LCBzZXEgMjQsIGxlbmd0aCA2NA0KMDk6NTc6MDkuMTUyMjQzIElQIDEwLjEwLjExLjUwID4g MTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDI0LCBsZW5ndGggNjQN CjA5OjU3OjEwLjE1Mjk1MyBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyBy ZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDI1LCBsZW5ndGggNjQNCjA5OjU3OjEwLjE1MzIwMCBJUCAx MC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAy NSwgbGVuZ3RoIDY0DQowOTo1NzoxMS4xNTM5MjMgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUw OiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAyNiwgbGVuZ3RoIDY0DQowOTo1Nzox Mi4xNTQ4OTQgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwg aWQgMTk4MDgsIHNlcSAyNywgbGVuZ3RoIDY0DQowOTo1NzoxMi4xNTUxNzcgSVAgMTAuMTAuMTEu NTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMjcsIGxlbmd0 aCA2NA0KMDk6NTc6MTMuMTU1ODY2IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBl Y2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMjgsIGxlbmd0aCA2NA0KMDk6NTc6MTMuMTU2MTcy IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwg c2VxIDI4LCBsZW5ndGggNjQNCjA5OjU3OjE0LjE1Njg0MCBJUCAxMC4xMC4xMS4xID4gMTAuMTAu MTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDI5LCBsZW5ndGggNjQNCjA5 OjU3OjE0LjE1NzE1NiBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBs eSwgaWQgMTk4MDgsIHNlcSAyOSwgbGVuZ3RoIDY0DQowOTo1NzoxNS4xNTc4MTEgSVAgMTAuMTAu MTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAzMCwg bGVuZ3RoIDY0DQowOTo1NzoxNS4xNTgxMTAgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJ Q01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMzAsIGxlbmd0aCA2NA0KMDk6NTc6MTYuMTU4 Nzg0IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5 ODA4LCBzZXEgMzEsIGxlbmd0aCA2NA0KMDk6NTc6MTYuMTU5MDk2IElQIDEwLjEwLjExLjUwID4g MTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDMxLCBsZW5ndGggNjQN CjA5OjU3OjE3LjE1OTc1NCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyBy ZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDMyLCBsZW5ndGggNjQNCjA5OjU3OjE3LjE2MDA0NSBJUCAx MC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAz MiwgbGVuZ3RoIDY0DQowOTo1NzoxOC4xNjA3MjcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUw OiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAzMywgbGVuZ3RoIDY0DQowOTo1Nzox OC4xNjEwMTcgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlk IDE5ODA4LCBzZXEgMzMsIGxlbmd0aCA2NA0KMDk6NTc6MTkuMTYxNzAwIElQIDEwLjEwLjExLjEg PiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMzQsIGxlbmd0 aCA2NA0KMDk6NTc6MTkuMTYxOTk5IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBl Y2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDM0LCBsZW5ndGggNjQNCjA5OjU3OjIwLjE2MjY3MiBJ UCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwg c2VxIDM1LCBsZW5ndGggNjQNCjA5OjU3OjIwLjE2Mjk3MSBJUCAxMC4xMC4xMS41MCA+IDEwLjEw LjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAzNSwgbGVuZ3RoIDY0DQowOTo1 NzoyMS4xNjM2NDYgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVz dCwgaWQgMTk4MDgsIHNlcSAzNiwgbGVuZ3RoIDY0DQowOTo1NzoyMS4xNjM5NDcgSVAgMTAuMTAu MTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMzYsIGxl bmd0aCA2NA0KMDk6NTc6MjIuMTY0NjE2IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNN UCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMzcsIGxlbmd0aCA2NA0KMDk6NTc6MjIuMTY0 OTE3IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgw OCwgc2VxIDM3LCBsZW5ndGggNjQNCjA5OjU3OjIzLjE2NTU4NyBJUCAxMC4xMC4xMS4xID4gMTAu MTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDM4LCBsZW5ndGggNjQN CjA5OjU3OjIzLjE2NTg3OCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyBy ZXBseSwgaWQgMTk4MDgsIHNlcSAzOCwgbGVuZ3RoIDY0DQowOTo1NzoyNC4xNjY1NjEgSVAgMTAu MTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAz OSwgbGVuZ3RoIDY0DQowOTo1NzoyNC4xNjY4NjMgOTM6NTI6NWM6NzA6MTU6NjggKG91aSBVbmtu b3duKSA+IGFlOjVjOjhlOjNiOjU4OmEzIChvdWkgVW5rbm93biksIGV0aGVydHlwZSBVbmtub3du ICgweDEzODEpLCBsZW5ndGggOTg6IA0KCTB4MDAwMDogIGNjMmMgMjUwMSBlZjliIGM2MTAgZjgx YiA2ODEzIGJjMGEgYjQ0NSAgLiwlLi4uLi4uLmguLi4uRQ0KCTB4MDAxMDogIDVlNDUgYjA4NCA4 MWFlIDlkZDAgNjM5OSA3NjQ0IGE0NWYgN2YzNCAgXkUuLi4uLi5jLnZELl8uNA0KCTB4MDAyMDog IDQ4ODQgYWZjMyAzNjIyIDU3NjEgMWIwOCBmZjZhIGJhN2QgZjUxZiAgSC4uLjYiV2EuLi5qLn0u Lg0KCTB4MDAzMDogIDExNTIgM2RjMCBmNTQzIGE0MzAgNDBkNyBlZWNjIDZmYmIgZTZiNSAgLlI9 Li5DLjBALi4uby4uLg0KCTB4MDA0MDogIDM5NzYgNGQ1YiAyZDlkIGI3NzAgOTg4OCAxMGU0IDE2 M2EgMzBmOCAgOXZNWy0uLnAuLi4uLjowLg0KCTB4MDA1MDogIDUzZDIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUy4NCjA5OjU3OjI1LjE2NzUzMyBJUCAxMC4xMC4xMS4xID4g MTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDQwLCBsZW5ndGgg NjQNCjA5OjU3OjI1LjE2NzgxNyBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNo byByZXBseSwgaWQgMTk4MDgsIHNlcSA0MCwgbGVuZ3RoIDY0DQowOTo1NzoyNi4xNjg1MDQgSVAg MTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNl cSA0MSwgbGVuZ3RoIDY0DQowOTo1NzoyNi4xNjg3OTcgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4x MS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNDEsIGxlbmd0aCA2NA0KMDk6NTc6 MjcuMTY5NDc2IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3Qs IGlkIDE5ODA4LCBzZXEgNDIsIGxlbmd0aCA2NA0KMDk6NTc6MjcuMTY5NzcxIElQIDEwLjEwLjEx LjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDQyLCBsZW5n dGggNjQNCjA5OjU3OjI4LjE3MDQ0OCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAg ZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDQzLCBsZW5ndGggNjQNCjA5OjU3OjI4LjE3MDcz NSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgs IHNlcSA0MywgbGVuZ3RoIDY0DQowOTo1NzoyOS4xNzE0MjQgSVAgMTAuMTAuMTEuMSA+IDEwLjEw LjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA0NCwgbGVuZ3RoIDY0DQow OTo1NzoyOS4xNzE3MjEgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVw bHksIGlkIDE5ODA4LCBzZXEgNDQsIGxlbmd0aCA2NA0KMDk6NTc6MzAuMTcyMzkzIElQIDEwLjEw LjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNDUs IGxlbmd0aCA2NA0KMDk6NTc6MzEuMTczMzY1IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDog SUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNDYsIGxlbmd0aCA2NA0KMDk6NTc6MzEu MTczNjY0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAx OTgwOCwgc2VxIDQ2LCBsZW5ndGggNjQNCjA5OjU3OjMyLjE3NDMzNyBJUCAxMC4xMC4xMS4xID4g MTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDQ3LCBsZW5ndGgg NjQNCjA5OjU3OjMyLjE3NDYxOSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNo byByZXBseSwgaWQgMTk4MDgsIHNlcSA0NywgbGVuZ3RoIDY0DQowOTo1NzozMy4xNzUzMTAgSVAg MTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNl cSA0OCwgbGVuZ3RoIDY0DQowOTo1NzozMy4xNzU2MDEgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4x MS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNDgsIGxlbmd0aCA2NA0KMDk6NTc6 MzQuMTc2Mjg1IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3Qs IGlkIDE5ODA4LCBzZXEgNDksIGxlbmd0aCA2NA0KMDk6NTc6MzQuMTc2NTk4IElQIDEwLjEwLjEx LjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDQ5LCBsZW5n dGggNjQNCjA5OjU3OjM1LjE3NzI1NiBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAg ZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDUwLCBsZW5ndGggNjQNCjA5OjU3OjM1LjE3NzU0 NCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgs IHNlcSA1MCwgbGVuZ3RoIDY0DQowOTo1NzozNi4xNzgyMjUgSVAgMTAuMTAuMTEuMSA+IDEwLjEw LjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA1MSwgbGVuZ3RoIDY0DQow OTo1NzozNi4xNzg1MTggSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVw bHksIGlkIDE5ODA4LCBzZXEgNTEsIGxlbmd0aCA2NA0KMDk6NTc6MzcuMTc5MTk4IElQIDEwLjEw LjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNTIs IGxlbmd0aCA2NA0KMDk6NTc6MzcuMTc5NDkyIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTog SUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDUyLCBsZW5ndGggNjQNCjA5OjU3OjM4LjE4 MDE3MCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAx OTgwOCwgc2VxIDUzLCBsZW5ndGggNjQNCjA5OjU3OjM4LjE4MDQ2MiBJUCAxMC4xMC4xMS41MCA+ IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA1MywgbGVuZ3RoIDY0 DQowOTo1NzozOS4xODExNTEgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8g cmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA1NCwgbGVuZ3RoIDY0DQowOTo1Nzo0MC4xODIxMjcgSVAg MTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNl cSA1NSwgbGVuZ3RoIDY0DQowOTo1Nzo0MC4xODI0NDIgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4x MS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNTUsIGxlbmd0aCA2NA0KMDk6NTc6 NDEuMTgzMDg4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3Qs IGlkIDE5ODA4LCBzZXEgNTYsIGxlbmd0aCA2NA0KMDk6NTc6NDEuMTgzMzk5IElQIDEwLjEwLjEx LjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDU2LCBsZW5n dGggNjQNCjA5OjU3OjQyLjE4NDA2MCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAg ZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDU3LCBsZW5ndGggNjQNCjA5OjU3OjQyLjE4NDM2 NyBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgs IHNlcSA1NywgbGVuZ3RoIDY0DQowOTo1Nzo0My4xODUwMzIgSVAgMTAuMTAuMTEuMSA+IDEwLjEw LjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA1OCwgbGVuZ3RoIDY0DQow OTo1Nzo0My4xODUzNDEgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVw bHksIGlkIDE5ODA4LCBzZXEgNTgsIGxlbmd0aCA2NA0KMDk6NTc6NDQuMTg2MDA2IElQIDEwLjEw LjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNTks IGxlbmd0aCA2NA0KMDk6NTc6NDQuMTg2MzI4IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTog SUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDU5LCBsZW5ndGggNjQNCjA5OjU3OjQ1LjE4 Njk3OCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAx OTgwOCwgc2VxIDYwLCBsZW5ndGggNjQNCjA5OjU3OjQ1LjE4NzMxNSBJUCAxMC4xMC4xMS41MCA+ IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA2MCwgbGVuZ3RoIDY0 DQowOTo1Nzo0Ni4xODc5NDcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8g cmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA2MSwgbGVuZ3RoIDY0DQowOTo1Nzo0Ni4xODgyNTUgSVAg MTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEg NjEsIGxlbmd0aCA2NA0KMDk6NTc6NDcuMTg4OTIxIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41 MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNjIsIGxlbmd0aCA2NA0KMDk6NTc6 NDcuMTg5MjAxIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBp ZCAxOTgwOCwgc2VxIDYyLCBsZW5ndGggNjQNCjA5OjU3OjQ4LjE4OTkwMSBJUCAxMC4xMC4xMS4x ID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDYzLCBsZW5n dGggNjQNCjA5OjU3OjQ4LjE5MDE5MCA1YzpmOTowMDoxNjo3NjozMCAob3VpIFVua25vd24pID4g YjM6MjQ6MDA6MTA6NGI6MmMgKG91aSBVbmtub3duKSwgZXRoZXJ0eXBlIFVua25vd24gKDB4Njgx ZCksIGxlbmd0aCA5ODogDQoJMHgwMDAwOiAgMDgwMCA0NTAwIDE0MDAgMDlkYyAwMDQwIDgwMDYg NWQ4MyAwYTBhICAuLkUuLi4uLi5ALi5dLi4uDQoJMHgwMDEwOiAgMGE2NiA3ZjAwIDAwMDEgMDU0 ZCAwYzM4IGNjNjYgODJhYyAyOGI1ICAuZi4uLi4uTS44LmYuLiguDQoJMHgwMDIwOiAgMDQ3OCA1 MDEwIDQ2ZmYgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwICAueFAuRi4uLi4uLi4uLi4uDQoJMHgw MDMwOiAgNTNjOCA1N2Y2IDlkMDEgMWQxYiA4ZDJiIDdkMWMgZmU0MyBkOTc5ICBTLlcuLi4uLi4r fS4uQy55DQoJMHgwMDQwOiAgNDEzYyA5NDBlIDNhMDYgMzI5ZSA4MjEzIGMyNzEgM2Q0NSBlYzQ1 ICBBPC4uOi4yLi4uLnE9RS5FDQoJMHgwMDUwOiAgNWEyMCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBaLg0KMDk6NTc6NDkuMTkwODY3IElQIDEwLjEwLjExLjEgPiAxMC4xMC4x MS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNjQsIGxlbmd0aCA2NA0KMDk6 NTc6NDkuMTkxMTg0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5 LCBpZCAxOTgwOCwgc2VxIDY0LCBsZW5ndGggNjQNCjA5OjU3OjUwLjE5MTgzNiBJUCAxMC4xMC4x MS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDY1LCBs ZW5ndGggNjQNCjA5OjU3OjUwLjE5MjEzOCAwODo2ZDo2MTo2Mzo2ODo2OSAob3VpIFVua25vd24p ID4gNTQ6MDA6MDA6MDA6ZGU6MDAgKG91aSBVbmtub3duKSwgZXRoZXJ0eXBlIFVua25vd24gKDB4 NmU2NSksIGxlbmd0aCA5ODogDQoJMHgwMDAwOiAgNmU3NSA2ZDYyIDY1NzIgMDAwMCAwMWRmIDY3 MDAgMDEwMCAwMDAwICBudW1iZXIuLi4uZy4uLi4uDQoJMHgwMDEwOiAgMTcwMCAwNGZmIGZmZmYg ZmYwMCAwMDY5IDY0MDAgMDAwMSBkZjdiICAuLi4uLi4uLi5pZC4uLi57DQoJMHgwMDIwOiAgMDAw MSAwMDAwIDAwMTcgMDAwNCBmZmZmIGZmZmYgMDAwMCA2MTY0ICAuLi4uLi4uLi4uLi4uLmFkDQoJ MHgwMDMwOiAgNjQ3MiA2NTczIDczMDAgMDAwMSBkZjdiIDAwMDIgMDAwMCAwMzY1ICBkcmVzcy4u Li57Li4uLi5lDQoJMHgwMDQwOiAgZmZmZiBmZmZmIGZmZmYgMDAwMCA3Mzc0IDYxNzIgNzQwMCAw MDAwICAuLi4uLi4uLnN0YXJ0Li4uDQoJMHgwMDUwOiAgMDAwMCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAuLg0KMDk6NTc6NTEuMTkyODA4IElQIDEwLjEwLjExLjEgPiAxMC4x MC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNjYsIGxlbmd0aCA2NA0K MDk6NTc6NTEuMTkzMDkxIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJl cGx5LCBpZCAxOTgwOCwgc2VxIDY2LCBsZW5ndGggNjQNCjA5OjU3OjUyLjE5Mzc4MSBJUCAxMC4x MC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDY3 LCBsZW5ndGggNjQNCjA5OjU3OjUyLjE5NDA1OSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6 IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA2NywgbGVuZ3RoIDY0DQowOTo1Nzo1My4x OTQ3NTIgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQg MTk4MDgsIHNlcSA2OCwgbGVuZ3RoIDY0DQowOTo1Nzo1My4xOTUwNDQgSVAgMTAuMTAuMTEuNTAg PiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNjgsIGxlbmd0aCA2 NA0KMDk6NTc6NTQuMTk1NzI5IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hv IHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNjksIGxlbmd0aCA2NA0KMDk6NTc6NTQuMTk2MDM3IDVj OmY5OjAwOjEzOmU4OjQ5IChvdWkgVW5rbm93bikgPiBjODoxZTowMDoxMDo0YjoyYyAob3VpIFVu a25vd24pLCBldGhlcnR5cGUgVW5rbm93biAoMHgzZDBkKSwgbGVuZ3RoIDk4OiANCgkweDAwMDA6 ICAwODAwIDQ1MTAgMjAwMCBkNmFhIDAwNDAgNDAwNiAzYjM0IDBhMGEgIC4uRS4uLi4uLkBALjs0 Li4NCgkweDAwMTA6ICAwYWMxIDBhMGEgMGEwMSBlNGE1IDAwMTYgNTkzNSAwNGQ2IGM2ZjcgIC4u Li4uLi4uLi5ZNS4uLi4NCgkweDAwMjA6ICA2YzQzIDgwMTAgZjIwMSAwMDAwIDAwMDAgMDEwMSAw ODBhIDAwNTcgIGxDLi4uLi4uLi4uLi4uLlcNCgkweDAwMzA6ICAxMjBkIDFiNTIgNTkxNSBlNGIw IDMxMjcgY2U3NSAyZjk5IDZhNGQgIC4uLlJZLi4uMScudS8uak0NCgkweDAwNDA6ICA1NmIwIGM2 NmMgYTVkMyAwZWE5IDNlODQgMGMwZSBmNTcwIDE1OGIgIFYuLmwuLi4uPi4uLi5wLi4NCgkweDAw NTA6ICAwZTU5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC5ZDQowOTo1Nzo1 NS4xOTY2OTggSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwg aWQgMTk4MDgsIHNlcSA3MCwgbGVuZ3RoIDY0DQowOTo1Nzo1NS4xOTY5ODggSVAgMTAuMTAuMTEu NTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNzAsIGxlbmd0 aCA2NA0KMDk6NTc6NTYuMTk3NjcwIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBl Y2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNzEsIGxlbmd0aCA2NA0KMDk6NTc6NTYuMTk3OTcw IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwg c2VxIDcxLCBsZW5ndGggNjQNCjA5OjU3OjU3LjE5ODY0MSBJUCAxMC4xMC4xMS4xID4gMTAuMTAu MTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDcyLCBsZW5ndGggNjQNCjA5 OjU3OjU3LjE5ODkyNyBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBs eSwgaWQgMTk4MDgsIHNlcSA3MiwgbGVuZ3RoIDY0DQowOTo1Nzo1OC4xOTk2MjAgSVAgMTAuMTAu MTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA3Mywg bGVuZ3RoIDY0DQowOTo1Nzo1OC4xOTk5MDcgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJ Q01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNzMsIGxlbmd0aCA2NA0KMDk6NTc6NTkuMjAw NTk4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5 ODA4LCBzZXEgNzQsIGxlbmd0aCA2NA0KMDk6NTc6NTkuMjAwODk2IElQIDEwLjEwLjExLjUwID4g MTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDc0LCBsZW5ndGggNjQN CjA5OjU4OjAwLjIwMTU2NCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyBy ZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDc1LCBsZW5ndGggNjQNCjA5OjU4OjAwLjIwMTg4MSBJUCAx MC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA3 NSwgbGVuZ3RoIDY0DQowOTo1ODowMS4yMDI1MzMgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUw OiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA3NiwgbGVuZ3RoIDY0DQowOTo1ODow MS4yMDI4MTYgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlk IDE5ODA4LCBzZXEgNzYsIGxlbmd0aCA2NA0KMDk6NTg6MDIuMjAzNTEwIElQIDEwLjEwLjExLjEg PiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNzcsIGxlbmd0 aCA2NA0KMDk6NTg6MDIuMjAzNzg0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBl Y2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDc3LCBsZW5ndGggNjQNCjA5OjU4OjAzLjIwNDQ4MCBJ UCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwg c2VxIDc4LCBsZW5ndGggNjQNCjA5OjU4OjAzLjIwNDc0OSA1YzpmOTowMDoxNjo3NjozMCAob3Vp IFVua25vd24pID4gNmY6NmU6MDA6MTA6NGI6MmMgKG91aSBVbmtub3duKSwgZXRoZXJ0eXBlIFVu a25vd24gKDB4NjgxZCksIGxlbmd0aCA5ODogDQoJMHgwMDAwOiAgMDAxMCA0YjJjIDVjZjkgMDgw MCA0NTAwIDAwMjggOTBmMyA0MDAwICAuLkssXC4uLkUuLiguLkAuDQoJMHgwMDEwOiAgNzIwNiA3 ODk2IGNmMmUgMWJhOCAwYTBhIDBhNjYgMDc0NyAwNWU2ICByLnguLi4uLi4uLmYuRy4uDQoJMHgw MDIwOiAgMWE5ZCA2NDczIGE1N2QgZGNlZCA1MDEwIGZiMDUgYTZkZiAwMDAwICAuLmRzLn0uLlAu Li4uLi4uDQoJMHgwMDMwOiAgYWFhYSBmYjA1IDFhZDIgMWFlNiBhOTNjIDUzMmYgMzEyZSAzMjJl ICAuLi4uLi4uLi48Uy8xLjIuDQoJMHgwMDQwOiAgMzIzNSAwZDBhIDQ1NTQgNjE2NyAzYTIwIDQ4 NGYgNTQ0ZiA1MjRlICAyNS4uRVRhZzouSE9UT1JODQoJMHgwMDUwOiAgNGY1NCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBPVA0KMDk6NTg6MDQuMjA1NDQ3IElQIDEwLjEwLjEx LjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNzksIGxl bmd0aCA2NA0KMDk6NTg6MDQuMjA1NzQ3IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNN UCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDc5LCBsZW5ndGggNjQNCjA5OjU4OjA1LjIwNjQy NCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgw OCwgc2VxIDgwLCBsZW5ndGggNjQNCjA5OjU4OjA1LjIwNjY5OCBJUCAxMC4xMC4xMS41MCA+IDEw LjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA4MCwgbGVuZ3RoIDY0DQow OTo1ODowNi4yMDczOTkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVx dWVzdCwgaWQgMTk4MDgsIHNlcSA4MSwgbGVuZ3RoIDY0DQowOTo1ODowNi4yMDc2ODggSVAgMTAu MTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgODEs IGxlbmd0aCA2NA0KMDk6NTg6MDcuMjA4MzcyIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDog SUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgODIsIGxlbmd0aCA2NA0KMDk6NTg6MDcu MjA4NjM2IDVjOmY5OjAwOjE2Ojc2OjMwIChvdWkgVW5rbm93bikgPiA3MDozYTowMDoxMDo0Yjoy YyAob3VpIFVua25vd24pLCBldGhlcnR5cGUgVW5rbm93biAoMHg2ODFkKSwgbGVuZ3RoIDk4OiAN CgkweDAwMDA6ICAwODAwIDQ1MDAgMTQwMCAyZmQ5IDAwNDAgODAwNiAzNzg2IDBhMGEgIC4uRS4u Li8uLkAuLjcuLi4NCgkweDAwMTA6ICAwYTY2IDdmMDAgMDAwMSAwNWZhIDBjMzggNWM1ZCAxZTIz IGFkZWQgIC5mLi4uLi4uLjhcXS4jLi4NCgkweDAwMjA6ICBmODVkIDUwMTAgZmZmZiAwMDAwIDAw MDAgMDAwMCAwMDAwIDAwMDAgIC5dUC4uLi4uLi4uLi4uLi4NCgkweDAwMzA6ICAxMzBlIDFiNTIg NWIxYSA2ZGY1IGJhYzkgODNiZSBiZjc5IGU0YWUgIC4uLlJbLm0uLi4uLi55Li4NCgkweDAwNDA6 ICAyOTE5IGQ3YjcgMjEyOSAzNTkxIDM3ODcgODY4MSBiMDY5IDFhYTQgICkuLi4hKTUuNy4uLi5p Li4NCgkweDAwNTA6ICAyNzIxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICch DQowOTo1ODowOC4yMDkzNDUgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8g cmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA4MywgbGVuZ3RoIDY0DQowOTo1ODowOC4yMDk2MDggSVAg MTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEg ODMsIGxlbmd0aCA2NA0KMDk6NTg6MDkuMjEwMzI0IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41 MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgODQsIGxlbmd0aCA2NA0KMDk6NTg6 MDkuMjEwNjE3IDJlOjMwOjIwOjMyOjMwOjMwIChvdWkgVW5rbm93bikgPiA0ODo1NDo1NDo1MDoy ZjozMSAob3VpIFVua25vd24pLCBldGhlcnR5cGUgVW5rbm93biAoMHgyMDRmKSwgbGVuZ3RoIDk4 OiANCgkweDAwMDA6ICA0YjBkIDBhNDQgNjE3NCA2NTNhIDIwNTcgNjU2NCAyYzIwIDMyMzAgIEsu LkRhdGU6LldlZCwuMjANCgkweDAwMTA6ICAyMDQ2IDY1NjIgMjAzMiAzMDMwIDM4MjAgMzIzMyAz YTM1IDM3M2EgIC5GZWIuMjAwOC4yMzo1NzoNCgkweDAwMjA6ICAzMDMzIDIwNDcgNGQ1NCAwZDBh IDUzNjUgNzI3NiA2NTcyIDNhMjAgIDAzLkdNVC4uU2VydmVyOi4NCgkweDAwMzA6ICA0ZDY5IDYz NzIgNmY3MyA2ZjY2IDc0MmQgNDk0OSA1MzJmIDM2MmUgIE1pY3Jvc29mdC1JSVMvNi4NCgkweDAw NDA6ICAzMDBkIDBhNTAgMzM1MCAzYTIwIDQzNTAgM2QyMiA0MjU1IDUzMjAgIDAuLlAzUDouQ1A9 IkJVUy4NCgkweDAwNTA6ICA0MzU1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IENVDQowOTo1ODoxMC4yMTEyODcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVj aG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA4NSwgbGVuZ3RoIDY0DQowOTo1ODoxMC4yMTE1NTkg SVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBz ZXEgODUsIGxlbmd0aCA2NA0KMDk6NTg6MTEuMjEyMjcxIElQIDEwLjEwLjExLjEgPiAxMC4xMC4x MS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgODYsIGxlbmd0aCA2NA0KMDk6 NTg6MTEuMjEyNTQxIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5 LCBpZCAxOTgwOCwgc2VxIDg2LCBsZW5ndGggNjQNCjA5OjU4OjEyLjIxMzI0MSBJUCAxMC4xMC4x MS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDg3LCBs ZW5ndGggNjQNCjA5OjU4OjEzLjIxNDIwMiBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElD TVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDg4LCBsZW5ndGggNjQNCjA5OjU4OjEzLjIx NDQ5NiBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4 MDgsIHNlcSA4OCwgbGVuZ3RoIDY0DQowOTo1ODoxNC4yMTUxNzcgSVAgMTAuMTAuMTEuMSA+IDEw LjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA4OSwgbGVuZ3RoIDY0 DQowOTo1ODoxNC4yMTU0ODIgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8g cmVwbHksIGlkIDE5ODA4LCBzZXEgODksIGxlbmd0aCA2NA0KMDk6NTg6MTUuMjE2MTQ0IElQIDEw LjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEg OTAsIGxlbmd0aCA2NA0KMDk6NTg6MTUuMjE2NDQxIDVjOmY5OjAwOjE2Ojc2OjMwIChvdWkgVW5r bm93bikgPiA1MTowMDowMDoxMDo0YjoyYyAob3VpIFVua25vd24pLCBldGhlcnR5cGUgVW5rbm93 biAoMHg2ODFkKSwgbGVuZ3RoIDk4OiANCgkweDAwMDA6ICAwODAwIDQ1MDAgMTQwMCAzMTg0IDAw NDAgODAwNiAzNWRiIDBhMGEgIC4uRS4uLjEuLkAuLjUuLi4NCgkweDAwMTA6ICAwYTY2IDdmMDAg MDAwMSAwNjFiIDBjMzggZGE5NCBiMjk4IGQ4MWMgIC5mLi4uLi4uLjguLi4uLi4NCgkweDAwMjA6 ICBhMTE4IDUwMTAgZmZmZiAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgIC4uUC4uLi4uLi4uLi4u Li4NCgkweDAwMzA6ICA2YjYxIDZkNjEgNjkwMyA2ZTY1IDc0MDAgMDAwMSAwMDAxIGMwMGMgIGth bWFpLm5ldC4uLi4uLi4NCgkweDAwNDA6ICAwMDAxIDAwMDEgMDAwMCAwYzU5IDAwMDQgYTUxNSAy MDY0IGMwMTAgIC4uLi4uLi5ZLi4uLi5kLi4NCgkweDAwNTA6ICAwMDAyICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC4uDQowOTo1ODoxNi4yMTcxMTQgSVAgMTAuMTAuMTEuMSA+ IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA5MSwgbGVuZ3Ro IDY0DQowOTo1ODoxNi4yMTc0MDkgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVj aG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgOTEsIGxlbmd0aCA2NA0KMDk6NTg6MTcuMjE4MDg2IElQ IDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBz ZXEgOTIsIGxlbmd0aCA2NA0KMDk6NTg6MTguMjE5MDU3IElQIDEwLjEwLjExLjEgPiAxMC4xMC4x MS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgOTMsIGxlbmd0aCA2NA0KMDk6 NTg6MTguMjE5MzY1IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5 LCBpZCAxOTgwOCwgc2VxIDkzLCBsZW5ndGggNjQNCjA5OjU4OjE5LjIyMDAzNiBJUCAxMC4xMC4x MS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDk0LCBs ZW5ndGggNjQNCjA5OjU4OjE5LjIzMjQ3OSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElD TVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA5NCwgbGVuZ3RoIDY0DQowOTo1ODoyMC4yMjEw MDkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4 MDgsIHNlcSA5NSwgbGVuZ3RoIDY0DQowOTo1ODoyMC4yMjEyOTkgSVAgMTAuMTAuMTEuNTAgPiAx MC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgOTUsIGxlbmd0aCA2NA0K MDk6NTg6MjEuMjIxOTgzIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJl cXVlc3QsIGlkIDE5ODA4LCBzZXEgOTYsIGxlbmd0aCA2NA0KMDk6NTg6MjEuMjIyMjgwIElQIDEw LjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDk2 LCBsZW5ndGggNjQNCjA5OjU4OjIyLjIyMjk1MiBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6 IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDk3LCBsZW5ndGggNjQNCjA5OjU4OjIy LjIyMzI0MSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQg MTk4MDgsIHNlcSA5NywgbGVuZ3RoIDY0DQowOTo1ODoyMy4yMjM5MjggSVAgMTAuMTAuMTEuMSA+ IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA5OCwgbGVuZ3Ro IDY0DQowOTo1ODoyMy4yMjQyMTMgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVj aG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgOTgsIGxlbmd0aCA2NA0KMDk6NTg6MjQuMjI0ODk2IElQ IDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBz ZXEgOTksIGxlbmd0aCA2NA0KMDk6NTg6MjQuMjI1MjE5IDVjOmY5OjAwOjE2Ojc2OjMwIChvdWkg VW5rbm93bikgPiA0ODo1NDowMDoxMDo0YjoyYyAob3VpIFVua25vd24pLCBldGhlcnR5cGUgVW5r bm93biAoMHg2ODFkKSwgbGVuZ3RoIDk4OiANCgkweDAwMDA6ICAwODAwIDQ1MDAgNjUwMSAzMGY4 IDAwNDAgODAwNiAzNTE2IDBhMGEgIC4uRS5lLjAuLkAuLjUuLi4NCgkweDAwMTA6ICAwYTY2IDdm MDAgMDAwMSAwNjE1IDBjMzggNzA5MSAwOTQ3IGUxY2MgIC5mLi4uLi4uLjhwLi5HLi4NCgkweDAw MjA6ICBhNmRlIDUwMTggZmZmZiAwMDAwIDAwMDAgNDc0NSA1NDIwIDJmNmQgIC4uUC4uLi4uLi5H RVQuL20NCgkweDAwMzA6ICA2MTY5IDZjMmYgMzEzMiAyZTMxIDJlMzAgMzAzNiAzOTJlIDMxMzIg IGFpbC8xMi4xLjAwNjkuMTINCgkweDAwNDA6ICAzMTMzIDJmNGMgNjk2NyA2ODc0IDJlNmEgNzMy MCA0ODU0IDU0NTAgIDEzL0xpZ2h0LmpzLkhUVFANCgkweDAwNTA6ICAyZjMxICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC8xDQpeQw0KMTk3IHBhY2tldHMgY2FwdHVyZWQNCjE5 NyBwYWNrZXRzIHJlY2VpdmVkIGJ5IGZpbHRlcg0KMCBwYWNrZXRzIGRyb3BwZWQgYnkga2VybmVs DQpyb2JiYWtAZ3c6fiAwICQgZXhpdA0KClNjcmlwdCBkb25lIG9uIFRodSBGZWIgMjEgMDk6NTk6 NDMgMjAwOAo= ------=_Part_349_32900395.1203555782162 Content-Type: application/octet-stream; name=remote-tcpdump Content-Transfer-Encoding: base64 X-Attachment-Id: f_fcwlydju2 Content-Disposition: attachment; filename=remote-tcpdump U2NyaXB0IHN0YXJ0ZWQgb24gVGh1IEZlYiAyMSAwOTo1NTozMiAyMDA4CnJvYmJha0BvbGQtZ3c6 fiAwICQgdGNwZHVtcCAtaSBzaXMwDQp0Y3BkdW1wOiAobm8gZGV2aWNlcyBmb3VuZCkgL2Rldi9i cGYwOiBQZXJtaXNzaW9uIGRlbmllZA0Kcm9iYmFrQG9sZC1ndzp+IDEgJCB0Y3BkdW1wIC1pIHNp czAICAgICAgICAgICAgICAgHG1s0aHMbWzRsG1s0aHUbWzRsG1s0aGQbWzRsG1s0aG8bWzRsG1s0 aCAbWzRsDQpQYXNzd29yZDoNCnRjcGR1bXA6IHZlcmJvc2Ugb3V0cHV0IHN1cHByZXNzZWQsIHVz ZSAtdiBvciAtdnYgZm9yIGZ1bGwgcHJvdG9jb2wgZGVjb2RlDQpsaXN0ZW5pbmcgb24gc2lzMCwg bGluay10eXBlIEVOMTBNQiAoRXRoZXJuZXQpLCBjYXB0dXJlIHNpemUgOTYgYnl0ZXMNCjA5OjU2 OjQ1LjkyNjMwMSBhcnAgd2hvLWhhcyAxMC4xMC4xMS41MCB0ZWxsIDEwLjEwLjExLjENCjA5OjU2 OjQ1LjkyNjU3OCBhcnAgcmVwbHkgMTAuMTAuMTEuNTAgaXMtYXQgMDA6MTE6NWI6YjE6OWQ6YjEg KG91aSBVbmtub3duKQ0KMDk6NTY6NDUuOTI2NzEyIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41 MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMCwgbGVuZ3RoIDY0DQowOTo1Njo0 NS45MjY4NTAgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlk IDE5ODA4LCBzZXEgMCwgbGVuZ3RoIDY0DQowOTo1Njo0Ni45Mjc1NDcgSVAgMTAuMTAuMTEuMSA+ IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxLCBsZW5ndGgg NjQNCjA5OjU2OjQ2LjkyNzY5NSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNo byByZXBseSwgaWQgMTk4MDgsIHNlcSAxLCBsZW5ndGggNjQNCjA5OjU2OjQ3LjkyODUyNSBJUCAx MC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2Vx IDIsIGxlbmd0aCA2NA0KMDk6NTY6NDcuOTI4NjU5IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEu MTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDIsIGxlbmd0aCA2NA0KMDk6NTY6NDgu OTI5NTA5IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlk IDE5ODA4LCBzZXEgMywgbGVuZ3RoIDY0DQowOTo1Njo0OC45Mjk2NTMgSVAgMTAuMTAuMTEuNTAg PiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMywgbGVuZ3RoIDY0 DQowOTo1Njo0OS45MzA0OTEgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8g cmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA0LCBsZW5ndGggNjQNCjA5OjU2OjQ5LjkzMDY0NyBJUCAx MC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA0 LCBsZW5ndGggNjQNCjA5OjU2OjUwLjkzMTQ3MSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6 IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDUsIGxlbmd0aCA2NA0KMDk6NTY6NTAu OTMxNjIwIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAx OTgwOCwgc2VxIDUsIGxlbmd0aCA2NA0KMDk6NTY6NTEuOTMyNDQzIElQIDEwLjEwLjExLjEgPiAx MC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNiwgbGVuZ3RoIDY0 DQowOTo1Njo1MS45MzI1NzggSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8g cmVwbHksIGlkIDE5ODA4LCBzZXEgNiwgbGVuZ3RoIDY0DQowOTo1Njo1Mi45MzM0MjggSVAgMTAu MTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA3 LCBsZW5ndGggNjQNCjA5OjU2OjUyLjkzMzU2MCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6 IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA3LCBsZW5ndGggNjQNCjA5OjU2OjUzLjkz NDQxMiBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAx OTgwOCwgc2VxIDgsIGxlbmd0aCA2NA0KMDk6NTY6NTMuOTM0NTU2IElQIDEwLjEwLjExLjUwID4g MTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDgsIGxlbmd0aCA2NA0K MDk6NTY6NTQuOTM1NDA1IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJl cXVlc3QsIGlkIDE5ODA4LCBzZXEgOSwgbGVuZ3RoIDY0DQowOTo1Njo1NC45MzU1ODggSVAgMTAu MTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgOSwg bGVuZ3RoIDY0DQowOTo1Njo1NS45MzYzNzUgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJ Q01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxMCwgbGVuZ3RoIDY0DQowOTo1Njo1NS45 MzY1MzAgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5 ODA4LCBzZXEgMTAsIGxlbmd0aCA2NA0KMDk6NTY6NTYuOTM3MzYwIElQIDEwLjEwLjExLjEgPiAx MC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMTEsIGxlbmd0aCA2 NA0KMDk6NTY6NTYuOTM3NTExIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hv IHJlcGx5LCBpZCAxOTgwOCwgc2VxIDExLCBsZW5ndGggNjQNCjA5OjU2OjU3LjkzODMzMyBJUCAx MC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2Vx IDEyLCBsZW5ndGggNjQNCjA5OjU2OjU3LjkzODQ3NSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjEx LjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAxMiwgbGVuZ3RoIDY0DQowOTo1Njo1 OC45MzkzMTkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwg aWQgMTk4MDgsIHNlcSAxMywgbGVuZ3RoIDY0DQowOTo1Njo1OC45Mzk0NTIgSVAgMTAuMTAuMTEu NTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMTMsIGxlbmd0 aCA2NA0KMDk6NTY6NTkuOTQwMzE4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBl Y2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMTQsIGxlbmd0aCA2NA0KMDk6NTY6NTkuOTQwNDg3 IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwg c2VxIDE0LCBsZW5ndGggNjQNCjA5OjU3OjAwLjk0MTI4MyBJUCAxMC4xMC4xMS4xID4gMTAuMTAu MTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDE1LCBsZW5ndGggNjQNCjA5 OjU3OjAwLjk0MTQ0MCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBs eSwgaWQgMTk4MDgsIHNlcSAxNSwgbGVuZ3RoIDY0DQowOTo1NzowMS45NDIyNzEgSVAgMTAuMTAu MTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxNiwg bGVuZ3RoIDY0DQowOTo1NzowMS45NDI0MjUgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJ Q01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMTYsIGxlbmd0aCA2NA0KMDk6NTc6MDIuOTQz MjQzIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5 ODA4LCBzZXEgMTcsIGxlbmd0aCA2NA0KMDk6NTc6MDIuOTQzMzg2IElQIDEwLjEwLjExLjUwID4g MTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDE3LCBsZW5ndGggNjQN CjA5OjU3OjAzLjk0NDIyOSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyBy ZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDE4LCBsZW5ndGggNjQNCjA5OjU3OjAzLjk0NDM3NCBJUCAx MC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAx OCwgbGVuZ3RoIDY0DQowOTo1NzowNC45NDUyMTcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUw OiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAxOSwgbGVuZ3RoIDY0DQowOTo1Nzow NC45NDUzNzggSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlk IDE5ODA4LCBzZXEgMTksIGxlbmd0aCA2NA0KMDk6NTc6MDUuOTQ2MTc5IElQIDEwLjEwLjExLjEg PiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMjAsIGxlbmd0 aCA2NA0KMDk6NTc6MDUuOTQ2MzI0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBl Y2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDIwLCBsZW5ndGggNjQNCjA5OjU3OjA2Ljk0NzE2OCBJ UCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwg c2VxIDIxLCBsZW5ndGggNjQNCjA5OjU3OjA2Ljk0NzMwNyBJUCAxMC4xMC4xMS41MCA+IDEwLjEw LjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAyMSwgbGVuZ3RoIDY0DQowOTo1 NzowNy45NDgxNDcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVz dCwgaWQgMTk4MDgsIHNlcSAyMiwgbGVuZ3RoIDY0DQowOTo1NzowNy45NDgyODQgSVAgMTAuMTAu MTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMjIsIGxl bmd0aCA2NA0KMDk6NTc6MDguOTQ5MTE4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNN UCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMjMsIGxlbmd0aCA2NA0KMDk6NTc6MDguOTQ5 MjUxIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgw OCwgc2VxIDIzLCBsZW5ndGggNjQNCjA5OjU3OjA5Ljk1MDExMSBJUCAxMC4xMC4xMS4xID4gMTAu MTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDI0LCBsZW5ndGggNjQN CjA5OjU3OjA5Ljk1MDI0NiBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyBy ZXBseSwgaWQgMTk4MDgsIHNlcSAyNCwgbGVuZ3RoIDY0DQowOTo1NzoxMC45NTEwODcgSVAgMTAu MTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAy NSwgbGVuZ3RoIDY0DQowOTo1NzoxMC45NTEyMTIgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4x OiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMjUsIGxlbmd0aCA2NA0KMDk6NTc6MTEu OTYyOTQyIElQIHJ2LWluLWYxOC5nb29nbGUuY29tLmh0dHBzID4gMTAuMTAuMTAuMTkzLjQyMTI4 OiBSIDI5NjI1Mzg1Mjc6Mjk2MjUzODUyNygwKSB3aW4gMA0KMDk6NTc6MTIuOTUzMDUyIElQIDEw LjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEg MjcsIGxlbmd0aCA2NA0KMDk6NTc6MTIuOTUzMjA3IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEu MTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDI3LCBsZW5ndGggNjQNCjA5OjU3OjEz Ljk1NDA0NSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBp ZCAxOTgwOCwgc2VxIDI4LCBsZW5ndGggNjQNCjA5OjU3OjEzLjk1NDIxMSBJUCAxMC4xMC4xMS41 MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAyOCwgbGVuZ3Ro IDY0DQowOTo1NzoxNC45NTUwMjcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVj aG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAyOSwgbGVuZ3RoIDY0DQowOTo1NzoxNC45NTUyMDQg SVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBz ZXEgMjksIGxlbmd0aCA2NA0KMDk6NTc6MTUuOTU2MDA1IElQIDEwLjEwLjExLjEgPiAxMC4xMC4x MS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMzAsIGxlbmd0aCA2NA0KMDk6 NTc6MTUuOTU2MTY3IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5 LCBpZCAxOTgwOCwgc2VxIDMwLCBsZW5ndGggNjQNCjA5OjU3OjE2Ljk1Njk5MiBJUCAxMC4xMC4x MS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDMxLCBs ZW5ndGggNjQNCjA5OjU3OjE2Ljk1NzE2MSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElD TVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAzMSwgbGVuZ3RoIDY0DQowOTo1NzoxNy45NTc5 NjAgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4 MDgsIHNlcSAzMiwgbGVuZ3RoIDY0DQowOTo1NzoxNy45NTgxMjAgSVAgMTAuMTAuMTEuNTAgPiAx MC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMzIsIGxlbmd0aCA2NA0K MDk6NTc6MTguOTU4OTQzIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJl cXVlc3QsIGlkIDE5ODA4LCBzZXEgMzMsIGxlbmd0aCA2NA0KMDk6NTc6MTguOTU5MTAwIElQIDEw LjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDMz LCBsZW5ndGggNjQNCjA5OjU3OjE5Ljk1OTkyNiBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6 IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDM0LCBsZW5ndGggNjQNCjA5OjU3OjE5 Ljk2MDA5MiBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQg MTk4MDgsIHNlcSAzNCwgbGVuZ3RoIDY0DQowOTo1NzoyMC45NjA5MDQgSVAgMTAuMTAuMTEuMSA+ IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAzNSwgbGVuZ3Ro IDY0DQowOTo1NzoyMC45NjEwNzIgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVj aG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgMzUsIGxlbmd0aCA2NA0KMDk6NTc6MjEuOTYxODkyIElQ IDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBz ZXEgMzYsIGxlbmd0aCA2NA0KMDk6NTc6MjEuOTYyMDU4IElQIDEwLjEwLjExLjUwID4gMTAuMTAu MTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDM2LCBsZW5ndGggNjQNCjA5OjU3 OjIyLjk2Mjg2OSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0 LCBpZCAxOTgwOCwgc2VxIDM3LCBsZW5ndGggNjQNCjA5OjU3OjIyLjk2MzAzNiBJUCAxMC4xMC4x MS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSAzNywgbGVu Z3RoIDY0DQowOTo1NzoyMy45NjM4NDkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01Q IGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSAzOCwgbGVuZ3RoIDY0DQowOTo1NzoyMy45NjQw MDcgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4 LCBzZXEgMzgsIGxlbmd0aCA2NA0KMDk6NTc6MjQuOTY0ODMzIElQIDEwLjEwLjExLjEgPiAxMC4x MC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgMzksIGxlbmd0aCA2NA0K MDk6NTc6MjQuOTY1MDAxIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJl cGx5LCBpZCAxOTgwOCwgc2VxIDM5LCBsZW5ndGggNjQNCjA5OjU3OjI1Ljk2NTgxMyBJUCAxMC4x MC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDQw LCBsZW5ndGggNjQNCjA5OjU3OjI1Ljk2NTk2NCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6 IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA0MCwgbGVuZ3RoIDY0DQowOTo1NzoyNi45 NjY3ODkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQg MTk4MDgsIHNlcSA0MSwgbGVuZ3RoIDY0DQowOTo1NzoyNi45NjY5NTMgSVAgMTAuMTAuMTEuNTAg PiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNDEsIGxlbmd0aCA2 NA0KMDk6NTc6MjcuOTY3Nzc0IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hv IHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNDIsIGxlbmd0aCA2NA0KMDk6NTc6MjcuOTY3OTM1IElQ IDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2Vx IDQyLCBsZW5ndGggNjQNCjA5OjU3OjI4Ljk2ODc1MSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEu NTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDQzLCBsZW5ndGggNjQNCjA5OjU3 OjI4Ljk2ODkwOSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwg aWQgMTk4MDgsIHNlcSA0MywgbGVuZ3RoIDY0DQowOTo1NzoyOS45Njk3NDAgSVAgMTAuMTAuMTEu MSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA0NCwgbGVu Z3RoIDY0DQowOTo1NzoyOS45Njk5MDMgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01Q IGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNDQsIGxlbmd0aCA2NA0KMDk6NTc6MzAuOTcwNzE3 IElQIDEwLjEwLjEwLjE5My41ODUzMyA+IGZyZWViaWUuZmxleGkucm9iYmFrLmNvbS5zc2g6IC4g YWNrIDExMzEyMTkyMDYgd2luIDQ4NyA8bm9wLG5vcCx0aW1lc3RhbXAgNTcxNzg0OSA0NTg0Mjc5 NzI+DQowOTo1NzozMS45NzE2OTkgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVj aG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA0NiwgbGVuZ3RoIDY0DQowOTo1NzozMS45NzE4NjQg SVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBz ZXEgNDYsIGxlbmd0aCA2NA0KMDk6NTc6MzIuOTcyNjczIElQIDEwLjEwLjExLjEgPiAxMC4xMC4x MS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNDcsIGxlbmd0aCA2NA0KMDk6 NTc6MzIuOTcyODI4IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5 LCBpZCAxOTgwOCwgc2VxIDQ3LCBsZW5ndGggNjQNCjA5OjU3OjMzLjk3MzY1OCBJUCAxMC4xMC4x MS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDQ4LCBs ZW5ndGggNjQNCjA5OjU3OjMzLjk3MzgxOCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElD TVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA0OCwgbGVuZ3RoIDY0DQowOTo1NzozNC45NzQ2 NTEgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4 MDgsIHNlcSA0OSwgbGVuZ3RoIDY0DQowOTo1NzozNC45NzQ4MjQgSVAgMTAuMTAuMTEuNTAgPiAx MC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNDksIGxlbmd0aCA2NA0K MDk6NTc6MzUuOTc1NjI3IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJl cXVlc3QsIGlkIDE5ODA4LCBzZXEgNTAsIGxlbmd0aCA2NA0KMDk6NTc6MzUuOTc1Nzc4IElQIDEw LjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDUw LCBsZW5ndGggNjQNCjA5OjU3OjM2Ljk3NjYwNCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6 IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDUxLCBsZW5ndGggNjQNCjA5OjU3OjM2 Ljk3Njc2MyBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQg MTk4MDgsIHNlcSA1MSwgbGVuZ3RoIDY0DQowOTo1NzozNy45Nzc1ODQgSVAgMTAuMTAuMTEuMSA+ IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA1MiwgbGVuZ3Ro IDY0DQowOTo1NzozNy45Nzc3NDYgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVj aG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNTIsIGxlbmd0aCA2NA0KMDk6NTc6MzguOTc4NTY1IElQ IDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBz ZXEgNTMsIGxlbmd0aCA2NA0KMDk6NTc6MzguOTc4NzI1IElQIDEwLjEwLjExLjUwID4gMTAuMTAu MTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDUzLCBsZW5ndGggNjQNCjA5OjU3 OjM5Ljk3OTU1MyBJUCBtYW5hZ2VyLmZsZXhpLnJvYmJhay5jb20uZmMtY2xpID4gZnJlZWJpZS5m bGV4aS5yb2JiYWsuY29tLmh0dHA6IC4gYWNrIDI2MDM0MTE2NjUgd2luIDYzMDUzDQowOTo1Nzo0 MC45ODA1NDIgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwg aWQgMTk4MDgsIHNlcSA1NSwgbGVuZ3RoIDY0DQowOTo1Nzo0MC45ODA3MjEgSVAgMTAuMTAuMTEu NTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNTUsIGxlbmd0 aCA2NA0KMDk6NTc6NDEuOTgxNTEzIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBl Y2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNTYsIGxlbmd0aCA2NA0KMDk6NTc6NDEuOTgxNjg4 IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwg c2VxIDU2LCBsZW5ndGggNjQNCjA5OjU3OjQyLjk4MjQ4OSBJUCAxMC4xMC4xMS4xID4gMTAuMTAu MTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDU3LCBsZW5ndGggNjQNCjA5 OjU3OjQyLjk4MjY2NSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBs eSwgaWQgMTk4MDgsIHNlcSA1NywgbGVuZ3RoIDY0DQowOTo1Nzo0My45ODM0NzMgSVAgMTAuMTAu MTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA1OCwg bGVuZ3RoIDY0DQowOTo1Nzo0My45ODM2NDggSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJ Q01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNTgsIGxlbmd0aCA2NA0KMDk6NTc6NDQuOTg0 NDU2IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5 ODA4LCBzZXEgNTksIGxlbmd0aCA2NA0KMDk6NTc6NDQuOTg0NjQ0IElQIDEwLjEwLjExLjUwID4g MTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDU5LCBsZW5ndGggNjQN CjA5OjU3OjQ1Ljk4NTQ0MSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyBy ZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDYwLCBsZW5ndGggNjQNCjA5OjU3OjQ1Ljk4NTY0MCBJUCAx MC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA2 MCwgbGVuZ3RoIDY0DQowOTo1Nzo0Ni45ODY0MTAgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUw OiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA2MSwgbGVuZ3RoIDY0DQowOTo1Nzo0 Ni45ODY1ODkgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlk IDE5ODA4LCBzZXEgNjEsIGxlbmd0aCA2NA0KMDk6NTc6NDcuOTg3MzkwIElQIDEwLjEwLjExLjEg PiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNjIsIGxlbmd0 aCA2NA0KMDk6NTc6NDcuOTg3NTQ0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBl Y2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDYyLCBsZW5ndGggNjQNCjA5OjU3OjQ4Ljk4ODM4MSBJ UCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwg c2VxIDYzLCBsZW5ndGggNjQNCjA5OjU3OjQ4Ljk4ODU0MSBJUCAxMC4xMC4xMS41MCA+IDEwLjEw LjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA2MywgbGVuZ3RoIDY0DQowOTo1 Nzo0OS45ODkzNjUgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVz dCwgaWQgMTk4MDgsIHNlcSA2NCwgbGVuZ3RoIDY0DQowOTo1Nzo0OS45ODk1NDUgSVAgMTAuMTAu MTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNjQsIGxl bmd0aCA2NA0KMDk6NTc6NTAuOTkwMzM1IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNN UCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNjUsIGxlbmd0aCA2NA0KMDk6NTc6NTAuOTkw NTA3IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgw OCwgc2VxIDY1LCBsZW5ndGggNjQNCjA5OjU3OjUxLjk5MTMxMCBJUCAxMC4xMC4xMS4xID4gMTAu MTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDY2LCBsZW5ndGggNjQN CjA5OjU3OjUxLjk5MTQ3MCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyBy ZXBseSwgaWQgMTk4MDgsIHNlcSA2NiwgbGVuZ3RoIDY0DQowOTo1Nzo1Mi45OTIyOTEgSVAgMTAu MTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA2 NywgbGVuZ3RoIDY0DQowOTo1Nzo1Mi45OTI0NDYgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4x OiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNjcsIGxlbmd0aCA2NA0KMDk6NTc6NTMu OTkzMjc4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlk IDE5ODA4LCBzZXEgNjgsIGxlbmd0aCA2NA0KMDk6NTc6NTMuOTkzNDQyIElQIDEwLjEwLjExLjUw ID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDY4LCBsZW5ndGgg NjQNCjA5OjU3OjU0Ljk5NDI2NSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNo byByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDY5LCBsZW5ndGggNjQNCjA5OjU3OjU0Ljk5NDQ0MyBJ UCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNl cSA2OSwgbGVuZ3RoIDY0DQowOTo1Nzo1NS45OTUyMzcgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjEx LjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA3MCwgbGVuZ3RoIDY0DQowOTo1 Nzo1NS45OTU0MDMgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHks IGlkIDE5ODA4LCBzZXEgNzAsIGxlbmd0aCA2NA0KMDk6NTc6NTYuOTk2MjQwIElQIDEwLjEwLjEx LjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNzEsIGxl bmd0aCA2NA0KMDk6NTc6NTYuOTk2Mzk0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNN UCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDcxLCBsZW5ndGggNjQNCjA5OjU3OjU3Ljk5NzIx NiBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgw OCwgc2VxIDcyLCBsZW5ndGggNjQNCjA5OjU3OjU3Ljk5NzM2MCBJUCAxMC4xMC4xMS41MCA+IDEw LjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA3MiwgbGVuZ3RoIDY0DQow OTo1Nzo1OC45OTgyMTQgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVx dWVzdCwgaWQgMTk4MDgsIHNlcSA3MywgbGVuZ3RoIDY0DQowOTo1Nzo1OC45OTgzNDggSVAgMTAu MTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNzMs IGxlbmd0aCA2NA0KMDk6NTc6NTkuOTk5MTkzIElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDog SUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgNzQsIGxlbmd0aCA2NA0KMDk6NTc6NTku OTk5MzQ2IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAx OTgwOCwgc2VxIDc0LCBsZW5ndGggNjQNCjA5OjU4OjAxLjAwMDE3MiBJUCAxMC4xMC4xMS4xID4g MTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDc1LCBsZW5ndGgg NjQNCjA5OjU4OjAxLjAwMDM0MCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNo byByZXBseSwgaWQgMTk4MDgsIHNlcSA3NSwgbGVuZ3RoIDY0DQowOTo1ODowMi4wMDExNDMgSVAg MTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNl cSA3NiwgbGVuZ3RoIDY0DQowOTo1ODowMi4wMDEyODQgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4x MS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgNzYsIGxlbmd0aCA2NA0KMDk6NTg6 MDMuMDAyMTI2IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3Qs IGlkIDE5ODA4LCBzZXEgNzcsIGxlbmd0aCA2NA0KMDk6NTg6MDMuMDAyMjYwIElQIDEwLjEwLjEx LjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDc3LCBsZW5n dGggNjQNCjA5OjU4OjA0LjAwMzA5NSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAg ZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDc4LCBsZW5ndGggNjQNCjA5OjU4OjA0LjAwMzIz NSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgs IHNlcSA3OCwgbGVuZ3RoIDY0DQowOTo1ODowNS4wMDQwODIgSVAgMTAuMTAuMTEuMSA+IDEwLjEw LjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA3OSwgbGVuZ3RoIDY0DQow OTo1ODowNS4wMDQyNDIgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVw bHksIGlkIDE5ODA4LCBzZXEgNzksIGxlbmd0aCA2NA0KMDk6NTg6MDYuMDA1MDU1IElQIDEwLjEw LjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgODAs IGxlbmd0aCA2NA0KMDk6NTg6MDYuMDA1MjAyIElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTog SUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDgwLCBsZW5ndGggNjQNCjA5OjU4OjA3LjAw NjA0MyBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAx OTgwOCwgc2VxIDgxLCBsZW5ndGggNjQNCjA5OjU4OjA3LjAwNjE5OSBJUCAxMC4xMC4xMS41MCA+ IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA4MSwgbGVuZ3RoIDY0 DQowOTo1ODowOC4wMDcwMjEgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8g cmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA4MiwgbGVuZ3RoIDY0DQowOTo1ODowOC4wMDcxNTcgSVAg MTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEg ODIsIGxlbmd0aCA2NA0KMDk6NTg6MDkuMDA3OTk4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41 MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgODMsIGxlbmd0aCA2NA0KMDk6NTg6 MDkuMDA4MTM4IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBp ZCAxOTgwOCwgc2VxIDgzLCBsZW5ndGggNjQNCjA5OjU4OjEwLjAwODk5OSBJUCAxMC4xMC4xMS4x ID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDg0LCBsZW5n dGggNjQNCjA5OjU4OjEwLjAwOTE1NiBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAg ZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA4NCwgbGVuZ3RoIDY0DQowOTo1ODoxMS4wMDk5NjEg SVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgs IHNlcSA4NSwgbGVuZ3RoIDY0DQowOTo1ODoxMS4wMTAxMDcgSVAgMTAuMTAuMTEuNTAgPiAxMC4x MC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgODUsIGxlbmd0aCA2NA0KMDk6 NTg6MTIuMDEwOTU0IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVl c3QsIGlkIDE5ODA4LCBzZXEgODYsIGxlbmd0aCA2NA0KMDk6NTg6MTIuMDExMDk4IElQIDEwLjEw LjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDg2LCBs ZW5ndGggNjQNCjA5OjU4OjEzLjAxMTkyMiBJUCB0cnVuY2F0ZWQtaXAgLSAzNjQgYnl0ZXMgbWlz c2luZyEgMTAuMTAuMTAuMTAyLjE1ODQgPiB3d3cucnN2cC5jb20uYXUuaHR0cDogUCAzMDYzMzMz NjgwOjMwNjMzMzQwODgoNDA4KSBhY2sgMTU3MTcyMTE0NiB3aW4gNjQ0NTgNCjA5OjU4OjE0LjAx MjkwMSBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAx OTgwOCwgc2VxIDg4LCBsZW5ndGggNjQNCjA5OjU4OjE0LjAxMzA3MSBJUCAxMC4xMC4xMS41MCA+ IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA4OCwgbGVuZ3RoIDY0 DQowOTo1ODoxNS4wMTM4OTQgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8g cmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA4OSwgbGVuZ3RoIDY0DQowOTo1ODoxNS4wMTQwNjUgSVAg MTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEg ODksIGxlbmd0aCA2NA0KMDk6NTg6MTYuMDE0ODY1IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41 MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgOTAsIGxlbmd0aCA2NA0KMDk6NTg6 MTYuMDE1MDM0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBp ZCAxOTgwOCwgc2VxIDkwLCBsZW5ndGggNjQNCjA5OjU4OjE3LjAxNTg1MCBJUCAxMC4xMC4xMS4x ID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDkxLCBsZW5n dGggNjQNCjA5OjU4OjE3LjAxNjAxMSBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAg ZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA5MSwgbGVuZ3RoIDY0DQowOTo1ODoxOC4wMTY4MzEg SVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBz ZXEgOTAsIGxlbmd0aCA2NA0KMDk6NTg6MTkuMDE3ODIwIElQIDEwLjEwLjExLjEgPiAxMC4xMC4x MS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBzZXEgOTMsIGxlbmd0aCA2NA0KMDk6 NTg6MTkuMDE3OTg0IElQIDEwLjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5 LCBpZCAxOTgwOCwgc2VxIDkzLCBsZW5ndGggNjQNCjA5OjU4OjIwLjAzMDkzMiBJUCAxMC4xMC4x MS4xID4gMTAuMTAuMTEuNTA6IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDk0LCBs ZW5ndGggNjQNCjA5OjU4OjIwLjAzMTEwOCBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElD TVAgZWNobyByZXBseSwgaWQgMTk4MDgsIHNlcSA5NCwgbGVuZ3RoIDY0DQowOTo1ODoyMS4wMTk3 ODAgSVAgMTAuMTAuMTEuMSA+IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4 MDgsIHNlcSA5NSwgbGVuZ3RoIDY0DQowOTo1ODoyMS4wMTk5MzYgSVAgMTAuMTAuMTEuNTAgPiAx MC4xMC4xMS4xOiBJQ01QIGVjaG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgOTUsIGxlbmd0aCA2NA0K MDk6NTg6MjIuMDIwNzY4IElQIDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJl cXVlc3QsIGlkIDE5ODA4LCBzZXEgOTYsIGxlbmd0aCA2NA0KMDk6NTg6MjIuMDIwOTI3IElQIDEw LjEwLjExLjUwID4gMTAuMTAuMTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDk2 LCBsZW5ndGggNjQNCjA5OjU4OjIzLjAyMTc0MCBJUCAxMC4xMC4xMS4xID4gMTAuMTAuMTEuNTA6 IElDTVAgZWNobyByZXF1ZXN0LCBpZCAxOTgwOCwgc2VxIDk3LCBsZW5ndGggNjQNCjA5OjU4OjIz LjAyMTg5NiBJUCAxMC4xMC4xMS41MCA+IDEwLjEwLjExLjE6IElDTVAgZWNobyByZXBseSwgaWQg MTk4MDgsIHNlcSA5NywgbGVuZ3RoIDY0DQowOTo1ODoyNC4wMjI3MjUgSVAgMTAuMTAuMTEuMSA+ IDEwLjEwLjExLjUwOiBJQ01QIGVjaG8gcmVxdWVzdCwgaWQgMTk4MDgsIHNlcSA5OCwgbGVuZ3Ro IDY0DQowOTo1ODoyNC4wMjI4NzcgSVAgMTAuMTAuMTEuNTAgPiAxMC4xMC4xMS4xOiBJQ01QIGVj aG8gcmVwbHksIGlkIDE5ODA4LCBzZXEgOTgsIGxlbmd0aCA2NA0KMDk6NTg6MjUuMDIzNzEwIElQ IDEwLjEwLjExLjEgPiAxMC4xMC4xMS41MDogSUNNUCBlY2hvIHJlcXVlc3QsIGlkIDE5ODA4LCBz ZXEgOTksIGxlbmd0aCA2NA0KMDk6NTg6MjUuMDIzODg0IElQIDEwLjEwLjExLjUwID4gMTAuMTAu MTEuMTogSUNNUCBlY2hvIHJlcGx5LCBpZCAxOTgwOCwgc2VxIDk5LCBsZW5ndGggNjQNCl5DDQox OTcgcGFja2V0cyBjYXB0dXJlZA0KMTk3IHBhY2tldHMgcmVjZWl2ZWQgYnkgZmlsdGVyDQowIHBh Y2tldHMgZHJvcHBlZCBieSBrZXJuZWwNCnJvYmJha0BvbGQtZ3c6fiAwICQgZXhpdA0KClNjcmlw dCBkb25lIG9uIFRodSBGZWIgMjEgMDk6NTk6NTIgMjAwOAo= ------=_Part_349_32900395.1203555782162-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 23:41:38 2008 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 F317716A401 for ; Wed, 20 Feb 2008 23:41:37 +0000 (UTC) (envelope-from bbiskebo@bosco.princeton.edu) Received: from Princeton.EDU (postoffice05.Princeton.EDU [128.112.133.189]) by mx1.freebsd.org (Postfix) with ESMTP id AB23713C45A for ; Wed, 20 Feb 2008 23:41:37 +0000 (UTC) (envelope-from bbiskebo@bosco.princeton.edu) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by Princeton.EDU (8.13.8/8.13.8) with ESMTP id m1KNfVnV016646; Wed, 20 Feb 2008 18:41:31 -0500 (EST) Received: from [140.180.177.201] (formula.Princeton.EDU [140.180.177.201]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id m1KNfOrU009639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2008 18:41:24 -0500 (EST) Message-ID: <47BCBAA1.1070000@bosco.princeton.edu> Date: Wed, 20 Feb 2008 18:41:21 -0500 From: Brian Biskeborn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ken Smith References: 1202955279.6548.2.camel@section-8.internal.avioc.org <47BA10C1.5030701@trull.org> <47BA185C.6030703@samsco.org> <47BA882C.7090103@trull.org> <1203541485.99240.39.camel@bauer.cse.buffalo.edu> In-Reply-To: <1203541485.99240.39.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Feb 2008 02:24:59 +0000 Cc: freebsd-current@freebsd.org Subject: Re: hptrr driver panics on 7.0-RC2 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, 20 Feb 2008 23:41:38 -0000 "RC3" works fine with my 2314MS. Thanks. Brian Ken Smith wrote: > On Tue, 2008-02-19 at 07:41 +0000, Alex Trull wrote: >> Scott Long wrote: >>> Alex Trull wrote: >>>> Issue also confirmed with the rocketraid 2310 / revision 2.2 firmware >>>> on amd64. >>> Yeah, known issue that will be addressed shortly. Sorry for the >>> inconvenience. Does it work with RC1 for you? >>> >>> Scott >>> _______________________________________________ >>> 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" >> Yes - the quickest recovery was booting the rc1 livefs image followed by >> copying over that image's /boot/kernel. >> >> Thanks. >> >> -- >> Alex > > The hptrr driver update that had been done between 7.0-RC1 and 7.0-RC2 > has been backed out in the CVS repository. If you experienced problems > caused by that driver and can do a cvsup based update (branch tag > RELENG_7_0) to see if that solves the issues and let us know that would > be appreciated. I'm currently uploading a "mini-RC3" that just has the > amd64 and i386 architectures but it will be a while before the upload > completes and it then propagates out to the mirrors. I'll send out an > announcement about its availability once it's had a chance to propagate > a bit. If you successfully update using cvsup the kernel should > identify itself as 7.0-RC3. > > Thanks. Sorry for the inconvenience caused by the driver's update. > From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 00:43:21 2008 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 5BC2B16A401; Thu, 21 Feb 2008 00:43:21 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0FF13C4DD; Thu, 21 Feb 2008 00:43:20 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 5994238461; Thu, 21 Feb 2008 09:24:13 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [10.0.0.249]) by hub.bbnest.net (8.14.2/8.14.1) with ESMTP id m1L0OBos060066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2008 09:24:12 +0900 (JST) (envelope-from bland@bbnest.net) Message-Id: <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> From: Alexander Nedotsukov To: Kostik Belousov In-Reply-To: <20080124124213.GD57756@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary=Apple-Mail-51--239406666 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 09:26:16 +0900 References: <4792C32C.5010205@gmail.com> <20080122133835.GT57756@deviant.kiev.zoral.com.ua> <4796356D.9080809@gmail.com> <20080123051648.GV57756@deviant.kiev.zoral.com.ua> <479796E1.4000500@gmail.com> <1201118159.38742.17.camel@shumai.marcuscom.com> <20080123211149.GA57756@deviant.kiev.zoral.com.ua> <1201123933.62127.9.camel@shumai.marcuscom.com> <20080124124213.GD57756@deviant.kiev.zoral.com.ua> X-Mailer: Apple Mail (2.919.2) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on hub.bbnest.net X-Mailman-Approved-At: Thu, 21 Feb 2008 02:25:45 +0000 Cc: FreeBSD Current , Joe Marcus Clarke Subject: Re: page fault panic in scioctl and console-kit-daemon 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, 21 Feb 2008 00:43:21 -0000 --Apple-Mail-51--239406666 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, May I ask to revisit this issue? To me ENXIO is not semantically correct in this particular case. It also turns out that doing workaround in userspace may not be that good as we used to think. I propose is to fix VT_WAITACTIVE so it simply wait for bound device activation. For my understanding this change should not have any impact on existing code. I also removed really strange console cleanup bit sticked in a long time ago (see ioctl() part). It will be nice to see this patch --Apple-Mail-51--239406666 Content-Disposition: attachment; filename=sys_dev_syscons.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="sys_dev_syscons.patch" Content-Transfer-Encoding: 7bit Index: syscons.c =================================================================== RCS file: /home/ncvs/src/sys/dev/syscons/syscons.c,v retrieving revision 1.457 diff -u -r1.457 syscons.c --- syscons.c 24 Jan 2008 15:37:48 -0000 1.457 +++ syscons.c 7 Feb 2008 01:26:44 -0000 @@ -1065,17 +1065,9 @@ i = (*(int *)data == 0) ? scp->index : (*(int *)data - 1); if ((i < sc->first_vty) || (i >= sc->first_vty + sc->vtys)) return EINVAL; - s = spltty(); - error = sc_clean_up(sc->cur_scp); - splx(s); - if (error) - return error; - scp = sc_get_stat(SC_DEV(sc, i)); - if (scp == NULL) - return (ENXIO); - if (scp == scp->sc->cur_scp) + if (i == sc->cur_scp->index) return 0; - error = tsleep(&scp->smode, PZERO | PCATCH, "waitvt", 0); + error = tsleep(SC_DEV(sc, i), PZERO | PCATCH, "waitvt", 0); return error; case VT_GETACTIVE: /* get active vty # */ @@ -2335,7 +2327,7 @@ * be invoked at splhigh(). */ if (debugger == 0) - wakeup(&sc->new_scp->smode); + wakeup(SC_DEV(sc,next_scr)); splx(s); DPRINTF(5, ("switch done (new == old)\n")); return 0; @@ -2358,7 +2350,7 @@ /* wake up processes waiting for this vty */ if (debugger == 0) - wakeup(&sc->cur_scp->smode); + wakeup(SC_DEV(sc,next_scr)); /* wait for the controlling process to acknowledge, if necessary */ if (signal_vt_acq(sc->cur_scp)) { @@ -2384,7 +2376,7 @@ exchange_scr(sc); s = spltty(); /* sc->cur_scp == sc->new_scp */ - wakeup(&sc->cur_scp->smode); + wakeup(SC_DEV(sc,sc->cur_scp->index)); /* wait for the controlling process to acknowledge, if necessary */ if (!signal_vt_acq(sc->cur_scp)) { --Apple-Mail-51--239406666 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit (successfully tested by our affected users) committed to all branches. Thanks, Alexander. On 24.01.2008, at 21:42, Kostik Belousov wrote: > On Wed, Jan 23, 2008 at 04:32:13PM -0500, Joe Marcus Clarke wrote: >> >> On Wed, 2008-01-23 at 23:11 +0200, Kostik Belousov wrote: >>> On Wed, Jan 23, 2008 at 02:55:59PM -0500, Joe Marcus Clarke wrote: >>>> >>>> On Wed, 2008-01-23 at 20:34 +0100, Pawel Worach wrote: >>>>> Kostik Belousov wrote: >>>>>> On Tue, Jan 22, 2008 at 07:26:53PM +0100, Pawel Worach wrote: >>>>>>> Kostik Belousov wrote: >>>>>>>> On Sun, Jan 20, 2008 at 04:42:36AM +0100, Pawel Worach wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> While starting console-kit-daemon (sysutils/consolekit >>>>>>>>> 0.2.3) during >>>>>>>>> boot or in single-user mode the system panics. If I start it >>>>>>>>> post-boot >>>>>>>>> it runs fine. This is on 8.0-CURRENT from about 12 hours >>>>>>>>> ago, another >>>>>>>>> user also reported the same on RELENG_7. Any other >>>>>>>>> information I can >>>>>>>>> provide ? >>>>>>>>> >>>>>>>>> Fatal trap 12: page fault while in kernel mode >>>>>>>>> fault virtual address = 0x4 >>>>>>>>> fault code = supervisor read, page not present >>>>>>>>> instruction pointer = 0x20:0xc04d2ab4 >>>>>>>>> stack pointer = 0x28:0xe6499b18 >>>>>>>>> frame pointer = 0x28:0xe6499b80 >>>>>>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>>>>>> = DPL 0, pres 1, def32 1, gran 1 >>>>>>>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>>>>>>> current process = 134 (console-kit-daemon) >>>>>>>>> Physical memory: 1014 MB >>>>>>>>> Dumping 43 MB: 28 12 >>>>>>>>> >>>>>>>>> #8 0xc07a34a2 in trap (frame=0xe6499ad8) at >>>>>>>>> /usr/src/sys/i386/i386/trap.c:489 >>>>>>>>> #9 0xc079183b in calltrap () at /usr/src/sys/i386/i386/ >>>>>>>>> exception.s:146 >>>>>>>>> #10 0xc04d2ab4 in scioctl (dev=0xc3b20d00, cmd=537163270, >>>>>>>>> data=0xe6499c70 "\002", flag=1, td=0xc3d3c880) >>>>>>>>> at /usr/src/sys/dev/syscons/syscons.c:1073 >>>>>>>>> #11 0xc051ed1a in giant_ioctl (dev=0xc3b20d00, cmd=537163270, >>>>>>>>> data=0xe6499c70 "\002", fflag=1, td=0xc3d3c880) >>>>>>>>> at /usr/src/sys/kern/kern_conf.c:349 >>>>>>>>> #12 0xc0598194 in cnioctl (dev=0xc3b20d00, cmd=537163270, >>>>>>>>> data=0xe6499c70 "\002", flag=1, td=0xc3d3c880) >>>>>>>>> ---Type to continue, or q to quit--- >>>>>>>>> at /usr/src/sys/kern/tty_cons.c:521 >>>>>>>> Unless the virtual screen is opened, the screen state >>>>>>>> scr_stat structure >>>>>>>> is not allocated. The following patch would fix the panic, >>>>>>>> but I do not >>>>>>>> know how the console-kit would react to the ENXIO from the >>>>>>>> VT_WAITACTIVE ioctl. Please, test it. >>>>>>> Thanks! The patch works. >>>>>> >>>>>> To clarify: do you see any problems with the console-kit after >>>>>> the patch ? >>>>>> In particular, can you verify that the program functions >>>>>> correctly, esp. >>>>>> on the virtual terminals 1, 2 ... , whatever this means ? >>>>> >>>>> The panic is of course gone, while chatting a bit with Marcus >>>>> (CCd) it >>>>> looks like console-kit does not do any error handling at all. >>>>> I've not >>>>> looked at what c-k does so maybe Marcus can answer the question >>>>> better. >>>> >>>> It tries to install a wait thread on each available VT. That >>>> thread >>>> sets the WAITACTIVE ioctl, and waits for its VT to become >>>> active. When >>>> it does, it sets the CK active VT accordingly, and reattaches the >>>> wait. >>>> >>>> When an error occurs in the ioctl, no wait is attached, and CK >>>> will not >>>> know when a particular VT becomes active. This will essentially >>>> cripple >>>> CK (assuming the VT really does become available at a later point). >>>> >>>> Now, admittedly, there is no error correction in CK for this >>>> situation. >>>> It would be trivial to add something that periodically attempts to >>>> reestablish a failed wait. However, I am very curious why only a >>>> few >>>> users are seeing this panic (me excluded on two different >>>> machines). It >>>> seems to me that the scp should be initialized when >>>> sc_attach_unit() is >>>> called during device probing. I don't see anything special in >>>> init(8)'s >>>> code that would cause these VT devices to become initialized. I >>>> would >>>> assume that if one can open(2) them, then they should be >>>> available for >>>> ioctls? >>> >>> From my reading of the code, scp would be non-NULL after the first >>> open >>> of the corresponding /dev/ttyvX. sc_attach_unit() creates the scp >>> for >>> the console and the consolectl devices. >>> >>> VT_WAITACTIVE ioctl is performed on arbitrary syscons /dev node, and >>> can wait for any other screens, in particular, the screens that are >>> not opened at the moment (the reason for the reported panic). >> >> Right, and this is where I was confused. I had thought from an old >> reading of the CK code that CK opened each ttyvX device to perform >> the >> ioctl. It does not. Instead, it opens /dev/console, and performs >> the >> ioctl for each ttyvX on that fd. That does explain the panic, but >> not >> exactly why I did not see it. I'm guessing a race condition, but I >> can't be sure. >> >>> >>> The patch I posted may be improved by making the VT_WAITACTIVE ioctl >>> to wait for the scp being allocated, and only then for the screen >>> to be >>> switched too. Please, test. >> >> I really appreciate your attention to this. Funny thing is, CK 0.2.4 >> was just released, and it is no longer started out of rc.d. I've >> also >> added error correcting in the CK code path. The problem may >> disappear >> depending on when CK is executed out of D-BUS. However, it would be >> good to prevent this in the kernel. Pawel said he would try and test >> this patch. > > This must be fixed in the kernel, at least because it allows any > console > user to panic the system. The question I have to you is what > approach shall > we use: > - return the ENXIO (1) > - do the wait for the open, then wait for the switch (2) > > I would prefer (1), both due to putting the decision to the > userspace, and > to not have the algorithm that could be implemented in userspace, in > the > kernel. On the other hand, as the maintainer of the one of the major > API > consumer there, you may have the different opinion, that is crusial. --Apple-Mail-51--239406666-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 03:46:21 2008 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 8D09216A404 for ; Thu, 21 Feb 2008 03:46:21 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5E61213C467 for ; Thu, 21 Feb 2008 03:46:21 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-72-73-8.dsl.telstraclear.net [121.72.73.8]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JWK009TIL56XU10@smtp4.clear.net.nz> for freebsd-current@freebsd.org; Thu, 21 Feb 2008 16:46:20 +1300 (NZDT) Date: Thu, 21 Feb 2008 16:46:18 +1300 From: Mark Kirkwood In-reply-to: To: Robert Backhaus Message-id: <47BCF40A.4050302@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Thunderbird 2.0.0.9 (X11/20071203) Cc: FreeBSD Current Subject: Re: Packet corruption in re0 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, 21 Feb 2008 03:46:21 -0000 Robert Backhaus wrote: > Just to make troubleshooting difficult, this problem only shows up > after the system has been up for roughly 36 hours, depending on the > amount of traffic. > > This is possibly a bit left field - but I experienced something like this once, and it was due to overheating - the edges of the (large) cpu heatsink hung over the circuitry concerned, preventing enough airflow and obviously offloading heat! So maybe check for something hot nearby to where the realtek stuff is. Cheers Mark From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 03:50:23 2008 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 081BB16A402 for ; Thu, 21 Feb 2008 03:50:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id CCBA113C467 for ; Thu, 21 Feb 2008 03:50:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so849719wfa.7 for ; Wed, 20 Feb 2008 19:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=JrtXKaARc0P4XrN2jJm9OG0iiTZ/BEOfB5LMHBXyFwg=; b=Rwef97/QxM/WQDyQafIGv6t4zUIL+MDWnCVFvAqjeaZlUS9N0a34eTfQO+8P4upb/6HEYgKE76V1RxvRUWFz8gpmmKJVF1Zki8CUzyPkb7eZxiliPByVTcUu1fYPq7DbQw2Lmx/NiM8Rm8g0qoMvryrTcLFe2WQT3asPlhNeX/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=aVXsQIvetSuT+T2l/uiKasHYZEBHzSLCG1jkMepHfv2qb02XjGDrZ3IdBaGk6oQfTj7NBc+jk2jXvvZx8BSEL8GHAaq1C+O5+s1Ju3FGvWLIuvUYfp8JSXGkZO/4aOALUJhSPd1x1AieTzEWJ5YhC+8gLMgu9jr0zzgM9k/r5ZY= Received: by 10.142.180.17 with SMTP id c17mr7104974wff.76.1203565821318; Wed, 20 Feb 2008 19:50:21 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm24103830wff.11.2008.02.20.19.50.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 19:50:20 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1L3oFiJ027125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 12:50:15 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1L3oEPJ027124; Thu, 21 Feb 2008 12:50:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 21 Feb 2008 12:50:14 +0900 From: Pyun YongHyeon To: Robert Backhaus Message-ID: <20080221035014.GB26427@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 03:50:23 -0000 On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > I am experiencing roughly 15% packet corruption on the re interface on > my freebsd 7/amd64 box. > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: > Tue Feb 5 09:49:55 EST 2008 > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > The attached 3 files demonstrate the problem: "ping" shows the output > of ping -c 100, and shows 15% packet loss. "tcpdump" shows the packets > leaving, and some of the lost packets being returned with addresses, > ports and data corrupted. The data in these packets seems to be coming > from other packets passing through other interfaces at the time. > "remote-tcpdump" shows the packets being received and returned from > the other machine. Note that some packets are being corrupted on the > way out, too. > > Just to make troubleshooting difficult, this problem only shows up > after the system has been up for roughly 36 hours, depending on the > amount of traffic. > I didn't take a look attached tcpdump files but I guess the instability issue was fixed in HEAD. It's not yet MFCed but I'll handle it in a week. Would you try re(4) in HEAD? > I am using the latest bios that I am aware of. The bios that I > recently applied did include a firmware update for the realtek > interface, but this did not affect the problem. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 04:29:27 2008 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 0308216A402 for ; Thu, 21 Feb 2008 04:29:27 +0000 (UTC) (envelope-from kerneljake@hotmail.com) Received: from bay0-omc1-s2.bay0.hotmail.com (bay0-omc1-s2.bay0.hotmail.com [65.54.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id E998C13C4E3 for ; Thu, 21 Feb 2008 04:29:26 +0000 (UTC) (envelope-from kerneljake@hotmail.com) Received: from BAY136-W26 ([65.55.141.61]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 20:17:27 -0800 Message-ID: X-Originating-IP: [71.145.160.70] From: Kernel Jake To: Date: Wed, 20 Feb 2008 22:17:27 -0600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2008 04:17:27.0178 (UTC) FILETIME=[AAC44EA0:01C87440] Subject: 7.0-RC2 amd64 SMP Unsupported relocation type at boot 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, 21 Feb 2008 04:29:27 -0000 Background: standard install using releases/amd64/ISO-IMAGES/7.0/7.0-RC2-am= d64-disc1.iso on a 80GB SATA drive. Motherboard: Supermicro H8SSL-i with AMIBIOS 8.00.11 2/21/06 Right before the login prompt should appear in multiuser mode, the boot pro= cess stops with: /libexec/ld-elf.so.1: /lib/libedit.so.6: Unsupported relocation type 48886 = in non-PLT relocations If I boot to single user mode and immediately exit the shell, the multiuser= boot process completes and the login prompt appears, but the following err= or appears prior to the login prompt: /libexec/ld-elf.so.1: /usr/lib/libkrb5.so.9: invalid file format (3 times) /libexec/ld-elf.so.1: /usr/lib/libssl.so.5: Undefined symbol "i2d_DHparams = (2 times) And then a subsequent command like "man nc" yields: /libexec/ld-elf.so.1: troff: Shared object has no runtime symbol table. # dmesg Copyright (c) 1992-2008 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 7.0-RC2 #0: Fri Feb 8 00:02:33 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (1995.02-MHz K8-class C= PU) Origin =3D "AuthenticAMD" Id =3D 0x20f32 Stepping =3D 2 Features=3D0x178bfbff Features2=3D0x1 AMD Features=3D0xe2500800 AMD Features2=3D0x3 Cores per package: 2 usable memory =3D 1060904960 (1011 MB) avail memory =3D 1022255104 (974 MB) ACPI APIC Table:=20 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 540, 20 (4) failed acpi0: reservation of 500, 20 (4) failed acpi0: reservation of 560, 20 (4) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: port 0x508-0x50b on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 bge0: mem 0xfc9f0000-0xfc9fffff irq 24 at device 3.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000ba= seT-FDX, auto bge0: Ethernet address: 00:30:48:58:56:b6 bge0: [ITHREAD] bge1: mem 0xfc9e0000-0xfc9effff irq 25 at device 3.1 on pci2 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000ba= seT-FDX, auto bge1: Ethernet address: 00:30:48:58:56:b7 bge1: [ITHREAD] atapci0: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb4= 00-0xb40f mem 0xfcafe000-0xfcafffff irq 11 at device 14.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0xb080-0xb087,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa8= 00-0xa80f irq 11 at device 14.1 on pci1 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device = 2.1 on pci0 ata0: on atapci2 ata0: [ITHREAD] ata1: on atapci2 ata1: [ITHREAD] isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0xe800-0xe8ff mem 0xfebfd000-0xfebfdfff irq 10 at device 3.0 o= n pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: port 0xd800-0xd8ff mem 0xfebfc000-0xfebfcfff irq 10 at device 3.1 o= n pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: port 0xd400-0xd4ff mem 0xfebfb000-0xfebfbfff irq 10 at device 3.2 o= n pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered umass0: on uhub2 umass0: Get Max Lun not supported (STALLED) vgapci0: port 0xe000-0xe0ff mem 0xfd000000-0xfdffffff,0xfebff000-0xfebffff= f irq 19 at device 5.0 on pci0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc9fff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA=20 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad4: DMA limited to UDMA33, device found non-ATA66 cable ad4: 76324MB at ata2-master UDMA33 SMP: AP CPU #1 Launched! cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 40.000MB/s transfers cd0: cd present [256308 x 2048 byte records] GEOM_LABEL: Label for provider cd0 is iso9660/FreeBSD_Install. Trying to mount root from ufs:/dev/ad4s1a bge0: link state changed to UP _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= 08= From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 04:47:46 2008 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 73FE116A400 for ; Thu, 21 Feb 2008 04:47:46 +0000 (UTC) (envelope-from robbak@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id 5A87A13C474 for ; Thu, 21 Feb 2008 04:47:45 +0000 (UTC) (envelope-from robbak@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so1319890tid.3 for ; Wed, 20 Feb 2008 20:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=CczOC6kdJn0+UMn9PcWpQ7J0A7uE8KM81/ZQFup7xvk=; b=xpmtYuobMpFX5h6octwORZf3j2ywBJ18ebMpiYbXR1l3IlKyiH6SeIzOKWPQ4teRvsBvTf0gruN9AqsByINBJ8bVsK5/G3kwPdWQulmvxCz4Le2WaIh7c/U0/Tj6+QSgpJtOMhOwpxyWA2yjLhXXFPIa482ZW3hnIgino2tOyOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mVDWhcwVS+Fo0HSNteVU7qoM2fynDezUFhpj0AO8iuIXQqKeigXuzYkC8yDRUmQKrt3pqY+4K0WnIkZ/11xqlUGoUCIemwh5V+G0BaDLiABUhDgVEpYeVmZVC8wJ1lV3aOo/4zEz5gH7fEmOL+FyqVfjA2JYEeplhIjgH6GIHf8= Received: by 10.110.31.5 with SMTP id e5mr6395065tie.37.1203569263455; Wed, 20 Feb 2008 20:47:43 -0800 (PST) Received: by 10.110.26.11 with HTTP; Wed, 20 Feb 2008 20:47:43 -0800 (PST) Message-ID: Date: Thu, 21 Feb 2008 14:47:43 +1000 From: "Robert Backhaus" Sender: robbak@gmail.com To: "FreeBSD Current" In-Reply-To: <20080221035014.GB26427@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080221035014.GB26427@cdnetworks.co.kr> X-Google-Sender-Auth: b12468ae04bc9061 Subject: Re: Packet corruption in re0 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, 21 Feb 2008 04:47:46 -0000 On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wrote: > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > I am experiencing roughly 15% packet corruption on the re interface on > > my freebsd 7/amd64 box. > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: > > Tue Feb 5 09:49:55 EST 2008 > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > Just to make troubleshooting difficult, this problem only shows up > > after the system has been up for roughly 36 hours, depending on the > > amount of traffic. > > > > I didn't take a look attached tcpdump files but I guess the > instability issue was fixed in HEAD. It's not yet MFCed but > I'll handle it in a week. > > Would you try re(4) in HEAD? > OK, I'll do that. What is the best way to do that? csupping to "." seems a bit drastic, and I don't do much with cvs proper. I take it that I should use anon-cvs to grab the directory, but I don't quite know how. > >This is possibly a bit left field - but I experienced something like >this once, and it was due to overheating - the edges of the (large) cpu >heatsink hung over the circuitry concerned, preventing enough airflow >and obviously offloading heat! So maybe check for something hot nearby >to where the realtek stuff is. > >Cheers Yes, I've been down the heat path, but the problem takes ~36 hours to recur both if the system is turned on from cold, or simply rebooted. Mind you, North Queensland could do with some cooling! I will take another look at the circuitry if moving to HEAD's re doesn't fix it. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 05:06:43 2008 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 70E1D16A400 for ; Thu, 21 Feb 2008 05:06:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 41C4213C468 for ; Thu, 21 Feb 2008 05:06:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so863776wfa.7 for ; Wed, 20 Feb 2008 21:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=jLWv7pJ00JNEAKs7zz16m2v8FVqK4plYkwPBKWcp6OU=; b=jq2niR0/eGUuH2IpzJXz2IS4NhZWTTMq6a0jeLM7IZihd3y/dwVAzBl5hdSGtcO7eofX09Nu2kz/jHm4ZshTShL7bxWFvfQBLQeMya+fmi+PFPQ2sfy9RlOsgigU43nt9/Hu/r8PBqwPOEXFzNAZIcJzKK8MuIjNmKJHpU89Noo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=nYf2kGczufIpPDqztKlvpFqoYErUHDb6FS5sC2W/YRXsSsxZw5WdPJy6kkcwxUsNXnYs87GOfDptQLnkSVyJHjck5XEwBZs8+G6uu7SRl/s90LJRX9jLOYcId5BiXIPi/OSQjHdOBFWilz7zd8RlwN2nElpwInCfhI8U2nm/wrk= Received: by 10.142.246.8 with SMTP id t8mr7210013wfh.199.1203570401988; Wed, 20 Feb 2008 21:06:41 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 24sm24198351wfc.18.2008.02.20.21.06.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 21:06:41 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1L56Z3l027343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:06:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1L56ZXb027342; Thu, 21 Feb 2008 14:06:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 21 Feb 2008 14:06:35 +0900 From: Pyun YongHyeon To: Robert Backhaus Message-ID: <20080221050635.GC26427@cdnetworks.co.kr> References: <20080221035014.GB26427@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 05:06:43 -0000 On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wrote: > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > I am experiencing roughly 15% packet corruption on the re interface on > > > my freebsd 7/amd64 box. > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: > > > Tue Feb 5 09:49:55 EST 2008 > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > Just to make troubleshooting difficult, this problem only shows up > > > after the system has been up for roughly 36 hours, depending on the > > > amount of traffic. > > > > > > > I didn't take a look attached tcpdump files but I guess the > > instability issue was fixed in HEAD. It's not yet MFCed but > > I'll handle it in a week. > > > > Would you try re(4) in HEAD? > > > > OK, I'll do that. What is the best way to do that? csupping to "." seems a > bit drastic, and I don't do much with cvs proper. I take it that I should use > anon-cvs to grab the directory, but I don't quite know how. > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > >This is possibly a bit left field - but I experienced something like > >this once, and it was due to overheating - the edges of the (large) cpu > >heatsink hung over the circuitry concerned, preventing enough airflow > >and obviously offloading heat! So maybe check for something hot nearby > >to where the realtek stuff is. > > > >Cheers > > Yes, I've been down the heat path, but the problem takes ~36 hours to recur > both if the system is turned on from cold, or simply rebooted. Mind you, > North Queensland could do with some cooling! I will take another look at the > circuitry if moving to HEAD's re doesn't fix it. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 05:44:46 2008 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 40FE716A402 for ; Thu, 21 Feb 2008 05:44:46 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id F3C7013C45E for ; Thu, 21 Feb 2008 05:44:45 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so2532701wxd.7 for ; Wed, 20 Feb 2008 21:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding:sender; bh=yEhStMIIfvkRG/cG47PxZolXUQ0nwGLpM2D4uqLG0ew=; b=ldZYKbowHsjwC9F2J3bPA3YFIyekyNYgwpY/LwsEf5UydDGcx4yHljNqI/Bse/S8rf6xWQntYKEi4UbOA5a84gZoB7TSIfXNPEpSq7h/QJ2QXG5tizU+DorG+mSTIJpeDFKbWYqser9+mg+ZyHsDstZqbVNDY00Al2GCpAtiX+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding:sender; b=vxqbMfhXV+WyWLbI0Ulz9DIsArirF5FYa9oTcRVPUHrpzlt90rp28mr3m0q5YZe6hiFtRmBcFeGq5Nhuyvko6N/sBgPI0ZT3mWds/enaWi+o6JLY48qJzhX7gT+gumH2O0RF7EQcOPfuWbTiexz+IA+zRC+6JZ/vPkF7rJmV4Tw= Received: by 10.142.187.2 with SMTP id k2mr4725671wff.25.1203570959170; Wed, 20 Feb 2008 21:15:59 -0800 (PST) Received: from ?192.168.10.84? ( [59.125.13.44]) by mx.google.com with ESMTPS id 9sm24208266wfc.16.2008.02.20.21.15.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Feb 2008 21:15:58 -0800 (PST) From: "Eric L. Chen" To: Robert Backhaus In-Reply-To: References: Content-Type: text/plain Date: Thu, 21 Feb 2008 13:15:54 +0800 Message-Id: <1203570954.1696.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Sender: "Eric L. Chen" Cc: FreeBSD Current Subject: Re: Packet corruption in re0 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, 21 Feb 2008 05:44:46 -0000 On Thu, 2008-02-21 at 11:03 +1000, Robert Backhaus wrote: > I am experiencing roughly 15% packet corruption on the re interface on > my freebsd 7/amd64 box. > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: > Tue Feb 5 09:49:55 EST 2008 > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > The attached 3 files demonstrate the problem: "ping" shows the output > of ping -c 100, and shows 15% packet loss. "tcpdump" shows the packets > leaving, and some of the lost packets being returned with addresses, > ports and data corrupted. The data in these packets seems to be coming > from other packets passing through other interfaces at the time. > "remote-tcpdump" shows the packets being received and returned from > the other machine. Note that some packets are being corrupted on the > way out, too. > > Just to make troubleshooting difficult, this problem only shows up > after the system has been up for roughly 36 hours, depending on the > amount of traffic. > > I am using the latest bios that I am aware of. The bios that I > recently applied did include a firmware update for the realtek > interface, but this did not affect the problem. > _______________________________________________ I disabled some hw features and works fine. like this (/etc/rc.conf) ifconfig_re0="inet 192.168.1.10 netmask 255.255.255.0 -rxcsum -txcsum -tso -lr o" /Eric From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 07:43:20 2008 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 3453216A402 for ; Thu, 21 Feb 2008 07:43:20 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 0B89913C461 for ; Thu, 21 Feb 2008 07:43:19 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so2281076rvb.43 for ; Wed, 20 Feb 2008 23:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=zR+F7scFSXbNRvjs262RwhYyFXuvHgFj19mI3Xk40cQ=; b=IBeFuFSl1dXmB2GBso8INdxR5B5Ut45RrI1SI4hA8tHFgz4RZMlOA/Hw/iGtr7/vFrqrE98KnURV76yT/UengHUud0V04DkxylvoaYs06qKKmk7DyC5s8fJ4Qdspjv1gRujNcoEZwV9a5qCTNNkFJ9GUjy6ECUfrMEUX+qQQ+Yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VuHylDL9QSKeIA/IhcUX9ptAEc7uykZZQCJvt+JFtib11P0dC8zVgAEBzwhUqtxNULgxrZzif7N35eOG/ZRQfT/WLsZZ0jUxlXCabDKEl2L/kiWAllfRlDO+lJ+IKcm6VJKrGR81/sYNRC3KBqzJDwcd+HmHwH1dPXkSIL8NUMo= Received: by 10.140.163.3 with SMTP id l3mr6436510rve.253.1203579799061; Wed, 20 Feb 2008 23:43:19 -0800 (PST) Received: by 10.141.170.18 with HTTP; Wed, 20 Feb 2008 23:43:18 -0800 (PST) Message-ID: <2e77fc10802202343j2ac419bay89a2442a4832b2d@mail.gmail.com> Date: Thu, 21 Feb 2008 07:43:18 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: "Eric L. Chen" In-Reply-To: <1203570954.1696.2.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1203570954.1696.2.camel@localhost> X-Google-Sender-Auth: b7c147a00f0455bb Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 21 Feb 2008 07:43:20 -0000 On Thu, Feb 21, 2008 at 5:15 AM, Eric L. Chen wrote: > > > On Thu, 2008-02-21 at 11:03 +1000, Robert Backhaus wrote: > > I am experiencing roughly 15% packet corruption on the re interface on > > my freebsd 7/amd64 box. > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: > > Tue Feb 5 09:49:55 EST 2008 > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > The attached 3 files demonstrate the problem: "ping" shows the output > > of ping -c 100, and shows 15% packet loss. "tcpdump" shows the packets > > leaving, and some of the lost packets being returned with addresses, > > ports and data corrupted. The data in these packets seems to be coming > > from other packets passing through other interfaces at the time. > > "remote-tcpdump" shows the packets being received and returned from > > the other machine. Note that some packets are being corrupted on the > > way out, too. > > > > Just to make troubleshooting difficult, this problem only shows up > > after the system has been up for roughly 36 hours, depending on the > > amount of traffic. > > > > I am using the latest bios that I am aware of. The bios that I > > recently applied did include a firmware update for the realtek > > interface, but this did not affect the problem. > > _______________________________________________ > > I disabled some hw features and works fine. > like this (/etc/rc.conf) > ifconfig_re0="inet 192.168.1.10 netmask 255.255.255.0 -rxcsum -txcsum > -tso -lr > o" > > /Eric > I experienced the same problems shortly after upgrading to 7.0-PRE After about a day and something of uptime my ssh shells began to drop with messages about corrupted/mismatched checksums. I "fixed" the problem by putting an em(4) interface in the machine, because I need it to be online and accessible remotely at all times. --Niki From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 07:54:48 2008 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 5F77B16A407 for ; Thu, 21 Feb 2008 07:54:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1423F13C469 for ; Thu, 21 Feb 2008 07:54:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3595391pyb.10 for ; Wed, 20 Feb 2008 23:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=L9WxZFd5TFduqufZhgq8xr5fQN/iYOfGo0V1+AUVczE=; b=Y+mw4qsNhDTO/tS+a3o5UoAAxQXlRysJbY9ixJxrfmlfoGKfRdiB6CCy9v4HvR66CSzIJ/1QVNvHHMxRZtCA/Hc5m3av7Xgwvns1xttj0TdYTt+JnG+XaBmE5te+2z0dcNZiNUN8XOtnHyGqU/TlyfLvW5r2tOjA21odCuKo99Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=tTNwEiYslSAvprvI/gIn04ibW1emvTIB/36xOEbtC3A098UWBgDWMOSqa5i8SYs0tNAS+AEhM+vmAfCp7vducGpQjrfhftqWe0+EVNzIqux5xzXr5skPi4R76809vFm6fEAlYBc0SBe2KuHpcBZzPaB90ahu0i1G+VsJao/U4sk= Received: by 10.142.214.5 with SMTP id m5mr7352737wfg.51.1203580486640; Wed, 20 Feb 2008 23:54:46 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm24547629wff.11.2008.02.20.23.54.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 23:54:45 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1L7se4E027777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:54:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1L7sco4027776; Thu, 21 Feb 2008 16:54:38 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 21 Feb 2008 16:54:38 +0900 From: Pyun YongHyeon To: Niki Denev Message-ID: <20080221075438.GD26427@cdnetworks.co.kr> References: <1203570954.1696.2.camel@localhost> <2e77fc10802202343j2ac419bay89a2442a4832b2d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e77fc10802202343j2ac419bay89a2442a4832b2d@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , "Eric L. Chen" , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 07:54:48 -0000 On Thu, Feb 21, 2008 at 07:43:18AM +0000, Niki Denev wrote: > On Thu, Feb 21, 2008 at 5:15 AM, Eric L. Chen wrote: > > > > > > On Thu, 2008-02-21 at 11:03 +1000, Robert Backhaus wrote: > > > I am experiencing roughly 15% packet corruption on the re interface on > > > my freebsd 7/amd64 box. > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8: > > > Tue Feb 5 09:49:55 EST 2008 > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > The attached 3 files demonstrate the problem: "ping" shows the output > > > of ping -c 100, and shows 15% packet loss. "tcpdump" shows the packets > > > leaving, and some of the lost packets being returned with addresses, > > > ports and data corrupted. The data in these packets seems to be coming > > > from other packets passing through other interfaces at the time. > > > "remote-tcpdump" shows the packets being received and returned from > > > the other machine. Note that some packets are being corrupted on the > > > way out, too. > > > > > > Just to make troubleshooting difficult, this problem only shows up > > > after the system has been up for roughly 36 hours, depending on the > > > amount of traffic. > > > > > > I am using the latest bios that I am aware of. The bios that I > > > recently applied did include a firmware update for the realtek > > > interface, but this did not affect the problem. > > > _______________________________________________ > > > > I disabled some hw features and works fine. > > like this (/etc/rc.conf) > > ifconfig_re0="inet 192.168.1.10 netmask 255.255.255.0 -rxcsum -txcsum > > -tso -lr > > o" > > > > /Eric > > > > I experienced the same problems shortly after upgrading to 7.0-PRE > After about a day and something of uptime my ssh shells began to drop > with messages about corrupted/mismatched checksums. > I "fixed" the problem by putting an em(4) interface in the machine, > because I need it to be online and accessible remotely at all times. > There had been several bus_dma(9) related bugs in re(4) for a long time and I guess I fixed most of them. Hiding actual bugs by replacing interfaces is not a good way to fix root cause of the issue. If you can reproduce above issues in HEAD please let me know. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 10:15:45 2008 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 DAA4816A401 for ; Thu, 21 Feb 2008 10:15:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com (anti-4.kiev.sovam.com [62.64.120.202]) by mx1.freebsd.org (Postfix) with ESMTP id 82C4F13C46A for ; Thu, 21 Feb 2008 10:15:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JS8Sr-000BSx-Ow; Thu, 21 Feb 2008 12:15:44 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1KBEMAO079394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 13:14:22 +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.2/8.14.2) with ESMTP id m1KBEifa026674; Wed, 20 Feb 2008 13:14:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1KBEiTH026673; Wed, 20 Feb 2008 13:14:44 +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: Wed, 20 Feb 2008 13:14:44 +0200 From: Kostik Belousov To: d@delphij.net Message-ID: <20080220111444.GH57756@deviant.kiev.zoral.com.ua> References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> <47BBF9CC.4030404@delphij.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CzROh2enfuzgPXpq" Content-Disposition: inline In-Reply-To: <47BBF9CC.4030404@delphij.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 1118cf21f7425d415ed61e91afc5cb63 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2271 [Feb 20 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-fs@freebsd.org, Alexander Leidinger , FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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, 21 Feb 2008 10:15:45 -0000 --CzROh2enfuzgPXpq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 01:58:36AM -0800, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Alexander Leidinger wrote: > > Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 > > -0800): > >=20 > >> Change summary: > >> > >> fsutil.c: > >> - Really update standard superblock. fsck_ffs -b used to update the > >> backup superblock which does not recover file systems which have bad > >> master superblocks. > >> - Instead of coredump, zero out whole cg if its signature is bad. > >> > >> inode.c: > >> - Instead of coredump, zero out whole cg if its signature is bad. > >=20 > > Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask > > for confirmation? >=20 > My assumption is that if a cylinder group's magic number is damaged, > then the whole stuff can not be trusted at all, but yes, I think this > should come with a prompt, will add tomorrow. I have some uneasy feeling about automatically zeroing a cg. I think it would be safer to show the message there, and add the same functionality to fsdb, something like clrcg command, analogous to clri. --CzROh2enfuzgPXpq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke8C6MACgkQC3+MBN1Mb4hvnACeLqs9DokpnnsjAcFSWXrxLYDq 1iIAnjNMukCTe1AzihTKlCP1jAi+zLvG =ltem -----END PGP SIGNATURE----- --CzROh2enfuzgPXpq-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 10:31:40 2008 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 BB92916A402 for ; Thu, 21 Feb 2008 10:31:40 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4838113C43E for ; Thu, 21 Feb 2008 10:31:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JS8iH-0000PT-Hh for freebsd-current@freebsd.org; Thu, 21 Feb 2008 10:31:37 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 10:31:37 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 10:31:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 21 Feb 2008 11:34:01 +0100 Lines: 52 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11484294007BCFD079928B80" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: 7.0-RC2 amd64 SMP Unsupported relocation type at boot 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, 21 Feb 2008 10:31:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11484294007BCFD079928B80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kernel Jake wrote: > Background: standard install using releases/amd64/ISO-IMAGES/7.0/7.0-RC= 2-amd64-disc1.iso on a 80GB SATA drive. > Motherboard: Supermicro H8SSL-i with AMIBIOS 8.00.11 2/21/06 >=20 > Right before the login prompt should appear in multiuser mode, the boot= process stops with: >=20 > /libexec/ld-elf.so.1: /lib/libedit.so.6: Unsupported relocation type 48= 886 in non-PLT relocations >=20 > If I boot to single user mode and immediately exit the shell, the multi= user boot process completes and the login prompt appears, but the followi= ng error appears prior to the login prompt: >=20 > /libexec/ld-elf.so.1: /usr/lib/libkrb5.so.9: invalid file format (3 tim= es) > /libexec/ld-elf.so.1: /usr/lib/libssl.so.5: Undefined symbol "i2d_DHpar= ams (2 times) >=20 > And then a subsequent command like "man nc" yields: >=20 > /libexec/ld-elf.so.1: troff: Shared object has no runtime symbol table.= Something is probably corrupting the executables. Probably one of these things: - bad memory (run memtest86) - bad hard drive / controller (check if other data are also affected) - bad installation media (download another) --------------enig11484294007BCFD079928B80 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHvVOeldnAQVacBcgRAgLwAJ433odWq2zxhCSwLTLusHZPtDNpgACbBJGs 68DDvMmF7ZbQ8xjpYkLeqyo= =d3qM -----END PGP SIGNATURE----- --------------enig11484294007BCFD079928B80-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 11:00:46 2008 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 25D5E16A405 for ; Thu, 21 Feb 2008 11:00:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4800F13C4D3; Thu, 21 Feb 2008 11:00:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BD59D9.9010308@FreeBSD.org> Date: Thu, 21 Feb 2008 12:00:41 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pluknet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: panic: mutex Giant owned at nfs_syscalls.c:556 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, 21 Feb 2008 11:00:46 -0000 pluknet wrote: > I got this assertion while attempting to remove file on nfs mounted > ffs filesystem. > NFS client on 7.0-PRERELEASE and NFS server on 8-CURRENT. > > FreeBSD 7.0-PRERELEASE #1: Wed Feb 6 18:09:18 MSK 2008 > FreeBSD 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008 > > Unread portion of the kernel message buffer: > panic: mutex Giant owned at > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 > KDB: enter: panic > exclusive sleep mutex nfsd_mtx r = 0 (0xc41d1660) locked @ > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501 > exclusive sleep mutex Giant r = 0 (0xc07e6410) locked @ > /usr/src/sys/kern/vfs_lookup.c:663 > ... > #9 0xc053959d in panic (fmt=0xc076181d "mutex %s owned at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:555 > #10 0xc052adf7 in _mtx_assert (m=0xc07e6410, what=0, > file=0xc41cb7b2 > "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c", > line=556) at /usr/src/sys/kern/kern_mutex.c:652 > #11 0xc41c9e82 in nfssvc (td=0xc2e68000, uap=0xd600dcfc) > at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 > #12 0xc0727903 in syscall (frame=0xd600dd38) > at /usr/src/sys/i386/i386/trap.c:1034 > #13 0xc0711630 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203 > ---Type to continue, or q to quit--- > #14 0x00000033 in ?? () > > Looks somewhat strange because nfs_syscalls.c:556 is not in nfssvc(), > it's in nfssvc_nfsd(). > Kernel and world synchronized on 8-CUR though. > This has been reported a couple of times before but you are the first to provide the WITNESS data, which was necessary to proceed. Thanks :) So there are two questions: 1) Why is Giant being acquired at all? vfs_lookup.c:663 is a VFS_LOCK_GIANT indicating that you are doing a lookup on a non-mpsafe filesystem. What filesystems are being exported by the server? Previously people claimed not to be exporting any filesystems that should be marked !mpsafe, which was a puzzle. 2) Missed VFS_UNLOCK_GIANT somewhere, or broken assert. The above trace should be enough to diagnose though. Kris From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 11:19:13 2008 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 9A21F16A400 for ; Thu, 21 Feb 2008 11:19:13 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 67FB813C45A for ; Thu, 21 Feb 2008 11:19:13 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=hirB/qBAtva3taeUUowWcTDeleri/z3xMhNK2e8kMhUXrjcebyzwSWl+uKJa8LyrRdIFIV4XpU6xXwXIzpDkEqtWaj3KPnVKrJBdzT2rtTqC2o8M+I2mBxEdeBLQdPYU+8t3+xZF1GCB1PJBG0fU1wbrCQX/2EQTD6OCkWh/kU3Q4dGSHFJ1SpNLhkLJgEW4I5wMpWaTVAIv/poNSTGNk29yFSgd26FdWQx3IerCZMTN7ASKARw//xC95AhB4Z+Q; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1JS9SG-0004BD-Bg; Thu, 21 Feb 2008 11:19:08 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JS9RT-0005n2-HH; Thu, 21 Feb 2008 11:18:19 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JS9RS-00016O-Hz; Thu, 21 Feb 2008 13:18:18 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: Message from Pyun YongHyeon of "Thu, 21 Feb 2008 14:06:35 +0900." <20080221050635.GC26427@cdnetworks.co.kr> X-Attribution: BOFH Date: Thu, 21 Feb 2008 13:18:18 +0200 Message-Id: Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 21 Feb 2008 11:19:13 -0000 Pyun YongHyeon wrote: > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wrote: > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > I am experiencing roughly 15% packet corruption on the re interface on > > > > my freebsd 7/amd64 box. > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8 : > > > > Tue Feb 5 09:49:55 EST 2008 > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > Just to make troubleshooting difficult, this problem only shows up > > > > after the system has been up for roughly 36 hours, depending on the > > > > amount of traffic. > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > I'll handle it in a week. > > > > > > Would you try re(4) in HEAD? > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." seems a > > bit drastic, and I don't do much with cvs proper. I take it that I should use > > anon-cvs to grab the directory, but I don't quite know how. > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > HEAD/RELENG_7 to if_re.c). That would make it build on your box. This doesn't solve the problem that I'm seeing on re(4) interfaces. It basically shows up as quagga establishing OSPF neighours as "Exchange/DR" when VLAN hardware tagging is enabled. I'm running OSPF over 802.1Q vlans. Neighbours are correctly negotiated once VLAN hardware tagging is disabled on the interface. I'll do more debugging. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 08:26:19 2008 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 C40E116A400 for ; Thu, 21 Feb 2008 08:26:19 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (host3.dynacom.ondsl.gr [62.103.35.211]) by mx1.freebsd.org (Postfix) with ESMTP id 91CC413C46B for ; Thu, 21 Feb 2008 08:26:17 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.14.2/8.14.2) with ESMTP id m1L8Q6is084457; Thu, 21 Feb 2008 10:26:06 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Received: from localhost (localhost [[UNIX: localhost]]) by smadev.internal.net (8.14.2/8.14.2/Submit) id m1L8Q61q084456; Thu, 21 Feb 2008 10:26:06 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: Eygene Ryabinkin Date: Thu, 21 Feb 2008 10:26:04 +0200 User-Agent: KMail/1.9.7 References: <200802201111.16340.achill@matrix.gatewaynet.com> <200802201547.17360.achill@matrix.gatewaynet.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802211026.05892.achill@matrix.gatewaynet.com> X-Mailman-Approved-At: Thu, 21 Feb 2008 12:21:58 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Problem with various ports 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, 21 Feb 2008 08:26:19 -0000 =D3=F4=E9=F2 Wednesday 20 February 2008 16:31:28 =EF/=E7 Eygene Ryabinkin = =DD=E3=F1=E1=F8=E5: > Achilleas, >=20 > Wed, Feb 20, 2008 at 03:47:16PM +0200, Achilleas Mantzios wrote: > > The below build, later complains about not existing /usr/local/share/xm= l/sdocbook/4.1.2.5/catalog, > > creating it by hand just reincarnated the problem. > > here is the whole original output: > >=20 > [...] > > SGML_CATALOG_FILES=3D/usr/local/share/sgml/catalog \ > > SGML_SEARCH_PATH=3D../..:../../doc:.. \ > > jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ > > -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml > > jade:/usr/local/share/sgml/catalog.ports:3:8:E: cannot open "/usr/local= /share/xml/sdocbook/4.1.2.5/catalog" (No such file or directory) >=20 > I bet that your '/usr/local/share/sgml/catalog.ports' has entry for > '/usr/local/share/xml/sdocbook/4.1.2.5/catalog'. Do you have > sdocbook-xml port version 4.1.2.5 installed? Will it solve the > problem if you'll remove this line from /usr/local/share/sgml/catalog.por= ts? I must say that my system was updated from 6.1 to RELENG_7_0 (on sunday) and i did a total ports wipe out, and starting with an empty system rebuilt= everything from source (kde,gnome). At the time of the problem my /usr/local/share/sgml/catalog.ports was =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 CATALOG "/usr/local/share/xml/docbook/4.1.2/docbook.cat" CATALOG "/usr/local/share/xml/sdocbook/4.1.2.5/catalog" CATALOG "/usr/local/share/xml/sdocbook/1.1/catalog" CATALOG "docbook/dsssl/modular/catalog" CATALOG "/usr/local/share/xml/docbook/4.2/docbook.cat" CATALOG "jade/catalog" CATALOG "iso8879/catalog" CATALOG "docbook/4.1/catalog" CATALOG "docbook/3.1/catalog" =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 Also at the time of the problem my related ports installed were: docbook-3.1_2 V3.1 of the DocBook DTD, designed for technical documen= tati docbook-4.1_3 V4.1 of the DocBook DTD, designed for technical documen= tati docbook-sk-4.1.2_4 XML version of the DocBook DTD version controlled for S= crol docbook-utils-0.6.14_3 Generates various output formats from DocBook SGML d= ocument docbook-xml-4.2_1 XML version of the DocBook DTD docbook-xml-4.3 DocBook/XML DTD V4.3, designed for technical documentat= ion docbook-xml-4.4 DocBook/XML DTD V4.4, designed for technical documentat= ion docbook-xsl-1.71.1_2 XSL DocBook stylesheets dsssl-docbook-modular-1.79_1,1 DSSSL stylesheets for the DocBook DTD by Nor= man Walsh sdocbook-xml-1.1,1 "Simplified" DocBook XML DTD What i did was what Eygene Ryabinkin suggested, i just removed the first tw= o lines of /usr/local/share/sgml/catalog.ports and the port built fine. Maybe /usr/local/share/sgml/catalog.ports was not cleaned/removed during m= y initial pkg_deintall "*" that i did on sunday in order to start with a fresh system, (since portupgrading -a would be sort of PITA) Thanks. =2D-=20 Achilleas Mantzios KOSOVO IS SERBIA FOR EVER From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:06:47 2008 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 BD5D116A404 for ; Thu, 21 Feb 2008 12:06:47 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (host3.dynacom.ondsl.gr [62.103.35.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1350213C458 for ; Thu, 21 Feb 2008 12:06:46 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.14.2/8.14.2) with ESMTP id m1LC6h0K085484 for ; Thu, 21 Feb 2008 14:06:43 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Received: from localhost (localhost [[UNIX: localhost]]) by smadev.internal.net (8.14.2/8.14.2/Submit) id m1LC6eE8085483 for freebsd-current@freebsd.org; Thu, 21 Feb 2008 14:06:41 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: freebsd-current@freebsd.org Date: Thu, 21 Feb 2008 14:06:39 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802211406.40612.achill@matrix.gatewaynet.com> X-Mailman-Approved-At: Thu, 21 Feb 2008 12:25:14 +0000 Subject: Crazy md5,sha256,bzip2 behaviour, frequent crashes RAM problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 12:06:47 -0000 Hi, i've struggling to build sysutils/coreutils and a crazy thing happens: each time i do fetch ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2 and while ls -l gives the exact same size (5384378), md5,sha256 give different checksums each time! I do this same fetch from another machine @ work and it gives the correct size, checksums. I scp the wierd coreutils-6.9.tar.bz2 from the wierd FreeBSD box to a linux, and i get the the same wierd checksums, so i conclude the problem happens at fetch time. Wierd problems on FreeBSD most commonly have bad memory as the root cause. Do you have any other idea of what it might causing it?? Also i have frequent crashes at high loads with this machine. It runs 7.0-RC2 FreeBSD 7.0-RC2 Here is the kgdb session from the most recent crash: doroot@smadev:/usr/obj/usr/src/sys/ACHIX7# kgdb kernel.debug /var/crash/vmcore.5 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2000028 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07bb175 stack pointer = 0x28:0xe6383794 frame pointer = 0x28:0xe63837bc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 49307 (bsdtar) trap number = 12 panic: page fault Uptime: 14h22m21s Physical memory: 979 MB Dumping 183 MB: 168 152 136 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc07504e3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc07506df in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a40e7c in trap_fatal (frame=0xe6383754, eva=33554472) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a410e0 in trap_pfault (frame=0xe6383754, usermode=0, eva=33554472) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a41a39 in trap (frame=0xe6383754) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2b33b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07bb175 in vfs_hash_get (mp=0xc416f7d4, hash=5561646, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_hash.c:72 #8 0xc0945029 in ffs_vget (mp=0xc416f7d4, ino=5561646, flags=2, vpp=0xe6383918) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1320 #9 0xc0927625 in ffs_valloc (pvp=0xc80bc330, mode=33188, cred=0xc5910700, vpp=0xe6383918) at /usr/src/sys/ufs/ffs/ffs_alloc.c:957 #10 0xc0956885 in ufs_makeinode (mode=33188, dvp=0xc80bc330, vpp=0xe6383b94, cnp=0xe6383ba8) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2238 #11 0xc0956ff0 in ufs_create (ap=0xe6383a8c) at /usr/src/sys/ufs/ufs/ufs_vnops.c:194 #12 0xc0a568b2 in VOP_CREATE_APV (vop=0xc0b8ac60, a=0xe6383a8c) at vnode_if.c:206 #13 0xc07d38ff in vn_open_cred (ndp=0xe6383b80, flagp=0xe6383c78, cmode=Variable "cmode" is not available. ) at vnode_if.h:112 #14 0xc07d3cc3 in vn_open (ndp=0xe6383b80, flagp=0xe6383c78, cmode=420, fp=0xc4d80288) at /usr/src/sys/kern/vfs_vnops.c:94 #15 0xc07d1957 in kern_open (td=0xc5fa2a50, path=0x28250100
, pathseg=UIO_USERSPACE, flags=2562, mode=420) at /usr/src/sys/kern/vfs_syscalls.c:1028 #16 0xc07d1ec0 in open (td=0xc5fa2a50, uap=0xe6383cfc) at /usr/src/sys/kern/vfs_syscalls.c:995 #17 0xc0a41435 in syscall (frame=0xe6383d38) at /usr/src/sys/i386/i386/trap.c:1035 #18 0xc0a2b3a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Achilleas Mantzios KOSOVO IS SERBIA FOR EVER From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:29:49 2008 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 1C99E16A402; Thu, 21 Feb 2008 12:29:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E686413C465; Thu, 21 Feb 2008 12:29:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LCTmTo061693; Thu, 21 Feb 2008 07:29:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LCTldE091826; Thu, 21 Feb 2008 07:29:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AFBB973039; Thu, 21 Feb 2008 07:29:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221122947.AFBB973039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 07:29:47 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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, 21 Feb 2008 12:29:49 -0000 TB --- 2008-02-21 12:16:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 12:16:35 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-21 12:16:35 - cleaning the object tree TB --- 2008-02-21 12:17:11 - cvsupping the source tree TB --- 2008-02-21 12:17:11 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-21 12:17:20 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 12:17:20 - cd /src TB --- 2008-02-21 12:17:20 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 12:17:23 UTC 2008 >>> 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 [...] cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/sparc64/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 12:29:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 12:29:47 - ERROR: failed to build world TB --- 2008-02-21 12:29:47 - tinderbox aborted TB --- 525.66 user 71.12 system 791.91 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:31:23 2008 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 B291E16A403 for ; Thu, 21 Feb 2008 12:31:23 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 369C413C45D for ; Thu, 21 Feb 2008 12:31:22 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1951nfb.33 for ; Thu, 21 Feb 2008 04:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=GYM3Wcvn31otx8Dlu3JftgoOakCW2YXhJ4m0N3MBFJs=; b=NY0btiqWBwrZrf2kc/5ue5r12/DY1eXQmiggBsI5kt6/Qwzjd1WQ/7Owej+5pYAopu4egI71dFl/kDlvVbspqLqQXeT0TzBk5rsHRIUH3Qd7JNmd8kFLFXg/dAN7JPPjUOz0S+YX+L2yc2KT2wtSyya8u53zkFiiOR4zNpzVXaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mZ9Zt3QnnpgBnYwqt4rWQClPEOIOAUmpPkxqrYb3IsDiSXCxZOa3oUd4DNNcYaHnGnGcpGusJvfO8LBDc0q2H+z5AImFzPTXwjDIV3i86pJWlxfhVGwIUfd0oDy2fLYUvOm+TlFuyo0FtXulzeoflmpIckWUECR107yMvdKnbi4= Received: by 10.78.149.15 with SMTP id w15mr15518202hud.60.1203597079778; Thu, 21 Feb 2008 04:31:19 -0800 (PST) Received: by 10.78.16.10 with HTTP; Thu, 21 Feb 2008 04:31:19 -0800 (PST) Message-ID: Date: Thu, 21 Feb 2008 15:31:19 +0300 From: pluknet To: "Kris Kennaway" In-Reply-To: <47BD59D9.9010308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47BD59D9.9010308@FreeBSD.org> Cc: FreeBSD Current Subject: Re: panic: mutex Giant owned at nfs_syscalls.c:556 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, 21 Feb 2008 12:31:23 -0000 On 21/02/2008, Kris Kennaway wrote: > pluknet wrote: > > I got this assertion while attempting to remove file on nfs mounted > > ffs filesystem. > > NFS client on 7.0-PRERELEASE and NFS server on 8-CURRENT. > > > > FreeBSD 7.0-PRERELEASE #1: Wed Feb 6 18:09:18 MSK 2008 > > FreeBSD 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008 > > > > Unread portion of the kernel message buffer: > > panic: mutex Giant owned at > > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 > > KDB: enter: panic > > exclusive sleep mutex nfsd_mtx r = 0 (0xc41d1660) locked @ > > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501 > > exclusive sleep mutex Giant r = 0 (0xc07e6410) locked @ > > /usr/src/sys/kern/vfs_lookup.c:663 > > ... > > #9 0xc053959d in panic (fmt=0xc076181d "mutex %s owned at %s:%d") > > at /usr/src/sys/kern/kern_shutdown.c:555 > > #10 0xc052adf7 in _mtx_assert (m=0xc07e6410, what=0, > > file=0xc41cb7b2 > > "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c", > > line=556) at /usr/src/sys/kern/kern_mutex.c:652 > > #11 0xc41c9e82 in nfssvc (td=0xc2e68000, uap=0xd600dcfc) > > at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 > > #12 0xc0727903 in syscall (frame=0xd600dd38) > > at /usr/src/sys/i386/i386/trap.c:1034 > > #13 0xc0711630 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203 > > ---Type to continue, or q to quit--- > > #14 0x00000033 in ?? () > > > > Looks somewhat strange because nfs_syscalls.c:556 is not in nfssvc(), > > it's in nfssvc_nfsd(). > > Kernel and world synchronized on 8-CUR though. > > > > > This has been reported a couple of times before but you are the first to > provide the WITNESS data, which was necessary to proceed. Thanks :) > > So there are two questions: > > 1) Why is Giant being acquired at all? vfs_lookup.c:663 is a > VFS_LOCK_GIANT indicating that you are doing a lookup on a non-mpsafe > filesystem. What filesystems are being exported by the server? > Previously people claimed not to be exporting any filesystems that > should be marked !mpsafe, which was a puzzle. > I'm sorry for confusing you. :/ Actually 1 msdosfs filesystem is being exported. BTW panic occurred on UP kernel. > 2) Missed VFS_UNLOCK_GIANT somewhere, or broken assert. The above trace > should be enough to diagnose though. > I will try to reproduce and investigate this (in a week). > > Kris > wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:32:08 2008 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 5A6DB16A404; Thu, 21 Feb 2008 12:32:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1137F13C468; Thu, 21 Feb 2008 12:32:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B5F9643CC85; Thu, 21 Feb 2008 14:32:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNNHte2ZE-y4; Thu, 21 Feb 2008 14:32:06 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4905E43CAD5; Thu, 21 Feb 2008 14:32:06 +0200 (EET) Message-ID: <47BD6F39.7080105@icyb.net.ua> Date: Thu, 21 Feb 2008 14:31:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <47B81D07.7090208@icyb.net.ua> In-Reply-To: <47B81D07.7090208@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) 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, 21 Feb 2008 12:32:08 -0000 on 17/02/2008 13:39 Andriy Gapon said the following: > Should newfs_msdos be able to work on "whole" cdX/acdX device ? > [ufs/ffs] newfs can do it. > But with newfs_msdos I had to run disklabel first and then I could > create a filesystem on cdXa, but I couldn't do it on the whole disk. It seems that the reason for this newfs_msdos behavior is in the following lines: if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) errx(1, "Cannot get sector size, %s", strerror(errno)); if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) errx(1, "Cannot get number of sectors, %s", strerror(errno)); if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) errx(1, "Cannot get number of heads, %s", strerror(errno)); While a failure to get sector size is a serious situation indeed, number of sectors per track and number of heads are just relics of the past and are not applicable to all types of should-be-supported media. What's even more funny is that those values can be set via command line options and in that case values from ioctl are not used at all. Because those numbers are used by msdosfs on-disk structures we have to provide some reasonable values for them even if they are meaningless with respect to physical media organization. An example of simple calculations can be found in bsdlabel.c. I see two approaches: 1) fake those properties in device drivers, primarily cd(4) and acd(4); benefit: this can help other utilities besides newfs_msdos 2) fake those properties in newfs_msdof; benefit: this would help with other physical devices that can host FAT; Or maybe do both. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:42:39 2008 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 E28B116A402; Thu, 21 Feb 2008 12:42:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B6C7D13C447; Thu, 21 Feb 2008 12:42:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LCgXZO050116; Thu, 21 Feb 2008 07:42:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LCgXI6005841; Thu, 21 Feb 2008 07:42:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F246773039; Thu, 21 Feb 2008 07:42:32 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221124232.F246773039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 07:42:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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, 21 Feb 2008 12:42:39 -0000 TB --- 2008-02-21 12:29:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 12:29:47 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-21 12:29:47 - cleaning the object tree TB --- 2008-02-21 12:30:19 - cvsupping the source tree TB --- 2008-02-21 12:30:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-21 12:30:24 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 12:30:24 - cd /src TB --- 2008-02-21 12:30:24 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 12:30:26 UTC 2008 >>> 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 [...] cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/sun4v/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 12:42:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 12:42:32 - ERROR: failed to build world TB --- 2008-02-21 12:42:32 - tinderbox aborted TB --- 526.59 user 70.48 system 765.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:50:35 2008 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 38FD816A401 for ; Thu, 21 Feb 2008 12:50:35 +0000 (UTC) (envelope-from kaiwang27@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 AE48813C4EA for ; Thu, 21 Feb 2008 12:50:34 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so31175fgg.35 for ; Thu, 21 Feb 2008 04:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; bh=XEZvzjYxEfhMWMmzUE6eUv6zGfwheebJBvowuplCnDA=; b=lh4Q7VV2PXiJwrgcCrB/pMHFTHdcSDcviHwFzBBZC55CVrhaR6Ral3EU2cn1+m39OIOSvoaXTobs/iU5DuMLx7WLRz2zwy7b27Y46QIZkSE23NUfZtlJai4CM8N5PLqSEF2RfuTweRSRjaKByLaBXaKUonc2qJqeHPYADfMqxgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=E5If0EfjNdQHDYs/xEceSUBrSpUGYythJWtm6wCZWzLxYwKwODnN/LN/nn2QKDu95O5Y3AOBpdydybtolGUag4o2rvb3Icx6epeGyu6/SUcL+3lsZPs9e+Yq+pBwYvNtKHLYkvuT/oiahFEtXuRR4gu/qKaAMH5OwklEWbBpePQ= Received: by 10.82.160.19 with SMTP id i19mr16810853bue.23.1203598232836; Thu, 21 Feb 2008 04:50:32 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id m5sm11228106gve.11.2008.02.21.04.50.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 04:50:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSBDd-0000aR-UA for freebsd-current@freebsd.org; Thu, 21 Feb 2008 14:12:10 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1LDC9cn002258 for freebsd-current@freebsd.org; Thu, 21 Feb 2008 14:12:09 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Thu, 21 Feb 2008 14:12:09 +0100 From: Kai Wang To: freebsd-current@freebsd.org Message-ID: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 12:50:35 -0000 Hello list, I just committed ar(1) front-end. Note that you NEED update your world before you can successfully perform cross platform buildworld. You can update your system by: make buildworld ... make installworld or you can just install ar(1) by hand. (replace /usr/bin/ar and /usr/bin/ranlib by hand) This is needed because GNU Binutils ar and ranlib gets renamed to gar and granlib, and when you perform a cross platform buildworld, the build system will instead use /usr/bin/ar and /usr/bin/ranlib, which is not capable of cross build. Best Regards, Kai From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:51:42 2008 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 2878816A402 for ; Thu, 21 Feb 2008 12:51:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E69C513C45B for ; Thu, 21 Feb 2008 12:51:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4311C17105; Thu, 21 Feb 2008 12:26:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1LCQuvH074068; Thu, 21 Feb 2008 12:26:56 GMT (envelope-from phk@critter.freebsd.dk) To: Achilleas Mantzios From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 21 Feb 2008 14:06:39 +0200." <200802211406.40612.achill@matrix.gatewaynet.com> Date: Thu, 21 Feb 2008 12:26:56 +0000 Message-ID: <74067.1203596816@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Crazy md5, sha256, bzip2 behaviour, frequent crashes RAM problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 12:51:42 -0000 In message <200802211406.40612.achill@matrix.gatewaynet.com>, Achilleas Mantzio s writes: >Hi, >i've struggling to build sysutils/coreutils and a crazy thing happens: >each time i do >fetch ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2 >and while ls -l gives the exact same size (5384378), md5,sha256 give different checksums each time! Bad hardware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:08:10 2008 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 2D41216A400; Thu, 21 Feb 2008 13:08:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DD30013C467; Thu, 21 Feb 2008 13:08:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LD899U052200; Thu, 21 Feb 2008 08:08:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LD89dW023177; Thu, 21 Feb 2008 08:08:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1BF2D73039; Thu, 21 Feb 2008 08:08:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221130809.1BF2D73039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 08:08:09 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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, 21 Feb 2008 13:08:10 -0000 TB --- 2008-02-21 12:55:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 12:55:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-02-21 12:55:00 - cleaning the object tree TB --- 2008-02-21 12:55:25 - cvsupping the source tree TB --- 2008-02-21 12:55:25 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-02-21 12:55:31 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 12:55:31 - cd /src TB --- 2008-02-21 12:55:31 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 12:55:32 UTC 2008 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcswidth.c -o wcswidth.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/arm/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 13:08:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 13:08:09 - ERROR: failed to build world TB --- 2008-02-21 13:08:09 - tinderbox aborted TB --- 544.13 user 72.52 system 788.82 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:10:40 2008 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 B06D916A403; Thu, 21 Feb 2008 13:10:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8445213C45A; Thu, 21 Feb 2008 13:10:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LDAepK052446; Thu, 21 Feb 2008 08:10:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LDAdaf026163; Thu, 21 Feb 2008 08:10:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8445D73039; Thu, 21 Feb 2008 08:10:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221131039.8445D73039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 08:10:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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, 21 Feb 2008 13:10:40 -0000 TB --- 2008-02-21 12:55:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 12:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-02-21 12:55:00 - cleaning the object tree TB --- 2008-02-21 12:55:51 - cvsupping the source tree TB --- 2008-02-21 12:55:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-02-21 12:55:57 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 12:55:57 - cd /src TB --- 2008-02-21 12:55:57 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 12:56:00 UTC 2008 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/amd64/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 13:10:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 13:10:39 - ERROR: failed to build world TB --- 2008-02-21 13:10:39 - tinderbox aborted TB --- 646.30 user 82.94 system 939.25 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:20:28 2008 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 C818C16A403 for ; Thu, 21 Feb 2008 13:20:28 +0000 (UTC) (envelope-from kaiwang27@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 2527513C467 for ; Thu, 21 Feb 2008 13:20:27 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so38047fgg.35 for ; Thu, 21 Feb 2008 05:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=j+JBaVXOti4tmKkDOu2hYcZQmHu+DGAqtLlvggZ5V+k=; b=OJTK3xmHeHB3SQhGdyQ2m3h0Tm4aSZSnAvuybLgg9Ovy6BXRmLvNhADEdPGgUwMPwLAvOvn6yOL4LIYtSuyi+5s17e02OjxYlyDOeqSSiU4aXKFQwXINJ1bo7//soJQbdbBZy71Ik0RDRPn7S3bV0tR5GaeCn8dbIb4Gjc7NKH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=UZmLBot70naDSE3lVS0n4OHg8Hz97lSwEAk3W7Qn0vYz9VECfcCKwf4WycqYUQ4Qbx2607Pd/fkveBumXoTYb6hkECp8TuaHz9Rb++9xtwKzWOw0l1fXZeSS36BVjrfdvTnsX6Vw0wGMAKrIK8poJe8ApgC+5j4ggvhjnl/naXM= Received: by 10.82.172.10 with SMTP id u10mr18556293bue.14.1203598394714; Thu, 21 Feb 2008 04:53:14 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id j8sm11170294gvb.7.2008.02.21.04.53.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 04:53:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSBGF-0000aj-K8; Thu, 21 Feb 2008 14:14:51 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1LDEptZ002276; Thu, 21 Feb 2008 14:14:51 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Thu, 21 Feb 2008 14:14:51 +0100 From: Kai Wang To: FreeBSD Tinderbox Message-ID: <20080221131451.GB2022@plan0.kaiwan.csbnet.se> Mail-Followup-To: FreeBSD Tinderbox , current@freebsd.org, sparc64@freebsd.org References: <20080221122947.AFBB973039@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080221122947.AFBB973039@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 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, 21 Feb 2008 13:20:28 -0000 On Thu, Feb 21, 2008 at 07:29:47AM -0500, FreeBSD Tinderbox wrote: > TB --- 2008-02-21 12:16:35 - tinderbox 2.3 running on freebsd-current.sentex.ca > TB --- 2008-02-21 12:16:35 - starting HEAD tinderbox run for sparc64/sparc64 > TB --- 2008-02-21 12:16:35 - cleaning the object tree > TB --- 2008-02-21 12:17:11 - cvsupping the source tree > TB --- 2008-02-21 12:17:11 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile > TB --- 2008-02-21 12:17:20 - building world (CFLAGS=-O -pipe) > TB --- 2008-02-21 12:17:20 - cd /src > TB --- 2008-02-21 12:17:20 - /usr/bin/make -B buildworld > >>> World build started on Thu Feb 21 12:17:23 UTC 2008 > >>> 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 > [...] > cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So > cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So > cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So > cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So > cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So > cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So > building shared library libc.so.7 > /obj/sparc64/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one > *** Error code 1 > > Stop in /src/lib/libc. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2008-02-21 12:29:47 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2008-02-21 12:29:47 - ERROR: failed to build world > TB --- 2008-02-21 12:29:47 - tinderbox aborted > TB --- 525.66 user 71.12 system 791.91 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full Sorry for the breakage. Tinderbox need a new world before it can successfully perform cross-platform buildworld. (Please refer to the headsup I just posted in current@) Thanks, Kai From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 13:41:12 2008 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 32E8616A401 for ; Thu, 21 Feb 2008 13:41:12 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id DB67A13C4FB for ; Thu, 21 Feb 2008 13:41:11 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so9534anc.13 for ; Thu, 21 Feb 2008 05:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=UbQFrLspYp5x4eeUM+lT0+IO2ONpx/QI0WLaaQQc8IY=; b=WvDKC3zasL6AjAe7CvFIio6YLOd8XJHPCW4Izj0LSHlnZx0Ct9Cy0htbpFCU6E4ULrEKwYUfdaquqwrc9EJQ7ZoXlBFKwNvzNDGLo6Bk0GmihaHusNTH9vYXUeXvem+KNkqBwarTNLcmL6iAfHejpoUhK/Cu+3nnFXEEMP4S0FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=SuAr7WRbGnSCNOZjpDJ27kBmle0SBC2LfICg5j+lSPTdCaB61z6l1sc+DcNH9+rDVegKV0Gga+7UVJYaKiLGjn5l8a7R5e1KD8CKCaFOleJl9bERlrERB/iL9hkw11SSiIAWv3S3JEqAPSeDv69pTaz7PXeRlZAGqPTS3u6MIUw= Received: by 10.100.125.12 with SMTP id x12mr19970982anc.84.1203601271049; Thu, 21 Feb 2008 05:41:11 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id 20sm23857agd.11.2008.02.21.05.41.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 05:41:09 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSC0d-0000f1-96 for freebsd-current@freebsd.org; Thu, 21 Feb 2008 15:02:47 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1LE2lf4002542 for freebsd-current@freebsd.org; Thu, 21 Feb 2008 15:02:47 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Thu, 21 Feb 2008 15:02:47 +0100 From: Kai Wang To: freebsd-current@freebsd.org Message-ID: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> Mail-Followup-To: freebsd-current@freebsd.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 13:41:12 -0000 On Thu, Feb 21, 2008 at 02:12:09PM +0100, Kai Wang wrote: > Hello list, > > I just committed ar(1) front-end. Note that you NEED update your > world before you can successfully perform cross platform buildworld. > > You can update your system by: > make buildworld > ... > make installworld > > or you can just install ar(1) by hand. > (replace /usr/bin/ar and /usr/bin/ranlib by hand) > > This is needed because GNU Binutils ar and ranlib gets renamed to gar > and granlib, and when you perform a cross platform buildworld, the > build system will instead use /usr/bin/ar and /usr/bin/ranlib, which > is not capable of cross build. I think it's neccessary to explain it a bit. When you start cross-platform world build, the toolchain targarting that platform will be built first. Then the resulting cross-platform toolchain is used to build the world for that platform. ar(1) and ranlib(1) are part of the toolchain. After I renamed them to gar and granlib, the build system can no longer find them, as a result it will use default ones, i.e., /usr/bin/ar and /usr/bin/ranlib, which target your current platform and thus can not be used to cross build. You can solve this problem by updating your own world first, or by replacing '/usr/bin/ar' and '/usr/bin/ranlib' with 'BSD' ar and ranlib by hand. 'BSD' ar is platform independent and handles all the ELF targets thus can be used directly (no need to recompile itself for target platform) by the build system. Best Regards, Kai From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:34:00 2008 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 5DFCE16A402 for ; Thu, 21 Feb 2008 14:34:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com (anti-4.kiev.sovam.com [62.64.120.202]) by mx1.freebsd.org (Postfix) with ESMTP id 019B613C44B for ; Thu, 21 Feb 2008 14:33:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSCUm-00043n-Vm for freebsd-current@freebsd.org; Thu, 21 Feb 2008 16:33:58 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1LEXUtF025457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:33:30 +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.2/8.14.2) with ESMTP id m1LEXqp8041015; Thu, 21 Feb 2008 16:33:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1LEXq4K041014; Thu, 21 Feb 2008 16:33:52 +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: Thu, 21 Feb 2008 16:33:52 +0200 From: Kostik Belousov To: Kai Wang Message-ID: <20080221143351.GP57756@deviant.kiev.zoral.com.ua> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M8LGuhT/2+u1DQ9j" Content-Disposition: inline In-Reply-To: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: e04e44772e0ad72f7751591e8aa1bd99 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2273 [Feb 21 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 14:34:00 -0000 --M8LGuhT/2+u1DQ9j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 03:02:47PM +0100, Kai Wang wrote: > On Thu, Feb 21, 2008 at 02:12:09PM +0100, Kai Wang wrote: > > Hello list, > >=20 > > I just committed ar(1) front-end. Note that you NEED update your > > world before you can successfully perform cross platform buildworld. > >=20 > > You can update your system by: > > make buildworld > > ... > > make installworld > >=20 > > or you can just install ar(1) by hand. > > (replace /usr/bin/ar and /usr/bin/ranlib by hand) > >=20 > > This is needed because GNU Binutils ar and ranlib gets renamed to gar > > and granlib, and when you perform a cross platform buildworld, the > > build system will instead use /usr/bin/ar and /usr/bin/ranlib, which > > is not capable of cross build. >=20 > I think it's neccessary to explain it a bit. When you start > cross-platform world build, the toolchain targarting that platform > will be built first. Then the resulting cross-platform toolchain is > used to build the world for that platform. ar(1) and ranlib(1) are > part of the toolchain. >=20 > After I renamed them to gar and granlib, the build system can no > longer find them, as a result it will use default ones, i.e., > /usr/bin/ar and /usr/bin/ranlib, which target your current platform > and thus can not be used to cross build. >=20 > You can solve this problem by updating your own world first, or by=20 > replacing '/usr/bin/ar' and '/usr/bin/ranlib' with 'BSD' ar and ranlib > by hand. 'BSD' ar is platform independent and handles all the ELF > targets thus can be used directly (no need to recompile itself for > target platform) by the build system. Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this is a huge regression. --M8LGuhT/2+u1DQ9j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEUEARECAAYFAke9i88ACgkQC3+MBN1Mb4hRMQCTB1QYwK37HvcuB1pWZTVRdBDi BQCgoGqz2Bzl3ZdavS8WZzc80kA6OBI= =ev9C -----END PGP SIGNATURE----- --M8LGuhT/2+u1DQ9j-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:37:38 2008 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 99AD716A400; Thu, 21 Feb 2008 14:37:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E9F9C13C448; Thu, 21 Feb 2008 14:37:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B3CDC43D995; Thu, 21 Feb 2008 16:37:36 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMIl64jZnwjr; Thu, 21 Feb 2008 16:37:36 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2A1C543D699; Thu, 21 Feb 2008 16:37:36 +0200 (EET) Message-ID: <47BD8CAF.9090908@icyb.net.ua> Date: Thu, 21 Feb 2008 16:37:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Bruce Evans References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> <20080222005213.W5655@besplex.bde.org> In-Reply-To: <20080222005213.W5655@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) 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, 21 Feb 2008 14:37:38 -0000 on 21/02/2008 16:27 Bruce Evans said the following: > On Thu, 21 Feb 2008, Andriy Gapon wrote: > >> on 17/02/2008 13:39 Andriy Gapon said the following: >>> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >>> [ufs/ffs] newfs can do it. >>> But with newfs_msdos I had to run disklabel first and then I could >>> create a filesystem on cdXa, but I couldn't do it on the whole disk. >> It seems that the reason for this newfs_msdos behavior is in the >> following lines: >> if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) >> errx(1, "Cannot get sector size, %s", strerror(errno)); >> if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) >> errx(1, "Cannot get number of sectors, %s", strerror(errno)); >> if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) >> errx(1, "Cannot get number of heads, %s", strerror(errno)); >> >> While a failure to get sector size is a serious situation indeed, number >> of sectors per track and number of heads are just relics of the past and >> are not applicable to all types of should-be-supported media. >> What's even more funny is that those values can be set via command line >> options and in that case values from ioctl are not used at all. > > Also, it needs the BIOS geometry, but has been broken to ask for, and Bruce, you lost me after this. I understand that you speak about a general case, but is there a "BIOS geometry" for DVD-RAM disk ? Would any information about physical structure of DVD-RAM disk prove useful for FAT on it ? I thought that all those CHS parameters were useful only in times when CHS was the disk access mode (and maybe for performance optimizations). I don't see how those parameters can be of any real use now. P.S. I must declare that I know zero about FAT. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:55:53 2008 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 443C416A405 for ; Thu, 21 Feb 2008 14:55:53 +0000 (UTC) (envelope-from cs@legacy.schug.net) Received: from legacy.schug.net (legacy.schug.Net [194.97.148.165]) by mx1.freebsd.org (Postfix) with ESMTP id 033F713C45A for ; Thu, 21 Feb 2008 14:55:52 +0000 (UTC) (envelope-from cs@legacy.schug.net) Received: by legacy.schug.net (Postfix, from userid 10000) id C99A410F665A; Thu, 21 Feb 2008 15:37:48 +0100 (CET) Date: Thu, 21 Feb 2008 15:37:48 +0100 From: Christoph Schug To: Pyun YongHyeon Message-ID: <20080221143748.GE10726@lega.schug.net> References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221050635.GC26427@cdnetworks.co.kr> User-Agent: Mutt/1.5.13 OpenPKG/2-STABLE (2006-08-11) Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 21 Feb 2008 14:55:53 -0000 On Thu, Feb 21, 2008, Pyun YongHyeon wrote: > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > HEAD/RELENG_7 to if_re.c). That would make it build on your box. I am having the very same problem on a rented Hetzner DS8000 root server offering [1]. According to sysutils/dmidecode from the ports the main board is a MSI K9AG Neo2-Digital (MS-7368) [2] with an embedded RTL8168/8111 PCI-E Gigabit Ethernet NIC (re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00). [1] http://www.hetzner.de/rootserver.html [2] http://www.msicomputer.com/product/p_spec.asp?model=K9AG_Neo2-Digital&class=mb > > Yes, I've been down the heat path, but the problem takes ~36 hours to recur > > both if the system is turned on from cold, or simply rebooted. Mind you, > > North Queensland could do with some cooling! I will take another look at the > > circuitry if moving to HEAD's re doesn't fix it. Interestingly enough, in my case it takes a similar amount of time but I can speed up the problem to show up when doing many disk (!) I/O operations on the 3ware RAID controller. Furthermore calling programs like 'rpm -Uvh' which draw a progress bar by sending many hash ('#') characters in a short period of time are very "helpful" to freeze the session while other SSH sessions during the same time still work flawlessly. 'netstat -an' shows pretty high numbers in the send queue of the freezed session. Will give re(4) of HEAD a try despite the fact that I would be very happy to see a fix in RELENG_7 as I have to bring to machine into production very soon. Thanks for the hint! -cs From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:59:01 2008 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 7325C16A407; Thu, 21 Feb 2008 14:59:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 441FB13C4E1; Thu, 21 Feb 2008 14:59:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LEx0Tb069866; Thu, 21 Feb 2008 09:59:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LEx0au063986; Thu, 21 Feb 2008 09:59:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 22A9973039; Thu, 21 Feb 2008 09:59:00 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221145900.22A9973039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 09:59:00 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner4 X-Virus-Status: Clean 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, 21 Feb 2008 14:59:01 -0000 TB --- 2008-02-21 14:44:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 14:44:09 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-21 14:44:09 - cleaning the object tree TB --- 2008-02-21 14:44:46 - cvsupping the source tree TB --- 2008-02-21 14:44:46 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-21 14:44:54 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 14:44:54 - cd /src TB --- 2008-02-21 14:44:54 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 14:44:57 UTC 2008 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/ia64/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 14:58:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 14:58:59 - ERROR: failed to build world TB --- 2008-02-21 14:58:59 - tinderbox aborted TB --- 602.02 user 70.68 system 890.51 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 14:56:19 2008 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 4A98816A406; Thu, 21 Feb 2008 14:56:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id D956213C4E7; Thu, 21 Feb 2008 14:56:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LEuEZS016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:56:16 +1100 Date: Fri, 22 Feb 2008 01:56:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <47BD8CAF.9090908@icyb.net.ua> Message-ID: <20080222014649.X29998@delplex.bde.org> References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> <20080222005213.W5655@besplex.bde.org> <47BD8CAF.9090908@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 21 Feb 2008 15:00:02 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Bruce Evans , freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) 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, 21 Feb 2008 14:56:19 -0000 On Thu, 21 Feb 2008, Andriy Gapon wrote: > on 21/02/2008 16:27 Bruce Evans said the following: >> On Thu, 21 Feb 2008, Andriy Gapon wrote: >> >>> on 17/02/2008 13:39 Andriy Gapon said the following: >>>> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >>>> [ufs/ffs] newfs can do it. >>>> But with newfs_msdos I had to run disklabel first and then I could >>>> create a filesystem on cdXa, but I couldn't do it on the whole disk. >>> It seems that the reason for this newfs_msdos behavior is in the >>> following lines: >>> if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) >>> errx(1, "Cannot get sector size, %s", strerror(errno)); >>> if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) >>> errx(1, "Cannot get number of sectors, %s", strerror(errno)); >>> if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) >>> errx(1, "Cannot get number of heads, %s", strerror(errno)); >>> >>> While a failure to get sector size is a serious situation indeed, number >>> of sectors per track and number of heads are just relics of the past and >>> are not applicable to all types of should-be-supported media. >>> What's even more funny is that those values can be set via command line >>> options and in that case values from ioctl are not used at all. >> >> Also, it needs the BIOS geometry, but has been broken to ask for, and > you lost me after this. I understand that you speak about a general > case, but is there a "BIOS geometry" for DVD-RAM disk ? Probably not. Docs say "for interrupt 0x13... only relevant for media that have a geometry". > Would any information about physical structure of DVD-RAM disk prove > useful for FAT on it ? The geometry fields might only be used by the bootstrap even on media that has a geometry. Since newfs_msdos writes a dummy bootstrap that doesn't support media accesses, we don't have to initialize them for that. > I thought that all those CHS parameters were useful only in times when > CHS was the disk access mode (and maybe for performance optimizations). > I don't see how those parameters can be of any real use now. That is probably correct, but since we don't control all uses of these fields, we should try to initialize them correctly. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:05:28 2008 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 C936916A407; Thu, 21 Feb 2008 15:05:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC9213C447; Thu, 21 Feb 2008 15:05:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LF5RCj082958; Thu, 21 Feb 2008 10:05:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LF5RwQ097476; Thu, 21 Feb 2008 10:05:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4A20873039; Thu, 21 Feb 2008 10:05:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221150527.4A20873039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 10:05:27 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner4 X-Virus-Status: Clean 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, 21 Feb 2008 15:05:29 -0000 TB --- 2008-02-21 14:50:57 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 14:50:57 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-21 14:50:57 - cleaning the object tree TB --- 2008-02-21 14:51:22 - cvsupping the source tree TB --- 2008-02-21 14:51:22 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-21 14:51:28 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 14:51:28 - cd /src TB --- 2008-02-21 14:51:28 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 14:51:29 UTC 2008 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/powerpc/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 15:05:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 15:05:27 - ERROR: failed to build world TB --- 2008-02-21 15:05:27 - tinderbox aborted TB --- 612.81 user 70.61 system 869.82 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:11:43 2008 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 ABE8E16A402; Thu, 21 Feb 2008 15:11:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7F20E13C4E3; Thu, 21 Feb 2008 15:11:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFBhw6084055; Thu, 21 Feb 2008 10:11:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFBglP080182; Thu, 21 Feb 2008 10:11:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A6F2573039; Thu, 21 Feb 2008 10:11:42 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221151142.A6F2573039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 10:11:42 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean 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, 21 Feb 2008 15:11:43 -0000 TB --- 2008-02-21 14:59:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 14:59:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-21 14:59:00 - cleaning the object tree TB --- 2008-02-21 14:59:06 - cvsupping the source tree TB --- 2008-02-21 14:59:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-21 14:59:11 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 14:59:11 - cd /src TB --- 2008-02-21 14:59:11 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 14:59:13 UTC 2008 >>> 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 [...] cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sparc64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/sparc64/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 15:11:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 15:11:42 - ERROR: failed to build world TB --- 2008-02-21 15:11:42 - tinderbox aborted TB --- 526.06 user 68.00 system 762.45 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:14:03 2008 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 AE26916A405 for ; Thu, 21 Feb 2008 15:14:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7CB13C442 for ; Thu, 21 Feb 2008 15:14:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JSD7V-0006TX-QS for freebsd-current@freebsd.org; Thu, 21 Feb 2008 15:13:57 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 15:13:57 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 15:13:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 21 Feb 2008 16:16:24 +0100 Lines: 29 Message-ID: References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6127075BC0A18CE2C94E5A95" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: <20080221143351.GP57756@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 15:14:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6127075BC0A18CE2C94E5A95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this is = a > huge regression. Why wouldn't it, unless you're building amd64 CURRENT on i386 RELENG_[67] or a similar combination? --------------enig6127075BC0A18CE2C94E5A95 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHvZXIldnAQVacBcgRAnI8AJ9CPY0XvNFG3GU2lCE4I8a3TMgZcwCfQJb/ L7+57VS/9T7IWt5sAVWluuo= =yjLt -----END PGP SIGNATURE----- --------------enig6127075BC0A18CE2C94E5A95-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:17:08 2008 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 4AF7816A401; Thu, 21 Feb 2008 15:17:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1C14213C455; Thu, 21 Feb 2008 15:17:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFH7qw072393; Thu, 21 Feb 2008 10:17:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFH7Go017875; Thu, 21 Feb 2008 10:17:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0D11C73039; Thu, 21 Feb 2008 10:17:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221151707.0D11C73039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 10:17:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean 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, 21 Feb 2008 15:17:08 -0000 TB --- 2008-02-21 15:05:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 15:05:27 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-21 15:05:27 - cleaning the object tree TB --- 2008-02-21 15:05:37 - cvsupping the source tree TB --- 2008-02-21 15:05:37 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-21 15:05:42 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 15:05:42 - cd /src TB --- 2008-02-21 15:05:42 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 15:05:43 UTC 2008 >>> 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 [...] cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fPIC -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/sun4v/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DSUN4V -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/sun4v/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 15:17:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 15:17:07 - ERROR: failed to build world TB --- 2008-02-21 15:17:07 - tinderbox aborted TB --- 523.34 user 68.30 system 699.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:24:16 2008 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 836B816A400 for ; Thu, 21 Feb 2008 15:24:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 23BF813C45B for ; Thu, 21 Feb 2008 15:24:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSDHP-0008fi-Pj; Thu, 21 Feb 2008 15:24:14 +0000 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1LFNhxj026969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 17:23:43 +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.2/8.14.2) with ESMTP id m1LFO5Hu061737; Thu, 21 Feb 2008 17:24:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1LFO57l061736; Thu, 21 Feb 2008 17:24:05 +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: Thu, 21 Feb 2008 17:24:05 +0200 From: Kostik Belousov To: Ivan Voras Message-ID: <20080221152404.GQ57756@deviant.kiev.zoral.com.ua> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xIv6ePYtapqpq3Si" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 3140350ce96b4815fe22a3a842dc7b15 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2274 [Feb 21 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 15:24:16 -0000 --xIv6ePYtapqpq3Si Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 04:16:24PM +0100, Ivan Voras wrote: > Kostik Belousov wrote: >=20 > > Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this is a > > huge regression. >=20 > Why wouldn't it, unless you're building amd64 CURRENT on i386 > RELENG_[67] or a similar combination? >=20 Exactly. --xIv6ePYtapqpq3Si Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke9l5QACgkQC3+MBN1Mb4hVPwCdF9dBE1O9y+2zocrFEQCMVjkQ TPsAn1ud+oUTzwtJrCw7s2QrMmddcL2z =gObx -----END PGP SIGNATURE----- --xIv6ePYtapqpq3Si-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:30:33 2008 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 4556416A401 for ; Thu, 21 Feb 2008 15:30:33 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id AD92913C44B for ; Thu, 21 Feb 2008 15:30:32 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so92296fka.11 for ; Thu, 21 Feb 2008 07:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=28NKwdDGsNGwL7r/tNpH/ydsuZWlpTZgS7xE8z1pC2A=; b=pQPcE6uh9AtVw+XB10i/SwBiF4S5S2VBOm5uKSddUwWldHUzXSRTdgahJde0pYn+5c/8nyfgn5bvFH3n0gBxOuVK+KJCJADp3pir+4HhgJoskpYu1aHYB1zNpvOcnaw6dshAC7e4D0IQxoKufjiweDzYs13srCARd5Iek4KvjN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=WetrArVQw6+8RM+QL+IA/uKa7YiQ/mBRZ2oip5xejFGqd72lKVNDph76CjOwOHkqsW4vP6lNd67P8GnB+KyLS1CzilBpdojDtYw3aJ1BCcuMth20wiqJrcHnQbwAYNmmXRxAbln0JelFxR2/s7toGfkFEvAcP5yNwWullp/haOc= Received: by 10.82.160.19 with SMTP id i19mr17131748bue.23.1203607831273; Thu, 21 Feb 2008 07:30:31 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id i6sm182956gve.5.2008.02.21.07.30.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 07:30:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSDNS-0000LP-I4; Thu, 21 Feb 2008 16:30:26 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1LFUQ95001326; Thu, 21 Feb 2008 16:30:26 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Thu, 21 Feb 2008 16:30:26 +0100 From: Kai Wang To: Ivan Voras Message-ID: <20080221153026.GB1022@plan0.kaiwan.csbnet.se> Mail-Followup-To: Ivan Voras , freebsd-current@freebsd.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 15:30:33 -0000 On Thu, Feb 21, 2008 at 04:16:24PM +0100, Ivan Voras wrote: > Kostik Belousov wrote: > > > Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this is a > > huge regression. > > Why wouldn't it, unless you're building amd64 CURRENT on i386 > RELENG_[67] or a similar combination? That's right... I didn't consider this situation before... Building amd64 CURRENT on i386 RELENG_[67] won't work. I'll see what I can do, I think we probably need revert back to let Binutils ar to handle the cross build. My Makefile knowledge is very poor, is there a way to let the build system use Binutils 'ar' in the building process but later install it as 'gar'? Thanks, -- Kai From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:32:49 2008 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 686E816A401; Thu, 21 Feb 2008 15:32:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3A16E13C46E; Thu, 21 Feb 2008 15:32:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFWmmC087244; Thu, 21 Feb 2008 10:32:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFWmN0060444; Thu, 21 Feb 2008 10:32:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ECC2873039; Thu, 21 Feb 2008 10:32:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221153247.ECC2873039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 10:32:47 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm 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, 21 Feb 2008 15:32:49 -0000 TB --- 2008-02-21 15:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 15:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-02-21 15:20:00 - cleaning the object tree TB --- 2008-02-21 15:20:12 - cvsupping the source tree TB --- 2008-02-21 15:20:12 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-02-21 15:20:18 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 15:20:18 - cd /src TB --- 2008-02-21 15:20:18 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 15:20:20 UTC 2008 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcswidth.c -o wcswidth.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/arm -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/arm/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/arm/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/arm/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 15:32:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 15:32:47 - ERROR: failed to build world TB --- 2008-02-21 15:32:47 - tinderbox aborted TB --- 544.28 user 71.24 system 767.58 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:34:54 2008 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 472BC16A40A; Thu, 21 Feb 2008 15:34:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F2B4C13C467; Thu, 21 Feb 2008 15:34:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFYrox076237; Thu, 21 Feb 2008 10:34:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1LFYrnL062804; Thu, 21 Feb 2008 10:34:53 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 05C2973039; Thu, 21 Feb 2008 10:34:53 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080221153453.05C2973039@freebsd-current.sentex.ca> Date: Thu, 21 Feb 2008 10:34:53 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean 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, 21 Feb 2008 15:34:54 -0000 TB --- 2008-02-21 15:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-21 15:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-02-21 15:20:00 - cleaning the object tree TB --- 2008-02-21 15:20:12 - cvsupping the source tree TB --- 2008-02-21 15:20:12 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-02-21 15:20:17 - building world (CFLAGS=-O -pipe) TB --- 2008-02-21 15:20:17 - cd /src TB --- 2008-02-21 15:20:17 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 21 15:20:19 UTC 2008 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wcsxfrm.c -o wcsxfrm.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemchr.c -o wmemchr.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcmp.c -o wmemcmp.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemcpy.c -o wmemcpy.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemmove.c -o wmemmove.So cc -fpic -DPIC -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/amd64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /obj/amd64/src/tmp/usr/lib/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-21 15:34:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-21 15:34:52 - ERROR: failed to build world TB --- 2008-02-21 15:34:52 - tinderbox aborted TB --- 645.73 user 79.27 system 892.66 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:41:02 2008 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 81DF216A403; Thu, 21 Feb 2008 15:41:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com (anti-4.kiev.sovam.com [62.64.120.202]) by mx1.freebsd.org (Postfix) with ESMTP id 132F813C448; Thu, 21 Feb 2008 15:41:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSDXc-0001mB-O6; Thu, 21 Feb 2008 17:41:00 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1LFeDCT027461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 17:40:13 +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.2/8.14.2) with ESMTP id m1LFeZWr003727; Thu, 21 Feb 2008 17:40:35 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1LFeZYv003726; Thu, 21 Feb 2008 17:40:35 +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: Thu, 21 Feb 2008 17:40:35 +0200 From: Kostik Belousov To: Ivan Voras , freebsd-current@freebsd.org Message-ID: <20080221154035.GR57756@deviant.kiev.zoral.com.ua> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221153026.GB1022@plan0.kaiwan.csbnet.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5WxJcm1aAlURz5l8" Content-Disposition: inline In-Reply-To: <20080221153026.GB1022@plan0.kaiwan.csbnet.se> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: f216f799903dddc2f9accd11d8a1fded X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2275 [Feb 21 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 15:41:02 -0000 --5WxJcm1aAlURz5l8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 04:30:26PM +0100, Kai Wang wrote: > On Thu, Feb 21, 2008 at 04:16:24PM +0100, Ivan Voras wrote: > > Kostik Belousov wrote: > >=20 > > > Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this i= s a > > > huge regression. > >=20 > > Why wouldn't it, unless you're building amd64 CURRENT on i386 > > RELENG_[67] or a similar combination? >=20 > That's right... I didn't consider this situation before... > Building amd64 CURRENT on i386 RELENG_[67] won't work. I'll see what > I can do, I think we probably need revert back to let Binutils ar to > handle the cross build. Yes, please. This is critical for my work. > My Makefile knowledge is very poor, is there a way to let the build > system use Binutils 'ar' in the building process but later install > it as 'gar'? >=20 > Thanks, > -- > Kai --5WxJcm1aAlURz5l8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke9m3IACgkQC3+MBN1Mb4iVOQCeM5QGQSXhnnESTmefbnJNXgJe 8i4AnjZEdO/kY+LnTE2nDE5XLLHFQRAz =HRVE -----END PGP SIGNATURE----- --5WxJcm1aAlURz5l8-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:45:30 2008 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 00C3116A5B0 for ; Thu, 21 Feb 2008 15:45:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A75D813C455 for ; Thu, 21 Feb 2008 15:45:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JSDc0-00086g-Ck for freebsd-current@freebsd.org; Thu, 21 Feb 2008 15:45:28 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 15:45:28 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2008 15:45:28 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 21 Feb 2008 16:47:52 +0100 Lines: 37 Message-ID: References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152404.GQ57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7834D2198D0C9A4FDBB26751" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: <20080221152404.GQ57756@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 15:45:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7834D2198D0C9A4FDBB26751 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > On Thu, Feb 21, 2008 at 04:16:24PM +0100, Ivan Voras wrote: >> Kostik Belousov wrote: >> >>> Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this i= s a >>> huge regression. >> Why wouldn't it, unless you're building amd64 CURRENT on i386 >> RELENG_[67] or a similar combination? >> > Exactly. Maybe a note like "please symlink ar to gar before attempting this kind update" would be sufficient? Or the similar notion built into the makefil= e? --------------enig7834D2198D0C9A4FDBB26751 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHvZ0wldnAQVacBcgRAvqoAKDeElxUVWM76/iDeBn3RUgUNcqbAACg5bal kJS6ptPNQmp3yBvanMOTyjA= =ZlQL -----END PGP SIGNATURE----- --------------enig7834D2198D0C9A4FDBB26751-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:47:02 2008 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 6A91416A401; Thu, 21 Feb 2008 15:47:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCB613C45A; Thu, 21 Feb 2008 15:47:02 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 7750E2092; Thu, 21 Feb 2008 16:46:56 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 6A6EA2091; Thu, 21 Feb 2008 16:46:56 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 50E8C844B5; Thu, 21 Feb 2008 16:46:56 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: FreeBSD Tinderbox References: <20080221122947.AFBB973039@freebsd-current.sentex.ca> <20080221131451.GB2022@plan0.kaiwan.csbnet.se> Date: Thu, 21 Feb 2008 16:46:56 +0100 In-Reply-To: <20080221131451.GB2022@plan0.kaiwan.csbnet.se> (Kai Wang's message of "Thu\, 21 Feb 2008 14\:14\:51 +0100") Message-ID: <86hcg271n3.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 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, 21 Feb 2008 15:47:02 -0000 Kai Wang writes: > Tinderbox need a new world before it can successfully perform cross-platf= orm > buildworld. (Please refer to the headsup I just posted in current@) No, this is unacceptable. Back it out. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:47:47 2008 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 6638A16A404; Thu, 21 Feb 2008 15:47:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id E53A813C467; Thu, 21 Feb 2008 15:47:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSDe9-000Gui-Ie; Thu, 21 Feb 2008 15:47:44 +0000 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1LFkqhG027682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 17:46:52 +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.2/8.14.2) with ESMTP id m1LFlETM003984; Thu, 21 Feb 2008 17:47:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1LFlEUn003983; Thu, 21 Feb 2008 17:47:14 +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: Thu, 21 Feb 2008 17:47:14 +0200 From: Kostik Belousov To: Alexander Nedotsukov Message-ID: <20080221154714.GS57756@deviant.kiev.zoral.com.ua> References: <4792C32C.5010205@gmail.com> <20080122133835.GT57756@deviant.kiev.zoral.com.ua> <4796356D.9080809@gmail.com> <20080123051648.GV57756@deviant.kiev.zoral.com.ua> <479796E1.4000500@gmail.com> <1201118159.38742.17.camel@shumai.marcuscom.com> <20080123211149.GA57756@deviant.kiev.zoral.com.ua> <1201123933.62127.9.camel@shumai.marcuscom.com> <20080124124213.GD57756@deviant.kiev.zoral.com.ua> <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LMbs3ReFgmH17S4B" Content-Disposition: inline In-Reply-To: <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 5705bde2e570895834f5a69800e19fe2 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2275 [Feb 21 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: FreeBSD Current , Joe Marcus Clarke Subject: Re: page fault panic in scioctl and console-kit-daemon 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, 21 Feb 2008 15:47:47 -0000 --LMbs3ReFgmH17S4B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov wrote: > Hi, >=20 > May I ask to revisit this issue? To me ENXIO is not semantically =20 > correct in this particular case. It also turns out that doing =20 > workaround in userspace may not be that good as we used to think. I =20 > propose is to fix VT_WAITACTIVE so it simply wait for bound device =20 > activation. For my understanding this change should not have any =20 > impact on existing code. I also removed really strange console cleanup = =20 > bit sticked in a long time ago (see ioctl() part). > It will be nice to see this patch=20 > (successfully tested by our affected users) committed to all branches. >=20 > Thanks, > Alexander. I mostly agree with the patch, given it is tested. The first (not important) note is that change of the wait channel from the address of the private structure to the address of the cdev could cause more spurious wakeups then before. I expect you usermode code to deal with it properly. Second one is that I do not understand the reason to have sc_clean_up() there except that it might be to help the screen switching. The commit message for the rev. 1.307, where it seems to be introduced, is not useful at all. Any comments ? >=20 > On 24.01.2008, at 21:42, Kostik Belousov wrote: >=20 > >On Wed, Jan 23, 2008 at 04:32:13PM -0500, Joe Marcus Clarke wrote: > >> > >>On Wed, 2008-01-23 at 23:11 +0200, Kostik Belousov wrote: > >>>On Wed, Jan 23, 2008 at 02:55:59PM -0500, Joe Marcus Clarke wrote: > >>>> > >>>>On Wed, 2008-01-23 at 20:34 +0100, Pawel Worach wrote: > >>>>>Kostik Belousov wrote: > >>>>>>On Tue, Jan 22, 2008 at 07:26:53PM +0100, Pawel Worach wrote: > >>>>>>>Kostik Belousov wrote: > >>>>>>>>On Sun, Jan 20, 2008 at 04:42:36AM +0100, Pawel Worach wrote: > >>>>>>>>>Hi, > >>>>>>>>> > >>>>>>>>>While starting console-kit-daemon (sysutils/consolekit =20 > >>>>>>>>>0.2.3) during > >>>>>>>>>boot or in single-user mode the system panics. If I start it =20 > >>>>>>>>>post-boot > >>>>>>>>>it runs fine. This is on 8.0-CURRENT from about 12 hours =20 > >>>>>>>>>ago, another > >>>>>>>>>user also reported the same on RELENG_7. Any other =20 > >>>>>>>>>information I can > >>>>>>>>>provide ? > >>>>>>>>> > >>>>>>>>>Fatal trap 12: page fault while in kernel mode > >>>>>>>>>fault virtual address =3D 0x4 > >>>>>>>>>fault code =3D supervisor read, page not present > >>>>>>>>>instruction pointer =3D 0x20:0xc04d2ab4 > >>>>>>>>>stack pointer =3D 0x28:0xe6499b18 > >>>>>>>>>frame pointer =3D 0x28:0xe6499b80 > >>>>>>>>>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 134 (console-kit-daemon) > >>>>>>>>>Physical memory: 1014 MB > >>>>>>>>>Dumping 43 MB: 28 12 > >>>>>>>>> > >>>>>>>>>#8 0xc07a34a2 in trap (frame=3D0xe6499ad8) at > >>>>>>>>>/usr/src/sys/i386/i386/trap.c:489 > >>>>>>>>>#9 0xc079183b in calltrap () at /usr/src/sys/i386/i386/=20 > >>>>>>>>>exception.s:146 > >>>>>>>>>#10 0xc04d2ab4 in scioctl (dev=3D0xc3b20d00, cmd=3D537163270, > >>>>>>>>> data=3D0xe6499c70 "\002", flag=3D1, td=3D0xc3d3c880) > >>>>>>>>> at /usr/src/sys/dev/syscons/syscons.c:1073 > >>>>>>>>>#11 0xc051ed1a in giant_ioctl (dev=3D0xc3b20d00, cmd=3D537163270, > >>>>>>>>> data=3D0xe6499c70 "\002", fflag=3D1, td=3D0xc3d3c880) > >>>>>>>>> at /usr/src/sys/kern/kern_conf.c:349 > >>>>>>>>>#12 0xc0598194 in cnioctl (dev=3D0xc3b20d00, cmd=3D537163270, > >>>>>>>>> data=3D0xe6499c70 "\002", flag=3D1, td=3D0xc3d3c880) > >>>>>>>>>---Type to continue, or q to quit--- > >>>>>>>>> at /usr/src/sys/kern/tty_cons.c:521 > >>>>>>>>Unless the virtual screen is opened, the screen state =20 > >>>>>>>>scr_stat structure > >>>>>>>>is not allocated. The following patch would fix the panic, =20 > >>>>>>>>but I do not > >>>>>>>>know how the console-kit would react to the ENXIO from the > >>>>>>>>VT_WAITACTIVE ioctl. Please, test it. > >>>>>>>Thanks! The patch works. > >>>>>> > >>>>>>To clarify: do you see any problems with the console-kit after =20 > >>>>>>the patch ? > >>>>>>In particular, can you verify that the program functions =20 > >>>>>>correctly, esp. > >>>>>>on the virtual terminals 1, 2 ... , whatever this means ? > >>>>> > >>>>>The panic is of course gone, while chatting a bit with Marcus =20 > >>>>>(CCd) it > >>>>>looks like console-kit does not do any error handling at all. =20 > >>>>>I've not > >>>>>looked at what c-k does so maybe Marcus can answer the question =20 > >>>>>better. > >>>> > >>>>It tries to install a wait thread on each available VT. That =20 > >>>>thread > >>>>sets the WAITACTIVE ioctl, and waits for its VT to become =20 > >>>>active. When > >>>>it does, it sets the CK active VT accordingly, and reattaches the =20 > >>>>wait. > >>>> > >>>>When an error occurs in the ioctl, no wait is attached, and CK =20 > >>>>will not > >>>>know when a particular VT becomes active. This will essentially =20 > >>>>cripple > >>>>CK (assuming the VT really does become available at a later point). > >>>> > >>>>Now, admittedly, there is no error correction in CK for this =20 > >>>>situation. > >>>>It would be trivial to add something that periodically attempts to > >>>>reestablish a failed wait. However, I am very curious why only a =20 > >>>>few > >>>>users are seeing this panic (me excluded on two different =20 > >>>>machines). It > >>>>seems to me that the scp should be initialized when =20 > >>>>sc_attach_unit() is > >>>>called during device probing. I don't see anything special in =20 > >>>>init(8)'s > >>>>code that would cause these VT devices to become initialized. I =20 > >>>>would > >>>>assume that if one can open(2) them, then they should be =20 > >>>>available for > >>>>ioctls? > >>> > >>>From my reading of the code, scp would be non-NULL after the first =20 > >>>open > >>>of the corresponding /dev/ttyvX. sc_attach_unit() creates the scp =20 > >>>for > >>>the console and the consolectl devices. > >>> > >>>VT_WAITACTIVE ioctl is performed on arbitrary syscons /dev node, and > >>>can wait for any other screens, in particular, the screens that are > >>>not opened at the moment (the reason for the reported panic). > >> > >>Right, and this is where I was confused. I had thought from an old > >>reading of the CK code that CK opened each ttyvX device to perform =20 > >>the > >>ioctl. It does not. Instead, it opens /dev/console, and performs =20 > >>the > >>ioctl for each ttyvX on that fd. That does explain the panic, but =20 > >>not > >>exactly why I did not see it. I'm guessing a race condition, but I > >>can't be sure. > >> > >>> > >>>The patch I posted may be improved by making the VT_WAITACTIVE ioctl > >>>to wait for the scp being allocated, and only then for the screen =20 > >>>to be > >>>switched too. Please, test. > >> > >>I really appreciate your attention to this. Funny thing is, CK 0.2.4 > >>was just released, and it is no longer started out of rc.d. I've =20 > >>also > >>added error correcting in the CK code path. The problem may =20 > >>disappear > >>depending on when CK is executed out of D-BUS. However, it would be > >>good to prevent this in the kernel. Pawel said he would try and test > >>this patch. > > > >This must be fixed in the kernel, at least because it allows any =20 > >console > >user to panic the system. The question I have to you is what =20 > >approach shall > >we use: > >- return the ENXIO (1) > >- do the wait for the open, then wait for the switch (2) > > > >I would prefer (1), both due to putting the decision to the =20 > >userspace, and > >to not have the algorithm that could be implemented in userspace, in =20 > >the > >kernel. On the other hand, as the maintainer of the one of the major =20 > >API > >consumer there, you may have the different opinion, that is crusial. >=20 --LMbs3ReFgmH17S4B Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke9nQIACgkQC3+MBN1Mb4jnSwCfbX0xWNffMszpUZM3SmB+dm6m H8cAoOUsCn1VhOCnOPbisbnWeV1hN6pp =egYk -----END PGP SIGNATURE----- --LMbs3ReFgmH17S4B-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 15:50:28 2008 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 CFD9116A400; Thu, 21 Feb 2008 15:50:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB7F13C467; Thu, 21 Feb 2008 15:50:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSDgl-000Hoa-VU; Thu, 21 Feb 2008 15:50:27 +0000 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1LFnlf1027743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 17:49:47 +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.2/8.14.2) with ESMTP id m1LFo9KL004066; Thu, 21 Feb 2008 17:50:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1LFo932004065; Thu, 21 Feb 2008 17:50:09 +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: Thu, 21 Feb 2008 17:50:09 +0200 From: Kostik Belousov To: Ivan Voras Message-ID: <20080221155008.GT57756@deviant.kiev.zoral.com.ua> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152404.GQ57756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="utW7cflQPA+9Bfvi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 4204c266f86c3e9b1e0231505dd73b85 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2275 [Feb 21 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 15:50:28 -0000 --utW7cflQPA+9Bfvi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 04:47:52PM +0100, Ivan Voras wrote: > Kostik Belousov wrote: > > On Thu, Feb 21, 2008 at 04:16:24PM +0100, Ivan Voras wrote: > >> Kostik Belousov wrote: > >> > >>> Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this i= s a > >>> huge regression. > >> Why wouldn't it, unless you're building amd64 CURRENT on i386 > >> RELENG_[67] or a similar combination? > >> > > Exactly. >=20 > Maybe a note like "please symlink ar to gar before attempting this kind > update" would be sufficient? Or the similar notion built into the makefil= e? This is not an update. Instead, this is normal and often exercised part of the workflow. --utW7cflQPA+9Bfvi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke9nbAACgkQC3+MBN1Mb4iwtACgniiNh6hPt2gZ5eKJ6YG+VbVD dOsAoNUFMhSn9L8/5/y5EisBExVyBt9t =UHvy -----END PGP SIGNATURE----- --utW7cflQPA+9Bfvi-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:01:14 2008 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 638DE16A400; Thu, 21 Feb 2008 16:01:14 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1509B13C45B; Thu, 21 Feb 2008 16:01:13 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=63686 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSDJ0-000Iic-27; Thu, 21 Feb 2008 15:25:50 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1LFPn4U021808; Thu, 21 Feb 2008 18:25:49 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1LFPn6x021807; Thu, 21 Feb 2008 18:25:49 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Thu, 21 Feb 2008 18:25:49 +0300 From: Ruslan Ermilov To: Ivan Voras Message-ID: <20080221152549.GB21518@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 16:01:14 -0000 On Thu, Feb 21, 2008 at 04:16:24PM +0100, Ivan Voras wrote: > Kostik Belousov wrote: > > > Shall the crossbuild for CURRENT work on RELENG_[67] ? If not, this is a > > huge regression. > > Why wouldn't it, unless you're building amd64 CURRENT on i386 > RELENG_[67] or a similar combination? > Using host ar(1) (/usr/bin/ar) for world builds is a bug. ar(1) needs to be either bootstrapped (if its code is platform-neutral) or built as part of cross-tools. That in turn means that we won't be able to upgrade to 8.0 (when it's released) from <7.0 (libelf exists only starting from 7.0). Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:01:18 2008 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 BDFBA16A405 for ; Thu, 21 Feb 2008 16:01:18 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1CF13C45B for ; Thu, 21 Feb 2008 16:01:18 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=2012 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSD9w-000IYb-2Z for freebsd-current@freebsd.org; Thu, 21 Feb 2008 15:16:28 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1LFGRkS021682 for ; Thu, 21 Feb 2008 18:16:27 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1LFGRXK021681 for freebsd-current@freebsd.org; Thu, 21 Feb 2008 18:16:27 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Thu, 21 Feb 2008 18:16:27 +0300 From: Ruslan Ermilov To: freebsd-current@freebsd.org Message-ID: <20080221151627.GA21518@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 16:01:18 -0000 On Thu, Feb 21, 2008 at 03:02:47PM +0100, Kai Wang wrote: > On Thu, Feb 21, 2008 at 02:12:09PM +0100, Kai Wang wrote: > > Hello list, > > > > I just committed ar(1) front-end. Note that you NEED update your > > world before you can successfully perform cross platform buildworld. > > > > You can update your system by: > > make buildworld > > ... > > make installworld > > > > or you can just install ar(1) by hand. > > (replace /usr/bin/ar and /usr/bin/ranlib by hand) > > > > This is needed because GNU Binutils ar and ranlib gets renamed to gar > > and granlib, and when you perform a cross platform buildworld, the > > build system will instead use /usr/bin/ar and /usr/bin/ranlib, which > > is not capable of cross build. > > I think it's neccessary to explain it a bit. When you start > cross-platform world build, the toolchain targarting that platform > will be built first. Then the resulting cross-platform toolchain is > used to build the world for that platform. ar(1) and ranlib(1) are > part of the toolchain. > > After I renamed them to gar and granlib, the build system can no > longer find them, as a result it will use default ones, i.e., > /usr/bin/ar and /usr/bin/ranlib, which target your current platform > and thus can not be used to cross build. > > You can solve this problem by updating your own world first, or by > replacing '/usr/bin/ar' and '/usr/bin/ranlib' with 'BSD' ar and ranlib > by hand. 'BSD' ar is platform independent and handles all the ELF > targets thus can be used directly (no need to recompile itself for > target platform) by the build system. > If BSD ar(1) is crossplatform-neutral, you just need to add it to bootstrap-tools, like this: : Index: Makefile.inc1 : =================================================================== : RCS file: /home/ncvs/src/Makefile.inc1,v : retrieving revision 1.598 : diff -u -p -r1.598 Makefile.inc1 : --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 : +++ Makefile.inc1 21 Feb 2008 15:11:07 -0000 : @@ -885,8 +885,13 @@ _crunchgen= usr.sbin/crunch/crunchgen : _mklocale= usr.bin/mklocale : .endif : : +.if ${BOOTSTRAPPING} < 800022 : +_ar= usr.bin/ar : +.endif : + : bootstrap-tools: : .for _tool in \ : + ${_ar} \ : ${_mklocale} \ : ${_strfile} \ : ${_gperf} \ Then the breakage will be gone. With this change, we also bump the minimum requirement for source upgrades from 6.0-RELEASE to "7.0-CURRENT at some point" because new ar(1) requires libelf which is not available in previous releases of FreeBSD. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:17:47 2008 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 5685E16A400 for ; Thu, 21 Feb 2008 16:17:47 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0E58313C43E for ; Thu, 21 Feb 2008 16:17:46 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 67EF22088; Thu, 21 Feb 2008 17:17:43 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D76D42087; Thu, 21 Feb 2008 17:17:42 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id B927D8448A; Thu, 21 Feb 2008 17:17:42 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jason Evans References: <20080219151809.GF57366@rambler-co.ru> <47BB0D29.5080403@freebsd.org> Date: Thu, 21 Feb 2008 17:17:42 +0100 In-Reply-To: <47BB0D29.5080403@freebsd.org> (Jason Evans's message of "Tue\, 19 Feb 2008 09\:08\:57 -0800") Message-ID: <86zltu5lnd.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Igor Sysoev , freebsd-current@FreeBSD.ORG Subject: Re: malloc(3) ignores RLIMIT_DATA 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, 21 Feb 2008 16:17:47 -0000 Jason Evans writes: > Igor Sysoev writes: > > malloc(3) in FreeBSD 7 uses mmap() (then sbrk() on 32-bit platform) > > and ignores RLIMIT_DATA. FreeBSD 8's malloc() can be configured > > to use sbrk() only ("Dm"), but default setting is "DM". > I plan to merge these changes to RELENG_7 shortly after FreeBSD 7.0 is > released. FWIW, I would prefer if sbrk support were simply ripped back out of jemalloc, and the brk() and sbrk() prototypes removed from the system headers to make it impossible for new software to use them. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 16:28:33 2008 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 41E3316A40D for ; Thu, 21 Feb 2008 16:28:33 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id B91CA13C442 for ; Thu, 21 Feb 2008 16:28:32 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so2544507uge.37 for ; Thu, 21 Feb 2008 08:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=SwrxBxMCZwdHitBDRzddB5Jzz/hagFeJU2V4TcowNtk=; b=L+nLvnh9tDj7j0th2mzZDt8AyBT08BsLNorh0R0Rx3ZgIJSUNgeOI0dlDmW4wJI8cvSn0Ue3tvxLqkGHV7b7TXEPekzpnLIPBuaKAqk9IARNox9vg3KtrUWw9OtcGkXsbb+XI7pnAQ8V/s5P/GeAOx/c2rzN3rbsXNVZYQ/1Qqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ITaC3r8OjwHQa4UPaCfmeciPnXbJKY0Yi9HKxZbgm2ZgwmbY3a42x9djGXyzfkdcmiJRticWZImihhhqFk/gi+KdvfrLYB3042knfZcG3JdVSeoVbB00Mwk4pDAKt/G3hRLvHyGWcN+Uq3Q+zzqNap4YU+bP+/HfxeSKRg+8krA= Received: by 10.67.92.4 with SMTP id u4mr1088104ugl.85.1203611310525; Thu, 21 Feb 2008 08:28:30 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id g9sm257968gvc.4.2008.02.21.08.28.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 08:28:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSEHa-0000Rk-1R; Thu, 21 Feb 2008 17:28:26 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1LGSPWF001719; Thu, 21 Feb 2008 17:28:25 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Thu, 21 Feb 2008 17:28:25 +0100 From: Kai Wang To: Ruslan Ermilov Message-ID: <20080221162825.GB1372@plan0.kaiwan.csbnet.se> Mail-Followup-To: Ruslan Ermilov , freebsd-current@freebsd.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221151627.GA21518@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080221151627.GA21518@team.vega.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 16:28:33 -0000 On Thu, Feb 21, 2008 at 06:16:27PM +0300, Ruslan Ermilov wrote: > : Index: Makefile.inc1 > : =================================================================== > : RCS file: /home/ncvs/src/Makefile.inc1,v > : retrieving revision 1.598 > : diff -u -p -r1.598 Makefile.inc1 > : --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 > : +++ Makefile.inc1 21 Feb 2008 15:11:07 -0000 > : @@ -885,8 +885,13 @@ _crunchgen= usr.sbin/crunch/crunchgen > : _mklocale= usr.bin/mklocale > : .endif > : > : +.if ${BOOTSTRAPPING} < 800022 > : +_ar= usr.bin/ar > : +.endif > : + > : bootstrap-tools: > : .for _tool in \ > : + ${_ar} \ > : ${_mklocale} \ > : ${_strfile} \ > : ${_gperf} \ > > Then the breakage will be gone. Hello Ruslan, Thanks for pointing me to the right place. > With this change, we also bump the minimum requirement for source > upgrades from 6.0-RELEASE to "7.0-CURRENT at some point" because > new ar(1) requires libelf which is not available in previous > releases of FreeBSD. I think this requirement bump is unacceptable for now, probably we can do this after the EOL of 6.x... I just backed out the Makefile changes, and I plan to let 'BSD' ar install as "bsdar", as Robert just suggested. Thanks, -- Kai From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:31:51 2008 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 B99F116A408; Thu, 21 Feb 2008 17:31:51 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8585A13C465; Thu, 21 Feb 2008 17:31:51 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1LHVpZv093791; Thu, 21 Feb 2008 09:31:51 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1LHVpDp093790; Thu, 21 Feb 2008 09:31:51 -0800 (PST) (envelope-from obrien) Date: Thu, 21 Feb 2008 09:31:51 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080221173150.GA93693@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Ivan Voras , freebsd-current@freebsd.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221152549.GB21518@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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, 21 Feb 2008 17:31:51 -0000 On Thu, Feb 21, 2008 at 06:25:49PM +0300, Ruslan Ermilov wrote: > in turn means that we won't be able to upgrade to 8.0 > (when it's released) from <7.0 (libelf exists only > starting from 7.0). And many of us don't feel that is a bad limitation. Upgrading to FreeBSD Y+2.x from Y.x is not _required_ to work. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:40:43 2008 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 2A7D616A402 for ; Thu, 21 Feb 2008 17:40:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id DB1AA13C459 for ; Thu, 21 Feb 2008 17:40:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 50540209B; Thu, 21 Feb 2008 18:40:37 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id C32482099; Thu, 21 Feb 2008 18:40:36 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 9D210844B5; Thu, 21 Feb 2008 18:40:36 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mikael Ikivesi References: <20080219104532.0dc2b565@chaos.nox> <47BAAADF.2000707@FreeBSD.org> <1203450520.7248.25.camel@localhost> Date: Thu, 21 Feb 2008 18:40:36 +0100 In-Reply-To: <1203450520.7248.25.camel@localhost> (Mikael Ikivesi's message of "Tue\, 19 Feb 2008 21\:48\:40 +0200") Message-ID: <86wsoy438r.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: 2 core dumps 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, 21 Feb 2008 17:40:43 -0000 Mikael Ikivesi writes: > On Tue, 2008-02-19 at 11:09 +0100, Kris Kennaway wrote:=20 > > Mikael Ikivesi wrote: > > > with RELENG_7 (4-7 days old) I have come across with 2 > > > panic/reboot. > > Both look like signs of failing hardware to me. > This didn't happen with RELENG_6. [...] I agree with Kris, it looks like hardware trouble. Are you sure your laptop is not overheating? Does it run powerd? Are the fans or exhaust louvers blocked? Have you tried booting without X and running 'make -j8 buildworld' or something similar? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:55:38 2008 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 CEBC316A404 for ; Thu, 21 Feb 2008 17:55:38 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA2213C442 for ; Thu, 21 Feb 2008 17:55:38 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4553:f20a:f619:870a] (unknown [IPv6:2001:7b8:3a7:0:4553:f20a:f619:870a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 6796E3C; Thu, 21 Feb 2008 18:55:37 +0100 (CET) Message-ID: <47BDBB1A.9040701@andric.com> Date: Thu, 21 Feb 2008 18:55:38 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.13pre (Windows/20080218) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> In-Reply-To: <20080221050635.GC26427@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 21 Feb 2008 17:55:38 -0000 On 2008-02-21 06:06, Pyun YongHyeon wrote: > > > Would you try re(4) in HEAD? > > OK, I'll do that. What is the best way to do that? csupping to "." seems a > > bit drastic, and I don't do much with cvs proper. I take it that I should use > > anon-cvs to grab the directory, but I don't quite know how. > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > HEAD/RELENG_7 to if_re.c). That would make it build on your box. I've applied this on a RELENG_7_0 box with 2 re interfaces, and it seems to run without any problems. Not that it had many problems before, except sometimes it took a very long time (e.g. ~10 s) for the re's to come up during booting. Let me know if anyone wants this as a ready-made patch file. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 18:06:37 2008 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 4DCA516A4D2 for ; Thu, 21 Feb 2008 18:06:37 +0000 (UTC) (envelope-from svein-listmail@d80.iso100.no) Received: from d80.iso100.no (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0670713C469 for ; Thu, 21 Feb 2008 18:06:36 +0000 (UTC) (envelope-from svein-listmail@d80.iso100.no) Received: from localhost (unknown [127.0.0.1]) by d80.iso100.no (Familien Skogens mail) with ESMTP id E53244504F; Thu, 21 Feb 2008 18:47:29 +0100 (CET) X-Virus-Scanned: amavisd-new at d80.iso100.no Received: from d80.iso100.no ([127.0.0.1]) by localhost (d80.iso100.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcEFTYRDtnBy; Thu, 21 Feb 2008 18:47:25 +0100 (CET) Received: from [192.168.4.17] (unknown [192.168.4.17]) (Authenticated sender: svein) by d80.iso100.no (Familien Skogens mail) with ESMTP id 69FDF4503F; Thu, 21 Feb 2008 18:47:25 +0100 (CET) Message-ID: <47BDB92C.9050808@d80.iso100.no> Date: Thu, 21 Feb 2008 18:47:24 +0100 From: Svein Skogen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mikael Ikivesi References: <20080219104532.0dc2b565@chaos.nox> In-Reply-To: <20080219104532.0dc2b565@chaos.nox> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 2 core dumps 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, 21 Feb 2008 18:06:37 -0000 Mikael Ikivesi wrote: > Hi > > with RELENG_7 (4-7 days old) I have come across with 2 > panic/reboot. > > The first hapened while machine was compiling ports. When I came back > the machine had rebooted and coredumped. > *snip!* Could you add the following extra info (in case this is more than an isolated hardware failure): Your /var/run/dmesg.boot Laptop make & model, and (if any) docking station used. Reason I'm asking for docking station, is that a few years ago, I had similar dumps (waaaay back when 5 was current), that actually got nailed down to a dirty docking-station connector. Go figure. Knowing what hardware is involved can help other FreeBSD users test if this problem is repeatable. Regards, Svein Skogen From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 18:14:29 2008 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 A198616A410; Thu, 21 Feb 2008 18:14:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 17C4913C4F4; Thu, 21 Feb 2008 18:14:28 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LIEQSs027987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 05:14:27 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1LIEQ2f021716; Fri, 22 Feb 2008 05:14:26 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1LIEQ15021715; Fri, 22 Feb 2008 05:14:26 +1100 (EST) (envelope-from peter) Date: Fri, 22 Feb 2008 05:14:26 +1100 From: Peter Jeremy To: Ruslan Ermilov Message-ID: <20080221181426.GM51095@server.vk2pj.dyndns.org> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221151627.GA21518@team.vega.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DesjdUuHQDwS2t4N" Content-Disposition: inline In-Reply-To: <20080221151627.GA21518@team.vega.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 21 Feb 2008 18:14:29 -0000 --DesjdUuHQDwS2t4N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2008 at 06:16:27PM +0300, Ruslan Ermilov wrote: >With this change, we also bump the minimum requirement for source >upgrades from 6.0-RELEASE to "7.0-CURRENT at some point" because >new ar(1) requires libelf which is not available in previous >releases of FreeBSD. Can't libelf be added to the bootstrap toolchain if it doesn't already exis= t? --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --DesjdUuHQDwS2t4N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvb+C/opHv/APuIcRAgsEAJ9XGuGBziaiNy0q2Wkg7oE1aTMLnACdE9Xx A9dh8KmoN4e5jH2BDrZ5B8A= =OxcR -----END PGP SIGNATURE----- --DesjdUuHQDwS2t4N-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 18:53:21 2008 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 3F8C916A400 for ; Thu, 21 Feb 2008 18:53:21 +0000 (UTC) (envelope-from kerneljake@hotmail.com) Received: from bay0-omc1-s21.bay0.hotmail.com (bay0-omc1-s21.bay0.hotmail.com [65.54.246.93]) by mx1.freebsd.org (Postfix) with ESMTP id 282DC13C45E for ; Thu, 21 Feb 2008 18:53:21 +0000 (UTC) (envelope-from kerneljake@hotmail.com) Received: from BAY136-W29 ([65.55.141.64]) by bay0-omc1-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 10:53:20 -0800 Message-ID: X-Originating-IP: [71.42.72.221] From: Kernel Jake To: Date: Thu, 21 Feb 2008 12:53:20 -0600 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2008 18:53:20.0908 (UTC) FILETIME=[073B1CC0:01C874BB] Subject: RE: 7.0-RC2 amd64 SMP Unsupported relocation type at boot 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, 21 Feb 2008 18:53:21 -0000 It seems I am suffering from the same affliction as other H8SSL-i HT1000 us= ers with SATA drives. I do not have problems with PATA drives on 7.0-RC2, = nor have I seen this problem on 6.2-RELEASE with SATA. My workaround is to= use PATA with this motherboard. bad experiences: http://lists.freebsd.org/pipermail/freebsd-current/2007-December/080928.htm= l proposed patch: http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081094.htm= l _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= 08= From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 19:02:41 2008 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 4EE2816A404 for ; Thu, 21 Feb 2008 19:02:41 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 0413913C4EB for ; Thu, 21 Feb 2008 19:02:40 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so227776pyb.10 for ; Thu, 21 Feb 2008 11:02:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=P6dxNfOZieSojhIts0RFSxFcIhCbb6p+KQGPrVzW19I=; b=REZatpiY3BQ2kwvuo0UnDn2y2li7NIIpH5v5qBlT7/k57dupkyuSub4fg06rCgCZIM9Xk2IcFeJPbSNLFZpTizmsgUeLpWspxP4nRxeV5g+cCt+5KS1v58ykNZvj0JXC1BIhkes3iSq9l2TsIQ9BjQgXLxy7YmtCbq3DJ2fLYQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=p5XJOo/d1zD7e6BpLnNssB3COtUrVTIJwN/0h123h8kE+pKkECBKNw6NW6gQXhH+H5KhFGADLGnfwRnBQF3J5Vf6Sbh4Gf+ZqeAsIwCVN7IHXJUiyGY1p7rb1U/nrb6J+GzkTJzmx5Jp4MSZZxz6+0nhbtdm2Mcd5+6QBLopGXk= Received: by 10.65.182.11 with SMTP id j11mr14748852qbp.50.1203618934302; Thu, 21 Feb 2008 10:35:34 -0800 (PST) Received: by 10.64.195.8 with HTTP; Thu, 21 Feb 2008 10:35:34 -0800 (PST) Message-ID: <5f67a8c40802211035n3b6db2fcvd4309ebd1222cb69@mail.gmail.com> Date: Thu, 21 Feb 2008 18:35:34 +0000 From: "Zaphod Beeblebrox" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 100% of one CPU for nvidia 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, 21 Feb 2008 19:02:41 -0000 Has anyone noticed the latest nvidia binary driver driving their interrupt load up? I have: nvidia0: port 0xef00-0xef7f mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 16 at device 0.0 on pci3 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] nvidia1: port 0xdf00-0xdf7f mem 0xf7000000-0xf7ffffff,0xe0000000-0xefffffff,0xf8000000-0xf9ffffff irq 17 at device 0.0 on pci4 nvidia1: [GIANT-LOCKED] nvidia1: [ITHREAD] and nvidia-driver-169.07 NVidia graphics card binary drivers for hardware OpenGL ren FreeBSD canoe 7.0-RC3 FreeBSD 7.0-RC3 #0: Wed Feb 20 15:19:37 EST 2008 root@canoe.dclg.ca:/usr/obj/d/64/usr/src/sys/CANOE32 i386 (and 7.3_1 of xorg) and my top shows the following whenever X is active (note the 43.2%interrupt): last pid: 9412; load averages: 1.14, 0.89, 1.84 up 0+13:35:32 13:33:15 145 processes: 1 running, 133 sleeping, 11 stopped CPU states: 0.2% user, 0.2% nice, 1.7% system, 43.2% interrupt, 54.7%idle Mem: 648M Active, 2018M Inact, 309M Wired, 31M Cache, 112M Buf, 181M Free Swap: 16G Total, 16G Free My xorg.conf is configured to only use one of the GPU devices. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 19:28:57 2008 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 043D816A402 for ; Thu, 21 Feb 2008 19:28:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 34C8E13C45D; Thu, 21 Feb 2008 19:28:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BDD0F4.8020604@FreeBSD.org> Date: Thu, 21 Feb 2008 20:28:52 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pluknet References: <47BD59D9.9010308@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: panic: mutex Giant owned at nfs_syscalls.c:556 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, 21 Feb 2008 19:28:57 -0000 pluknet wrote: > On 21/02/2008, Kris Kennaway wrote: >> pluknet wrote: >> > I got this assertion while attempting to remove file on nfs mounted >> > ffs filesystem. >> > NFS client on 7.0-PRERELEASE and NFS server on 8-CURRENT. >> > >> > FreeBSD 7.0-PRERELEASE #1: Wed Feb 6 18:09:18 MSK 2008 >> > FreeBSD 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008 >> > >> > Unread portion of the kernel message buffer: >> > panic: mutex Giant owned at >> > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 >> > KDB: enter: panic >> > exclusive sleep mutex nfsd_mtx r = 0 (0xc41d1660) locked @ >> > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501 >> > exclusive sleep mutex Giant r = 0 (0xc07e6410) locked @ >> > /usr/src/sys/kern/vfs_lookup.c:663 >> > ... >> > #9 0xc053959d in panic (fmt=0xc076181d "mutex %s owned at %s:%d") >> > at /usr/src/sys/kern/kern_shutdown.c:555 >> > #10 0xc052adf7 in _mtx_assert (m=0xc07e6410, what=0, >> > file=0xc41cb7b2 >> > "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c", >> > line=556) at /usr/src/sys/kern/kern_mutex.c:652 >> > #11 0xc41c9e82 in nfssvc (td=0xc2e68000, uap=0xd600dcfc) >> > at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 >> > #12 0xc0727903 in syscall (frame=0xd600dd38) >> > at /usr/src/sys/i386/i386/trap.c:1034 >> > #13 0xc0711630 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203 >> > ---Type to continue, or q to quit--- >> > #14 0x00000033 in ?? () >> > >> > Looks somewhat strange because nfs_syscalls.c:556 is not in nfssvc(), >> > it's in nfssvc_nfsd(). >> > Kernel and world synchronized on 8-CUR though. >> > >> >> >> This has been reported a couple of times before but you are the first to >> provide the WITNESS data, which was necessary to proceed. Thanks :) >> >> So there are two questions: >> >> 1) Why is Giant being acquired at all? vfs_lookup.c:663 is a >> VFS_LOCK_GIANT indicating that you are doing a lookup on a non-mpsafe >> filesystem. What filesystems are being exported by the server? >> Previously people claimed not to be exporting any filesystems that >> should be marked !mpsafe, which was a puzzle. >> > > I'm sorry for confusing you. :/ Actually 1 msdosfs filesystem is being exported. > BTW panic occurred on UP kernel. > >> 2) Missed VFS_UNLOCK_GIANT somewhere, or broken assert. The above trace >> should be enough to diagnose though. >> > > I will try to reproduce and investigate this (in a week). Thanks, it makes sense that it should be acquiring Giant then. /* * Whatever happened to the SoC project that was supposed to work on * making msdosfs mpsafe? */ Hopefully it should be a straightforward fix to track down which code path is missing the VFS_UNLOCK_GIANT() to reach the above stack trace, or to reproduce. Kris From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 20:18:36 2008 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 E29C916A404; Thu, 21 Feb 2008 20:18:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 45AC313C474; Thu, 21 Feb 2008 20:18:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LERYCE024929; Fri, 22 Feb 2008 01:27:34 +1100 Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LERONJ022421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:27:25 +1100 Date: Fri, 22 Feb 2008 01:27:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <47BD6F39.7080105@icyb.net.ua> Message-ID: <20080222005213.W5655@besplex.bde.org> References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 21 Feb 2008 20:21:57 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) 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, 21 Feb 2008 20:18:37 -0000 On Thu, 21 Feb 2008, Andriy Gapon wrote: > on 17/02/2008 13:39 Andriy Gapon said the following: >> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >> [ufs/ffs] newfs can do it. >> But with newfs_msdos I had to run disklabel first and then I could >> create a filesystem on cdXa, but I couldn't do it on the whole disk. > > It seems that the reason for this newfs_msdos behavior is in the > following lines: > if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) > errx(1, "Cannot get sector size, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) > errx(1, "Cannot get number of sectors, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) > errx(1, "Cannot get number of heads, %s", strerror(errno)); > > While a failure to get sector size is a serious situation indeed, number > of sectors per track and number of heads are just relics of the past and > are not applicable to all types of should-be-supported media. > What's even more funny is that those values can be set via command line > options and in that case values from ioctl are not used at all. Also, it needs the BIOS geometry, but has been broken to ask for, and normally use, the firmware geometry. Setting the values on the command line is a fairly easy workaround. It's actually better for the ioctls and make you give the correct parameters on the command line instead of succeeding and giving wrong values. The "hidden sectors" calculation has also been broken. This can be fixed by setting the value on the command line too. The correct setting is normally or always the offset of the partition in sectors. > Because those numbers are used by msdosfs on-disk structures we have to > provide some reasonable values for them even if they are meaningless > with respect to physical media organization. > An example of simple calculations can be found in bsdlabel.c. Those don't give the BIOS geometry, which isn't a problem in disklabel since disklabel doesn't need any geometry, but newfs_msdos, fsck_msdosfs fdisk and sysinstall need more. newfs_msdos, fdisk and sysinstall used to read values from the label (including the label for the whole disk), and these parameters used to be set to the kernel's best guess at the BIOS geometry, so that everything saw a consistent geometry. fsck_msdosfs has never missed not being able to determine the correct values, since it has never checked or fixed the values. WinXP silently fixes at least "hidden sectors" at boot time. > I see two approaches: > 1) fake those properties in device drivers, primarily cd(4) and acd(4); > benefit: this can help other utilities besides newfs_msdos > 2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; > > Or maybe do both. This won't help for other utilities that need the BIOS geometry. I use the following fixes in newfs_msdos. They reduce mainly to complaints about the breakage and trying alternative ioctls so that the same binary has some chance of working on new and old versions of FreeBSD. I didn't restore the DIOCGSLICEINFO ioctl or the code that uses it to determine "hidden sectors". Another possible fix for this is to use the NetBSD version, which last time I looked was just the FreeBSD version with all the unportable ioctls and code ifdefed out. The 2004/09/24 version of it reduces to assuming that the correct (BIOS) values are in the label. It attempts to calculate "hidden sectors" where FreeBSD now sets it to 0. I think this works iff the offsets in the label are absolute. FreeBSD used to virtualize these offsets to well to be 0-based, and I think these offsets can be physically 0-based now. It is necessary to know the base, which my unimplemented DICOMEDIAOFFSET ioctl returns. % Index: newfs_msdos.c % =================================================================== % RCS file: /home/ncvs/src/sbin/newfs_msdos/newfs_msdos.c,v % retrieving revision 1.20 % diff -u -2 -r1.20 newfs_msdos.c % --- newfs_msdos.c 17 Feb 2004 02:02:18 -0000 1.20 % +++ newfs_msdos.c 22 Apr 2004 10:36:28 -0000 % @@ -711,56 +711,165 @@ % struct bpb *bpb) % { % - struct disklabel *lp, dlp; % - struct fd_type type; % - off_t ms, hs; % - % - lp = NULL; % - % - /* If the user specified a disk type, try to use that */ % + struct fd_type fdtype; % + struct disklabel label, *lp; % + off_t ms, mo; % + u_int heads, secpertrack, secsize; % + u_int cruftmap, fwheads, fwsectors; % + % +#define NO_MEDIASIZE (1 << 0) % +#define NO_MEDIAOFFSET (1 << 1) % +#define NO_SECTORSIZE (1 << 2) % +#define NO_HEADS (1 << 3) % +#define NO_SECPERTRACK (1 << 4) % +#define NO_FWHEADS (1 << 5) % +#define NO_FWSECTORS (1 << 6) % +#define NO_FDTYPE (1 << 7) % +#define NO_LABEL (1 << 8) % + cruftmap = 0; % + % + /* First, try to use only the "right" primitive ioctls. */ % + if (ioctl(fd, DIOCGMEDIASIZE, &ms) == -1) % + cruftmap |= NO_MEDIASIZE; % +#ifdef DIOCGMEDIAOFFSET % + if (ioctl(fd, DIOCGMEDIAOFFSET, &mo) == -1) % +#endif % + cruftmap |= NO_MEDIAOFFSET; % + if (ioctl(fd, DIOCGSECTORSIZE, &secsize) == -1) % + cruftmap |= NO_SECTORSIZE; % +#ifdef DIOCGHEADS % + if (ioctl(fd, DIOCGHEADS, &nheads)== -1) % +#endif % + cruftmap |= NO_HEADS; % +#ifdef DIOCGSECPERTRACK % + if (ioctl(fd, DIOCGSECPERTRACK, &secpertrack) == -1) % +#endif % + cruftmap |= NO_SECPERTRACK; % + % + /* Prepare fallbacks. */ % + if (ioctl(fd, DIOCGFWHEADS, &fwheads) == -1) % + cruftmap |= NO_FWHEADS; % + if (ioctl(fd, DIOCGFWSECTORS, &fwsectors) == -1) % + cruftmap |= NO_FWSECTORS; % + if (ioctl(fd, FD_GTYPE, &fdtype) == -1) % + cruftmap |= NO_FDTYPE; % if (dtype != NULL) { % lp = getdiskbyname(dtype); % - hs = 0; % + if (lp == NULL) % + errx(1, "%s: unknown disk type", dtype); % + label = *lp; % + } else if (ioctl(fd, DIOCGDINFO, &label) == -1) % + cruftmap |= NO_LABEL; % + % + /* % + * Preliminary fallback for firmware heads and sectors: use floppy ones. % + * Non-GEOM drivers don't have DIOCGFWHEADS or DIOCGFWSECTORS, and % + * we know how to recover for the fd driver only. We could get the % + * media size and sector size from fdtype too, but shouldn't need them. % + */ % + if ((cruftmap & (NO_FWHEADS | NO_FDTYPE)) == NO_FWHEADS) { % + fwheads = fdtype.heads; % + cruftmap &= ~NO_FWHEADS; % } % - % - /* Maybe it's a floppy drive */ % - if (lp == NULL) { % - if (ioctl(fd, DIOCGMEDIASIZE, &ms) == -1) % - errx(1, "Cannot get disk size, %s", strerror(errno)); % - if (ioctl(fd, FD_GTYPE, &type) != -1) { % - dlp.d_secsize = 128 << type.secsize; % - dlp.d_nsectors = type.sectrac; % - dlp.d_ntracks = type.heads; % - dlp.d_secperunit = ms / dlp.d_secsize; % - lp = &dlp; % - hs = 0; % - } % + if ((cruftmap & (NO_FWSECTORS | NO_FDTYPE)) == NO_FWSECTORS) { % + fwsectors = fdtype.sectrac; % + cruftmap &= ~NO_FWSECTORS; % } % % - /* Maybe it's a fixed drive */ % - if (lp == NULL) { % - if (ioctl(fd, DIOCGDINFO, &dlp) == -1) { % - if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) % - errx(1, "Cannot get sector size, %s", strerror(errno)); % - if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) % - errx(1, "Cannot get number of sectors, %s", strerror(errno)); % - if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) % - errx(1, "Cannot get number of heads, %s", strerror(errno)); % - dlp.d_secperunit = ms / dlp.d_secsize; % + /* Prefer to fall back to label info. */ % + if ((cruftmap & (NO_MEDIASIZE | NO_LABEL)) == NO_MEDIASIZE) { % + /* This shouldn't be needed. */ % + ms = label.d_secperunit * (off_t)label.d_secsize; % + cruftmap &= ~NO_MEDIASIZE; % + } % + if (cruftmap & NO_MEDIAOFFSET) { % +#ifdef NO_GEOM_LOSSAGE % + if (!(cruftmap | NO_LABEL)) { % + /* % + * XXX: lost non-GEOM code that handled this. The label info or % + * currently implemented primitive ioctls suffice for most file % + * systems, but msdosfs wants the absolute disk offset for one % + * thing (the number of hidden sectors). We can still use the old % + * code plus yet more compatibility cruft. In the GEOM case, GEOM % + * sysctl output must be parsed as in libdisk, or perhaps libdisk % + * can be used. libdisk takes a measly 300-400 lines and doesn't % + * seem to support more than the 2 layers (slice/partition) needed % + * for i386's, and demonstrates that xml is too hard to use by not % + * using it. % + * % + * Strangely, GEOM's breakage of compatibility for labels makes it % + * easy to determine the absolute disk offset here in some cases: % + * GEOM returns raw disk offsets in label.d_partitions[part].p_offset; % + * these already include the slice offset if the label is backwards % + * compatible, and we can determine if it is backwards compatible % + * by looking at the offset of the raw partition (until GEOM breaks % + * compatibility of that too). We would still need messy parsing % + * of the disk name to determine its partition number, if any. % + */ % + mo = ds.dss_slices[slice].ds_offset * (off_t)label.d_secsize; % + mo += label.d_partitions[part].p_offset * (off_t)label.d_secsize; % + cruftmap &= ~NO_MEDIAOFFSET; % } % +#else % + mo = 0; % + cruftmap &= ~NO_MEDIAOFFSET; % +#endif % + } % + if ((cruftmap & (NO_SECTORSIZE | NO_LABEL)) == NO_SECTORSIZE) { % + /* This shouldn't be needed. */ % + secsize = label.d_secsize; % + cruftmap &= ~NO_SECTORSIZE; % + } % + if ((cruftmap & (NO_HEADS | NO_LABEL)) == NO_HEADS) { % + heads = label.d_ntracks; % + cruftmap &= ~NO_HEADS; % + } % + if ((cruftmap & (NO_SECPERTRACK | NO_LABEL)) == NO_SECPERTRACK) { % + secpertrack = label.d_nsectors; % + cruftmap &= ~NO_SECPERTRACK; % + } % % - hs = (ms / dlp.d_secsize) - dlp.d_secperunit; % - lp = &dlp; % + /* % + * Fall back to "firmware" heads and sectors. % + * % + * XXX: this is quite broken, since we want the BIOS numbers, not the % + * firmware ones. GEOM has broken support for determining the BIOS % + * numbers in fdisk(8) and sysinstall(8) even more by changing things % + * to supply and use only the firmware numbers. Here we have a % + * preferred fallback to the numbers in the label, which can at least % + * be edited to give the BIOS numbers if they don't have them already. % + * Old labels defaulted to having BIOS numbers if possible, but GEOM % + * has got at new labels. % + */ % + if ((cruftmap & (NO_HEADS | NO_FWHEADS)) == NO_HEADS) { % + heads = fwheads; % + cruftmap &= ~NO_HEADS; % } % + if ((cruftmap & (NO_SECPERTRACK | NO_FWSECTORS)) == NO_SECPERTRACK) { % + secpertrack = fwsectors; % + cruftmap &= ~NO_SECPERTRACK; % + } % + % + /* % + * XXX this is too strict. We don't necessarily need the full disk % + * type, since we may have specified parts of it on the command line. % + * % + * Also, we don't support specifying the disk type in the normal way % + * (-T option in newfs). % + */ % + if ((cruftmap & (NO_MEDIASIZE | NO_MEDIAOFFSET | NO_SECTORSIZE | % + NO_HEADS | NO_SECPERTRACK)) != 0) % + warnx("%s: can't determine disk info; disk type must be specified", % + fname); % % if (bpb->bps == 0) % - bpb->bps = ckgeom(fname, lp->d_secsize, "bytes/sector"); % + bpb->bps = ckgeom(fname, secsize, "bytes/sector"); % if (bpb->spt == 0) % - bpb->spt = ckgeom(fname, lp->d_nsectors, "sectors/track"); % + bpb->spt = ckgeom(fname, secpertrack, "sectors/track"); % if (bpb->hds == 0) % - bpb->hds = ckgeom(fname, lp->d_ntracks, "drive heads"); % + bpb->hds = ckgeom(fname, heads, "drive heads"); % if (bpb->bsec == 0) % - bpb->bsec = lp->d_secperunit; % + bpb->bsec = ms / secsize; % if (bpb->hid == 0) % - bpb->hid = hs; % + bpb->hid = mo / secsize; % } % % @@ -802,5 +911,5 @@ % errx(1, "%s: no default %s", fname, msg); % if (val > MAXU16) % - errx(1, "%s: illegal %s %d", fname, msg, val); % + errx(1, "%s: illegal %s value %u", fname, msg, val); % return val; % } Bruce From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 20:53:56 2008 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 5F67816A400; Thu, 21 Feb 2008 20:53:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id C70D713C46E; Thu, 21 Feb 2008 20:53:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7F1C4744007; Thu, 21 Feb 2008 22:53:54 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id INKj9A8S7SWX; Thu, 21 Feb 2008 22:53:54 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 1FA35744006; Thu, 21 Feb 2008 22:53:52 +0200 (EET) Message-ID: <47BDE4D7.9000007@icyb.net.ua> Date: Thu, 21 Feb 2008 22:53:43 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> In-Reply-To: <47BD6F39.7080105@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------070705030706070407090301" Cc: Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) 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, 21 Feb 2008 20:53:56 -0000 This is a multi-part message in MIME format. --------------070705030706070407090301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Please found attached a patch to newfs_msdos that allows it to work on media for which CHS parameters do not make sense (e.g. DVD-RAM disks). First, newfs_msdos would not try to query parameters for which a user has provided override values via command line options. Second, newfs_msdos would fake values for CHS parameters like "sectors per track", "number of heads" which are not supported by the media and for which the user has not provided any values. These numbers/logic are borrowed from bsdlabel.c P.S. a line in the patch marked with XXX is a legacy of current code, not a new addition. P.S. this is not as extensive patch as that by Bruce Evans; its only merit is much smaller changeset versus current code/behavior. on 21/02/2008 14:31 Andriy Gapon said the following: > on 17/02/2008 13:39 Andriy Gapon said the following: >> Should newfs_msdos be able to work on "whole" cdX/acdX device ? >> [ufs/ffs] newfs can do it. >> But with newfs_msdos I had to run disklabel first and then I could >> create a filesystem on cdXa, but I couldn't do it on the whole disk. > > It seems that the reason for this newfs_msdos behavior is in the > following lines: > if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) > errx(1, "Cannot get sector size, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) > errx(1, "Cannot get number of sectors, %s", strerror(errno)); > if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) > errx(1, "Cannot get number of heads, %s", strerror(errno)); > > While a failure to get sector size is a serious situation indeed, number > of sectors per track and number of heads are just relics of the past and > are not applicable to all types of should-be-supported media. > What's even more funny is that those values can be set via command line > options and in that case values from ioctl are not used at all. > > Because those numbers are used by msdosfs on-disk structures we have to > provide some reasonable values for them even if they are meaningless > with respect to physical media organization. > An example of simple calculations can be found in bsdlabel.c. > I see two approaches: > 1) fake those properties in device drivers, primarily cd(4) and acd(4); > benefit: this can help other utilities besides newfs_msdos > 2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; > > Or maybe do both. > -- Andriy Gapon --------------070705030706070407090301 Content-Type: text/x-patch; name="newfs-chs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="newfs-chs.patch" --- newfs_msdos.c.orig 2008-02-21 21:35:00.000000000 +0200 +++ newfs_msdos.c 2008-02-21 21:56:13.000000000 +0200 @@ -739,13 +739,25 @@ /* Maybe it's a fixed drive */ if (lp == NULL) { if (ioctl(fd, DIOCGDINFO, &dlp) == -1) { - if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) + if (bpb->bps == 0 && ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) errx(1, "Cannot get sector size, %s", strerror(errno)); - if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) - errx(1, "Cannot get number of sectors, %s", strerror(errno)); - if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) - errx(1, "Cannot get number of heads, %s", strerror(errno)); + + /* XXX Should we use bpb->bps if it's set? */ dlp.d_secperunit = ms / dlp.d_secsize; + + if (bpb->spt == 0 && ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) { + warnx("Cannot get number of sectors per track, %s", strerror(errno)); + dlp.d_nsectors = 63; + } + if (bpb->hds == 0 && ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks) == -1) { + warnx("Cannot get number of heads, %s", strerror(errno)); + if (dlp.d_secperunit <= 63*1*1024) + dlp.d_ntracks = 1; + else if (dlp.d_secperunit <= 63*16*1024) + dlp.d_ntracks = 16; + else + dlp.d_ntracks = 255; + } } hs = (ms / dlp.d_secsize) - dlp.d_secperunit; --------------070705030706070407090301-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 21:37:15 2008 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 D80E516A40B for ; Thu, 21 Feb 2008 21:37:15 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 72E0013C442 for ; Thu, 21 Feb 2008 21:37:15 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id D3ED824D29; Thu, 21 Feb 2008 23:09:33 +0200 (SAST) Date: Thu, 21 Feb 2008 23:09:33 +0200 From: Aragon Gouveia To: freebsd-current@freebsd.org Message-ID: <20080221210933.GA8910@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Subject: ath problems/questions 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, 21 Feb 2008 21:37:15 -0000 Hi, First, forgive me if I'm posting to the incorrect list.... I have recently started playing with ath under FreeBSD 7.0-BETA2. I'm using a Ubiquiti SRX ExpressCard. The main problem I'm having is that during scans, channels will suddenly fail to reset and the only way to recover is to reboot or kldunload if_ath, unplug, replug, and kldload if_ath. Here's a snippet of the error messages: Feb 21 22:43:31 fuzz kernel: ath0: ath_chan_set: unable to reset channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) Feb 21 22:43:32 fuzz kernel: ath0: ath_chan_set: unable to reset channel 44 (5220 Mhz, flags 0x140 hal flags 0x140) Feb 21 22:43:33 fuzz kernel: ath0: ath_chan_set: unable to reset channel 48 (5240 Mhz, flags 0x140 hal flags 0x140) Feb 21 22:43:33 fuzz kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0) Feb 21 22:43:34 fuzz kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0) Feb 21 22:43:35 fuzz kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0) If I set the interface down and back up without any reloading of modules or replugging of the card, I get the following error: Feb 21 22:45:45 fuzz kernel: ath0: unable to reset hardware; hal status 3227908992 I am not able to reproduce this reliably, however, setting chanlist to 1-48 (or less) seems to stop it from happening. Scanning above channel 48 and the errors start again (sometimes). Any ideas? The other problem I'm having is that scanning behaves differently depending on when wlan_scan_sta.ko is loaded. If I load it before setting the interface up, when I set the interface up it begins scanning continuously by itself. While it's doing this issuing an "ifconfig ath0 scan" doesn't do anything. However, doing a list scan seems to work and continously gets updated. If I load wlan_scan_sta.ko after setting the interface up, no auto scanning occurs. If I run "ifconfig ath0 scan" it scans, returns the results, and stops scanning. I have tried with and without bgscan enabled - no difference. Is there any way of controlling this behaviour? Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 21:41:09 2008 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 9AE8616A413 for ; Thu, 21 Feb 2008 21:41:09 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 000B413C4D9 for ; Thu, 21 Feb 2008 21:41:08 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id 15E5F289EB9; Thu, 21 Feb 2008 22:41:04 +0100 (CET) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id m1LLdkWu097829; Thu, 21 Feb 2008 22:39:46 +0100 (CET) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id m1LLdjgf097828; Thu, 21 Feb 2008 22:39:45 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Thu, 21 Feb 2008 22:39:45 +0100 To: John Marino Message-ID: <20080221213945.GA97273@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217231126.GA68779@saturn.kn-bremen.de> <51702.82.234.78.29.1203318499.squirrel@secure.synsport.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51702.82.234.78.29.1203318499.squirrel@secure.synsport.net> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Thu, 21 Feb 2008 21:44:02 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 21 Feb 2008 21:41:09 -0000 On Mon, Feb 18, 2008 at 01:08:19AM -0600, John Marino wrote: > Hello Juergen, > I compiled a new debug kernel with PRINTF_BUFR_SIZE=128 option. After > that, KQuemu locked up in the same exact place but Freebsd would not dump > it's core. I had been using KQemu with the XFCE desktop. Finally I > started invoking it from the commandline. The emulator's display was > garbled. The first time it panicked, it looked like I had an interactive > debugger, but it was logged on. The core did not dump. I repeated this > again and finally FreeBSD dumped core, but it seems like it's a different > issue than before. Hopefully this will enlighten you... > > John > > > draco-root# kgdb kernel.debug /usr/local/crash/vmcore.2 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > kernel tkernel trap 12 with interrupts disabled > kernel trap 12 with interrupts disabled > Fatal trap 12: page fault while in kernel mode > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff804b2e50 > stack pointer = 0x10:0xffffffffab9d6190 > frame pointer = 0x10:0xffffffffab9d61b0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 1588 (qemu-system-x86_64) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x17a > trap_fatal() at trap_fatal+0x29f > trap() at trap+0x242 > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffffff804b2e50, rsp = 0xffffffffab9d6190, rbp = > 0xffffffffab9d61b0 --- > putcons() at putcons+0x50 > putchar() at putchar+0x6b > kvprintf() at kvprintf+0x72 > printf() at printf+0xcc > uart_z8530_class() at 0x1 > uart_z8530_class() at 0x1 > uart_z8530_class() at 0x1 > Uptime: 6h2m48s > Dumping 1983 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 1983MB (507568 pages) 1967 1951 1935 1919 1903 1887 1871 1855 > 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 > 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 > 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 > 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 > 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 > 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 > 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 > 47 31 15 > > #0 doadump () at pcpu.h:194 > 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0xffffffff80486dd8 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xffffffff80487237 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xffffffff8074860f in trap_fatal (frame=0xc, eva=Variable "eva" is not > available. > ) at /usr/src/sys/amd64/amd64/trap.c:724 > #4 0xffffffff80749302 in trap (frame=0xffffffffab9d60e0) at > /usr/src/sys/amd64/amd64/trap.c:251 > #5 0xffffffff8072e69e in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:169 > #6 0xffffffff804b2e50 in putcons (c=Variable "c" is not available. > ) at /usr/src/sys/kern/subr_prf.c:389 > #7 0xffffffff804b302b in putchar (c=10, arg=Variable "arg" is not available. > ) at /usr/src/sys/kern/subr_prf.c:421 > #8 0xffffffff804b1582 in kvprintf (fmt=0xffffffff8083c0b8 "", > func=0xffffffff804b2fc0 , arg=0xffffffffab9d63d0, > radix=10, ap=Variable "ap" is not available. > ) at /usr/src/sys/kern/subr_prf.c:674 > #9 0xffffffff804b2bbc in printf (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/subr_prf.c:314 > #10 0x0000000000000001 in ?? () > #11 0xffffffffab9d66f0 in ?? () > #12 0xffffffff80735ca3 in spinlock_exit () at cpufunc.h:391 > #13 0x0000000000000001 in ?? () > #14 0xffffffffab9d6790 in ?? () > #15 0x0000000080699029 in ?? () > #16 0x00000000ffffff04 in ?? () > #17 0xffffffffab9d6928 in ?? () > #18 0x0000000000000000 in ?? () > #19 0xffffffff80a6f8a0 in thread0 () > #20 0x00000000ab9d6930 in ?? () > #21 0x0000000000000000 in ?? () > #22 0xffffffff00000005 in ?? () > #23 0x0000000000000000 in ?? () > #24 0xffffffffab9d66f0 in ?? () > #25 0x0000000000000080 in ?? () > #26 0xffffffffab9d6720 in ?? () > #27 0x0000000000000050 in ?? () > #28 0x0000003000000020 in ?? () > #29 0xffffffffab9d6890 in ?? () > #30 0xffffffffab9d67c0 in ?? () > #31 0xfffbbfffab9d6970 in ?? () > #32 0x00000000a38d6a20 in ?? () > #33 0x000000000000000c in ?? () > #34 0xffffffff8083bdbf in printinterval.9757 () > #35 0xffffffff80805203 in op_table () > #36 0x0000000000000001 in ?? () > #37 0x000000000000009b in ?? () > #38 0xffffffffab9d6aa0 in ?? () > #39 0x0000000000000001 in ?? () > #40 0xffffff0001554301 in ?? () > #41 0x0000000000000001 in ?? () > #42 0xffffffff00000000 in ?? () > #43 0xffffffff80a6f8a0 in thread0 () > #44 0x000000006e72656b in ?? () > #45 0xfffeffff00000000 in ?? () > #46 0x0800000008808004 in ?? () > #47 0x0000000000000000 in ?? () > #48 0x0000810000000000 in ?? () > #49 0x0400200000000000 in ?? () > #50 0x4000300100002000 in ?? () > ---Type to continue, or q to quit--- > #51 0x0000000020000010 in ?? () > #52 0x0000008000000200 in ?? () > #53 0x0050400140000000 in ?? () > #54 0xffffffff80a6f8a0 in thread0 () > #55 0x0000000000000010 in ?? () > #56 0xffffffffab9d68e0 in ?? () > #57 0xffffffff807483f9 in trap_fatal (frame=0x3a00000039, eva=0) at > /usr/src/sys/amd64/amd64/trap.c:667 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > (kgdb) i li *0xffffffff804b2e50 > Line 390 of "/usr/src/sys/kern/subr_prf.c" starts at address > 0xffffffff804b2e50 > and ends at 0xffffffff804b2e53 . > (kgdb) Another bad crash that doesn't tell me whats wrong... I guess this is a lost cause. Juergen From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:25:58 2008 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 7E91016A400 for ; Thu, 21 Feb 2008 22:25:58 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2B313C4D9 for ; Thu, 21 Feb 2008 22:25:58 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1LMPv0n068005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:25:58 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47BDFA75.2010904@errno.com> Date: Thu, 21 Feb 2008 14:25:57 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Aragon Gouveia References: <20080221210933.GA8910@phat.za.net> In-Reply-To: <20080221210933.GA8910@phat.za.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: ath problems/questions 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, 21 Feb 2008 22:25:58 -0000 Aragon Gouveia wrote: > Hi, > > First, forgive me if I'm posting to the incorrect list.... > > I have recently started playing with ath under FreeBSD 7.0-BETA2. I'm using > a Ubiquiti SRX ExpressCard. > > The main problem I'm having is that during scans, channels will suddenly > fail to reset and the only way to recover is to reboot or kldunload if_ath, > unplug, replug, and kldload if_ath. Here's a snippet of the error messages: > > Feb 21 22:43:31 fuzz kernel: ath0: ath_chan_set: unable to reset channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) > Feb 21 22:43:32 fuzz kernel: ath0: ath_chan_set: unable to reset channel 44 (5220 Mhz, flags 0x140 hal flags 0x140) > Feb 21 22:43:33 fuzz kernel: ath0: ath_chan_set: unable to reset channel 48 (5240 Mhz, flags 0x140 hal flags 0x140) > Feb 21 22:43:33 fuzz kernel: ath0: ath_chan_set: unable to reset channel 2 (2417 Mhz, flags 0x480 hal flags 0xc0) > Feb 21 22:43:34 fuzz kernel: ath0: ath_chan_set: unable to reset channel 3 (2422 Mhz, flags 0x480 hal flags 0xc0) > Feb 21 22:43:35 fuzz kernel: ath0: ath_chan_set: unable to reset channel 4 (2427 Mhz, flags 0x480 hal flags 0xc0) Blech, I keep forgetting to add the hal status code to this printf. We need to identify why the reset failed but it's likely a hardware/expresscard issue and not in the driver. Unfortunately I don't have an SRX card (just about every other Ubiquiti cards--thank you Robert--but not this one). > > If I set the interface down and back up without any reloading of modules or > replugging of the card, I get the following error: > > Feb 21 22:45:45 fuzz kernel: ath0: unable to reset hardware; hal status 3227908992 This is odd, the status code should be in the range 1-15. > > I am not able to reproduce this reliably, however, setting chanlist to 1-48 > (or less) seems to stop it from happening. Scanning above channel 48 and the > errors start again (sometimes). Any ideas? Not really. I don't see a mac+phy for the card or any indication of the hal version you are using and I'm not familiar with the part in this card. > > > The other problem I'm having is that scanning behaves differently depending > on when wlan_scan_sta.ko is loaded. If I load it before setting the > interface up, when I set the interface up it begins scanning continuously > by itself. While it's doing this issuing an "ifconfig ath0 scan" doesn't > do anything. However, doing a list scan seems to work and continously gets > updated. > > If I load wlan_scan_sta.ko after setting the interface up, no auto scanning > occurs. If I run "ifconfig ath0 scan" it scans, returns the results, and > stops scanning. > > I have tried with and without bgscan enabled - no difference. Is there > any way of controlling this behaviour? Assuming all this is using the SRX card I'd forget about trying to understand/resolve 802.11 issues until we understand why you're seeing the above problems. Sam From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:33:40 2008 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 CF14916A403; Thu, 21 Feb 2008 22:33:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA8F13C45E; Thu, 21 Feb 2008 22:33:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2E2FC1710A; Thu, 21 Feb 2008 22:33:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1LDRqGW000890; Thu, 21 Feb 2008 13:27:52 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 21 Feb 2008 14:31:53 +0200." <47BD6F39.7080105@icyb.net.ua> Date: Thu, 21 Feb 2008 13:27:52 +0000 Message-ID: <889.1203600472@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) 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, 21 Feb 2008 22:33:40 -0000 In message <47BD6F39.7080105@icyb.net.ua>, Andriy Gapon writes: >on 17/02/2008 13:39 Andriy Gapon said the following: >I see two approaches: >1) fake those properties in device drivers, primarily cd(4) and acd(4); > benefit: this can help other utilities besides newfs_msdos No. The geom attributes are provided if they are available only. It is the responsibility of the application code to decide and handle their absence. >2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; This is the way to do it, but it might make sense to make a library routine do it, to get consistent behaviour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:39:23 2008 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 D8E5316A408 for ; Thu, 21 Feb 2008 22:39:23 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 77A7E13C4EE for ; Thu, 21 Feb 2008 22:39:23 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id 9548A24D29; Fri, 22 Feb 2008 00:39:21 +0200 (SAST) Date: Fri, 22 Feb 2008 00:39:21 +0200 From: Aragon Gouveia To: freebsd-current@freebsd.org Message-ID: <20080221223921.GA17039@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BDFA75.2010904@errno.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Subject: Re: ath problems/questions 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, 21 Feb 2008 22:39:23 -0000 | By Sam Leffler | [ 2008-02-22 00:26 +0200 ] > Not really. I don't see a mac+phy for the card or any indication of the > hal version you are using and I'm not familiar with the part in this card. Ah, sorry. Here it is. :) Feb 22 00:36:18 fuzz kernel: ath0: mem 0xf2000000-0xf200ffff irq 16 at device 0.0 on pci2 Feb 22 00:36:18 fuzz kernel: ath0: [ITHREAD] Feb 22 00:36:18 fuzz kernel: ath0: using obsoleted if_watchdog interface Feb 22 00:36:18 fuzz kernel: ath0: Ethernet address: Feb 22 00:36:18 fuzz kernel: ath0: mac 10.3 phy 6.1 radio 10.2 and ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 22:52:18 2008 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 5891516A404; Thu, 21 Feb 2008 22:52:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 876BA13C45A; Thu, 21 Feb 2008 22:52:17 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id AB70E28450; Fri, 22 Feb 2008 06:52:16 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 69B3AEC4BC7; Fri, 22 Feb 2008 06:52:16 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id nuJwdOQA5ExF; Fri, 22 Feb 2008 06:52:11 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id B2FF4EC4B6C; Fri, 22 Feb 2008 06:52:09 +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:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=TqTffa9FmLGDR8YZAc/FrSLl7Ff3ThVipBIAL+W5TVbiaLMzFIaZ9BgoGeHJhMZTe alvLo6c1P5GG/ZKr1Ucug== Message-ID: <47BE0096.3010109@delphij.net> Date: Thu, 21 Feb 2008 14:52:06 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> In-Reply-To: <47BBD864.3070905@delphij.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------090507070102080306020007" Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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, 21 Feb 2008 22:52:18 -0000 This is a multi-part message in MIME format. --------------090507070102080306020007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a revised version of patch. It adds a new '-C' flag to fsck_ffs(8), which causes fsck_ffs(8) to run in a new 'catastrophic recovery' mode, where more aggressive operations are done. All cg clearing operations are now hidden in '-C' mode, and a prompt is provided so that sysadmin can choose whether to clear the cg. Other changes: - Be more careful while resetting a cg. Set more fields; - Sanity check d_ino in pass2check(). Give fsck_ffs(8) an opportunity to recover from insane inode number provided by damaged directory entry. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvgCWi+vbBBjt66ARAjrmAKCvDR/4wWiNp/k+9Jhz6YEhp9fFpgCeLyus /1BXVmFBI9S0fBdc3YOXmMw= =sE9G -----END PGP SIGNATURE----- --------------090507070102080306020007 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsck.diff" Index: fsck.h =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v retrieving revision 1.37 diff -u -p -r1.37 fsck.h --- fsck.h 31 Oct 2006 22:06:56 -0000 1.37 +++ fsck.h 21 Feb 2008 22:01:44 -0000 @@ -270,6 +270,7 @@ char yflag; /* assume a yes response * int bkgrdflag; /* use a snapshot to run on an active system */ int bflag; /* location of alternate super block */ int debug; /* output debugging info */ +char catastrophicflag; /* run in catastrophic mode */ int cvtlevel; /* convert to newer file system format */ int bkgrdcheck; /* determine if background check is possible */ int bkgrdsumadj; /* whether the kernel have ability to adjust superblock summary */ @@ -335,6 +336,7 @@ void cacheino(union dinode *dp, ino_t i void catch(int); void catchquit(int); int changeino(ino_t dir, const char *name, ino_t newnum); +void check_cgmagic(int cg, struct cg *cgp); int chkrange(ufs2_daddr_t blk, int cnt); void ckfini(int markclean); int ckinode(union dinode *dp, struct inodesc *); Index: fsck_ffs.8 =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck_ffs.8,v retrieving revision 1.34 diff -u -p -r1.34 fsck_ffs.8 --- fsck_ffs.8 20 Sep 2005 08:02:38 -0000 1.34 +++ fsck_ffs.8 21 Feb 2008 22:26:08 -0000 @@ -38,7 +38,7 @@ .Nd file system consistency check and interactive repair .Sh SYNOPSIS .Nm -.Op Fl BFpfny +.Op Fl BCFpfny .Op Fl b Ar block .Op Fl c Ar level .Op Fl m Ar mode @@ -175,6 +175,26 @@ Use the block specified immediately afte the super block for the file system. An alternate super block is usually located at block 32 for UFS1, and block 160 for UFS2. +.It Fl C +Run +.Nm +in 'catastrophic recovery' mode, which will enable certain aggressive +operations that can make +.Nm +to survive with file systems that has very serious data damage, which +is an useful last resort when on disk data damage is very serious +and causes +.Nm +to crash otherwise. Be +.Em very careful +using this flag, is dangerous if there are data transmission hazards +because a false positive cylinder group magic number mismatch could +cause +.Em irrevertible data loss! +.Pp +This option implies the +.Fl f +flag. .It Fl c Convert the file system to the specified level. Note that the level of a file system can only be raised. Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 21 Feb 2008 22:47:08 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } @@ -418,6 +418,32 @@ blwrite(int fd, char *buf, ufs2_daddr_t } /* + * Check cg's magic number. If catastrophic mode is enabled and the cg's + * magic number is bad, offer an option to clear the whole cg. + */ +void +check_cgmagic(int cg, struct cg *cgp) +{ + + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + if (catastrophicflag) { + if (reply("CLEAR CG")) { + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_initediblk = sblock.fs_ipg; + cgp->cg_old_niblk = sblock.fs_ipg; + cgp->cg_old_ncyl = sblock.fs_old_cpg; + cgp->cg_cgx = cg; + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + } + } else + printf("YOU MAY NEED TO RERUN FSCK WITH -C IF IT CRASHED.\n"); + } +} + +/* * allocate a data block with the specified number of fragments */ ufs2_daddr_t @@ -441,8 +467,7 @@ allocblk(long frags) } cg = dtog(&sblock, i + j); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); baseblk = dtogd(&sblock, i + j); for (k = 0; k < frags; k++) { setbmap(i + j + k); Index: inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.38 diff -u -p -r1.38 inode.c --- inode.c 31 Oct 2006 22:06:56 -0000 1.38 +++ inode.c 21 Feb 2008 21:56:27 -0000 @@ -617,8 +617,7 @@ allocino(ino_t request, int type) return (0); cg = ino_to_cg(&sblock, ino); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); setbit(cg_inosused(cgp), ino % sblock.fs_ipg); cgp->cg_cs.cs_nifree--; switch (type & IFMT) { Index: main.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/main.c,v retrieving revision 1.47 diff -u -p -r1.47 main.c --- main.c 19 Sep 2007 01:24:19 -0000 1.47 +++ main.c 21 Feb 2008 22:02:42 -0000 @@ -81,7 +81,8 @@ main(int argc, char *argv[]) sync(); skipclean = 1; - while ((ch = getopt(argc, argv, "b:Bc:dfFm:npy")) != -1) { + catastrophicflag = 0; + while ((ch = getopt(argc, argv, "b:Bc:CdfFm:npy")) != -1) { switch (ch) { case 'b': skipclean = 0; @@ -105,6 +106,10 @@ main(int argc, char *argv[]) debug++; break; + case 'C': + catastrophicflag = 1; + /* FALLTHROUGH */ + case 'f': skipclean = 0; break; Index: pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.43 diff -u -p -r1.43 pass1.c --- pass1.c 8 Oct 2004 20:44:47 -0000 1.43 +++ pass1.c 20 Feb 2008 07:13:53 -0000 @@ -93,9 +93,11 @@ pass1(void) inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); - if (sblock.fs_magic == FS_UFS2_MAGIC) + if (sblock.fs_magic == FS_UFS2_MAGIC) { inosused = cgrp.cg_initediblk; - else + if (inosused > sblock.fs_ipg) + inosused = sblock.fs_ipg; + } else inosused = sblock.fs_ipg; if (got_siginfo) { printf("%s: phase 1: cyl group %d of %d (%d%%)\n", Index: pass2.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass2.c,v retrieving revision 1.26 diff -u -p -r1.26 pass2.c --- pass2.c 8 Oct 2004 20:44:47 -0000 1.26 +++ pass2.c 21 Feb 2008 22:31:03 -0000 @@ -242,6 +242,8 @@ pass2check(struct inodesc *idesc) /* * check for "." */ + if (dirp->d_ino > maxino) + goto chk2; if (idesc->id_entryno != 0) goto chk1; if (dirp->d_ino != 0 && strcmp(dirp->d_name, ".") == 0) { Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.50 diff -u -p -r1.50 setup.c --- setup.c 31 Oct 2006 22:06:56 -0000 1.50 +++ setup.c 20 Feb 2008 07:13:27 -0000 @@ -349,7 +349,7 @@ readsb(int listerr) sblock.fs_sblockloc == sblock_try[i])) && sblock.fs_ncg >= 1 && sblock.fs_bsize >= MINBSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_sbsize >= roundup(sizeof(struct fs), dev_bsize)) break; } if (sblock_try[i] == -1) { --------------090507070102080306020007-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 23:43:51 2008 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 2809316A402 for ; Thu, 21 Feb 2008 23:43:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63902.mail.re1.yahoo.com (web63902.mail.re1.yahoo.com [69.147.97.117]) by mx1.freebsd.org (Postfix) with SMTP id B23C913C44B for ; Thu, 21 Feb 2008 23:43:50 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 67913 invoked by uid 60001); 21 Feb 2008 23:43:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=333H35AqnMIG0FdMJEaM0cYn22k0xTi6xZGBW3LW7nxz9HsEJ94HkAWcp1y++C5bCB/gKtcLpROoR5Ey+2FscwBSR+IFg2+Lxow9SaG3L2hBWo4txdiE3fUyVp5gnjwuPJauZFT3hnYYCARSOaf5HuKQTIy600jusZwGItNgiKI=; X-YMail-OSG: lZLmO3wVM1kAzfnJTrEls9b3R.b3ETzeABS2EswzxBpEysdBRh4rkAiKOgAaVsyrObf_lyFioUMxUfRz.R3ueWAIWEBkdtYKhaXcdN7vsqOiMzYcrA-- Received: from [98.203.28.38] by web63902.mail.re1.yahoo.com via HTTP; Thu, 21 Feb 2008 15:43:49 PST Date: Thu, 21 Feb 2008 15:43:49 -0800 (PST) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <757984.60415.qm@web63902.mail.re1.yahoo.com> Cc: Subject: Anyone running Harpertown / Blackford on 7.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, 21 Feb 2008 23:43:51 -0000 If anyone is running successfully or having problems with a blackford/Harpertown please let me know. thanks, Barney ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 00:08:09 2008 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 599DB16A405 for ; Fri, 22 Feb 2008 00:08:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0B05213C455 for ; Fri, 22 Feb 2008 00:08:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so221119ele.3 for ; Thu, 21 Feb 2008 16:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:x-mailer; bh=3yrksGuoIX9SLnWMqHCA+OwudBAdxn5xrqRCg+iSO8k=; b=PtASF/FaW8VnYq6m4wYFHGfRAQQRwOJcizFY9r85A0UTMI9DJd5t4oZcVFRnkJXbVpj9OYhDh0P+YIbdpUctUAFJDJWK17GAj+bRWCvtbfGXkPi85ZOJVIBdU2UZsCjcBUJ4XVbeoIcx2ZvrSryOgWQdIZKn/8emS3LKy2PwaYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:x-mailer; b=wrRi+KHF6FbAvZPx2kfv+BGcKw4dIi7sIowkYFMykSe/yManuy7DdNrzT6VgfQis0/Z4moyr5Bhr2ii8xcIY7tMaG1qIJ4iQ3d0Mo2bP9H/Ya29JlLYE2GAWLCxRVj7j9RfpzRKhyeJqotMS4gT00Xaw8K8xGZWSZNI6S1us3pY= Received: by 10.142.115.10 with SMTP id n10mr8200753wfc.95.1203637271307; Thu, 21 Feb 2008 15:41:11 -0800 (PST) Received: from ?10.2.0.49? ( [67.96.45.122]) by mx.google.com with ESMTPS id 24sm1079446wff.10.2008.02.21.15.41.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 15:41:10 -0800 (PST) Message-Id: <511FC3E9-937C-475C-8F1B-39BA5347DBE0@gmail.com> From: Garrett Cooper To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 15:41:39 -0800 X-Mailer: Apple Mail (2.919.2) Cc: Subject: Gathering a list of showstoppers for RELENG_7 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, 22 Feb 2008 00:08:09 -0000 Hi all, As part of the new Cisco FreeBSD ramp-up, I've noted that there's been some concern about showstoppers for RELENG_7 as of late. So, I was just wondering what the current showstoppers are for 7.x and possibly how I can help triage issues in the next couple weeks, etc, to accelerate the release a bit. I may not have access to a PC at all times nor a FreeBSD machine, but I should be able to assign bugs or CC owners, or help debug some more common items. I'll also try getting VMware fusion in the upcoming week to work from my laptop and help out in some way shape or form in person. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 00:26:34 2008 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 E97DB16A59F for ; Fri, 22 Feb 2008 00:26:34 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF1413C43E for ; Fri, 22 Feb 2008 00:26:34 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JSLkG-0000JF-3E for freebsd-current@freebsd.org; Fri, 22 Feb 2008 00:26:32 +0000 Received: from 89-172-51-133.adsl.net.t-com.hr ([89.172.51.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2008 00:26:32 +0000 Received: from ivoras by 89-172-51-133.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2008 00:26:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 22 Feb 2008 01:26:21 +0100 Lines: 28 Message-ID: References: <757984.60415.qm@web63902.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig91809FEDB050E634C590EA1F" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-51-133.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <757984.60415.qm@web63902.mail.re1.yahoo.com> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Anyone running Harpertown / Blackford on 7.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: Fri, 22 Feb 2008 00:26:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91809FEDB050E634C590EA1F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Barney Cordoba wrote: > If anyone is running successfully or having problems > with a blackford/Harpertown please let me know.=20 I don't have it in production (yet), but I've tested it on RELENG_7=20 pretty heavily and it works fine. Very, very fast. --------------enig91809FEDB050E634C590EA1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHvhatldnAQVacBcgRApf9AKDXLP2/YlGdvLIwuxYSZd820IgqwgCgwV0u sXAT09TnFnDDLJUDv2Uu7pk= =NOSl -----END PGP SIGNATURE----- --------------enig91809FEDB050E634C590EA1F-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 01:00:34 2008 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 A77C816A405; Fri, 22 Feb 2008 01:00:34 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD8713C4D9; Fri, 22 Feb 2008 01:00:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 0AE7A2844E; Fri, 22 Feb 2008 09:00:32 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id B2F6AEC47B6; Fri, 22 Feb 2008 09:00:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id O6Ga7sVKDYkP; Fri, 22 Feb 2008 09:00:25 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 5E24CEC4781; Fri, 22 Feb 2008 09:00:24 +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:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=btvnXK0h/u2NC1GrK6ItXnVwEUEdEzeGt1Kb+rZTiRCSFo4xR3HIznxQKlZozv8x2 4m5RQLGnnpUf0t8hwS2OA== Message-ID: <47BE1EA3.7030105@delphij.net> Date: Thu, 21 Feb 2008 17:00:19 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> <47BE0096.3010109@delphij.net> In-Reply-To: <47BE0096.3010109@delphij.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------060303000807050602000802" Cc: freebsd-fs@freebsd.org, FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage 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: Fri, 22 Feb 2008 01:00:34 -0000 This is a multi-part message in MIME format. --------------060303000807050602000802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xin LI wrote: > Here is a revised version of patch. Sorry for replying myself. I found a nit - the clear of cg is beyond the reach of later phases, so set rerun = 1 to advise the user that a rerun of fsck is necessary to make a full recover. No other functional chnages. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvh6ii+vbBBjt66ARApvIAKDCTQ13lZCTnP3mHLrJtIs+dsvF2gCeIy3j lrJcQw30LubvVfiVm8y6cvs= =Wh3/ -----END PGP SIGNATURE----- --------------060303000807050602000802 Content-Type: text/plain; name="fsck.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsck.diff" Index: fsck.h =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v retrieving revision 1.37 diff -u -p -r1.37 fsck.h --- fsck.h 31 Oct 2006 22:06:56 -0000 1.37 +++ fsck.h 21 Feb 2008 22:01:44 -0000 @@ -270,6 +270,7 @@ char yflag; /* assume a yes response * int bkgrdflag; /* use a snapshot to run on an active system */ int bflag; /* location of alternate super block */ int debug; /* output debugging info */ +char catastrophicflag; /* run in catastrophic mode */ int cvtlevel; /* convert to newer file system format */ int bkgrdcheck; /* determine if background check is possible */ int bkgrdsumadj; /* whether the kernel have ability to adjust superblock summary */ @@ -335,6 +336,7 @@ void cacheino(union dinode *dp, ino_t i void catch(int); void catchquit(int); int changeino(ino_t dir, const char *name, ino_t newnum); +void check_cgmagic(int cg, struct cg *cgp); int chkrange(ufs2_daddr_t blk, int cnt); void ckfini(int markclean); int ckinode(union dinode *dp, struct inodesc *); Index: fsck_ffs.8 =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck_ffs.8,v retrieving revision 1.34 diff -u -p -r1.34 fsck_ffs.8 --- fsck_ffs.8 20 Sep 2005 08:02:38 -0000 1.34 +++ fsck_ffs.8 21 Feb 2008 22:26:08 -0000 @@ -38,7 +38,7 @@ .Nd file system consistency check and interactive repair .Sh SYNOPSIS .Nm -.Op Fl BFpfny +.Op Fl BCFpfny .Op Fl b Ar block .Op Fl c Ar level .Op Fl m Ar mode @@ -175,6 +175,26 @@ Use the block specified immediately afte the super block for the file system. An alternate super block is usually located at block 32 for UFS1, and block 160 for UFS2. +.It Fl C +Run +.Nm +in 'catastrophic recovery' mode, which will enable certain aggressive +operations that can make +.Nm +to survive with file systems that has very serious data damage, which +is an useful last resort when on disk data damage is very serious +and causes +.Nm +to crash otherwise. Be +.Em very careful +using this flag, is dangerous if there are data transmission hazards +because a false positive cylinder group magic number mismatch could +cause +.Em irrevertible data loss! +.Pp +This option implies the +.Fl f +flag. .It Fl c Convert the file system to the specified level. Note that the level of a file system can only be raised. Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 22 Feb 2008 00:50:43 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } @@ -418,6 +418,35 @@ blwrite(int fd, char *buf, ufs2_daddr_t } /* + * Check cg's magic number. If catastrophic mode is enabled and the cg's + * magic number is bad, offer an option to clear the whole cg. + */ +void +check_cgmagic(int cg, struct cg *cgp) +{ + + if (!cg_chkmagic(cgp)) { + pwarn("CG %d: BAD MAGIC NUMBER\n", cg); + if (catastrophicflag) { + if (reply("CLEAR CG")) { + memset(cgp, 0, (size_t)sblock.fs_cgsize); + cgp->cg_initediblk = sblock.fs_ipg; + cgp->cg_old_niblk = sblock.fs_ipg; + cgp->cg_old_ncyl = sblock.fs_old_cpg; + cgp->cg_cgx = cg; + cgp->cg_niblk = sblock.fs_ipg; + cgp->cg_ndblk = sblock.fs_size - cgbase(&sblock, cg); + cgp->cg_magic = CG_MAGIC; + cgdirty(); + printf("PLEASE RERUN FSCK.\n"); + rerun = 1; + } + } else + printf("YOU MAY NEED TO RERUN FSCK WITH -C IF IT CRASHED.\n"); + } +} + +/* * allocate a data block with the specified number of fragments */ ufs2_daddr_t @@ -441,8 +470,7 @@ allocblk(long frags) } cg = dtog(&sblock, i + j); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); baseblk = dtogd(&sblock, i + j); for (k = 0; k < frags; k++) { setbmap(i + j + k); Index: inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.38 diff -u -p -r1.38 inode.c --- inode.c 31 Oct 2006 22:06:56 -0000 1.38 +++ inode.c 21 Feb 2008 21:56:27 -0000 @@ -617,8 +617,7 @@ allocino(ino_t request, int type) return (0); cg = ino_to_cg(&sblock, ino); getblk(&cgblk, cgtod(&sblock, cg), sblock.fs_cgsize); - if (!cg_chkmagic(cgp)) - pfatal("CG %d: BAD MAGIC NUMBER\n", cg); + check_cgmagic(cg, cgp); setbit(cg_inosused(cgp), ino % sblock.fs_ipg); cgp->cg_cs.cs_nifree--; switch (type & IFMT) { Index: main.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/main.c,v retrieving revision 1.47 diff -u -p -r1.47 main.c --- main.c 19 Sep 2007 01:24:19 -0000 1.47 +++ main.c 21 Feb 2008 22:02:42 -0000 @@ -81,7 +81,8 @@ main(int argc, char *argv[]) sync(); skipclean = 1; - while ((ch = getopt(argc, argv, "b:Bc:dfFm:npy")) != -1) { + catastrophicflag = 0; + while ((ch = getopt(argc, argv, "b:Bc:CdfFm:npy")) != -1) { switch (ch) { case 'b': skipclean = 0; @@ -105,6 +106,10 @@ main(int argc, char *argv[]) debug++; break; + case 'C': + catastrophicflag = 1; + /* FALLTHROUGH */ + case 'f': skipclean = 0; break; Index: pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.43 diff -u -p -r1.43 pass1.c --- pass1.c 8 Oct 2004 20:44:47 -0000 1.43 +++ pass1.c 20 Feb 2008 07:13:53 -0000 @@ -93,9 +93,11 @@ pass1(void) inumber = c * sblock.fs_ipg; setinodebuf(inumber); getblk(&cgblk, cgtod(&sblock, c), sblock.fs_cgsize); - if (sblock.fs_magic == FS_UFS2_MAGIC) + if (sblock.fs_magic == FS_UFS2_MAGIC) { inosused = cgrp.cg_initediblk; - else + if (inosused > sblock.fs_ipg) + inosused = sblock.fs_ipg; + } else inosused = sblock.fs_ipg; if (got_siginfo) { printf("%s: phase 1: cyl group %d of %d (%d%%)\n", Index: pass2.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass2.c,v retrieving revision 1.26 diff -u -p -r1.26 pass2.c --- pass2.c 8 Oct 2004 20:44:47 -0000 1.26 +++ pass2.c 21 Feb 2008 22:31:03 -0000 @@ -242,6 +242,8 @@ pass2check(struct inodesc *idesc) /* * check for "." */ + if (dirp->d_ino > maxino) + goto chk2; if (idesc->id_entryno != 0) goto chk1; if (dirp->d_ino != 0 && strcmp(dirp->d_name, ".") == 0) { Index: setup.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.50 diff -u -p -r1.50 setup.c --- setup.c 31 Oct 2006 22:06:56 -0000 1.50 +++ setup.c 20 Feb 2008 07:13:27 -0000 @@ -349,7 +349,7 @@ readsb(int listerr) sblock.fs_sblockloc == sblock_try[i])) && sblock.fs_ncg >= 1 && sblock.fs_bsize >= MINBSIZE && - sblock.fs_bsize >= sizeof(struct fs)) + sblock.fs_sbsize >= roundup(sizeof(struct fs), dev_bsize)) break; } if (sblock_try[i] == -1) { --------------060303000807050602000802-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 01:59:21 2008 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 96A5416A405 for ; Fri, 22 Feb 2008 01:59:21 +0000 (UTC) (envelope-from robbak@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2CAC513C4D3 for ; Fri, 22 Feb 2008 01:59:20 +0000 (UTC) (envelope-from robbak@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so223952tid.3 for ; Thu, 21 Feb 2008 17:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=5tb5iujfZO6UqjVMQ8kenlUXWY7ajKm14Ss9jM/QBWM=; b=Mu2FPBL172FX20awK1Ykiu4MzhLxvqG0G9rjptH1D5XYzwPZoFlL5o3j41rjDKgCLRDrXTDGzIEwW7LlMMFAHlKkz3yhkdMyT+nwd6pTgJ7RseULWLi7GZSFoBe9dGJXdearwg5He3fHIyLK2ar7ELQgJiiGeN4bjOjbAQQPaFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=g99uzpcr12khZjV1MXdkUmsmnoN+/ZGkYwWPwsqQD56kzJHNBj/eoEnPb/enBSAwTfE2WfuTAjkScm/6V5w2qy3mDOZ5qEMhi+/CQU0dJcibm+1MMIO/lNYOYAqw9lXq43A6MCgiiv73Rd131sKpuc0f7716j1DzuQRSz9U7IGA= Received: by 10.110.20.17 with SMTP id 17mr7534988tit.47.1203645559455; Thu, 21 Feb 2008 17:59:19 -0800 (PST) Received: by 10.110.26.11 with HTTP; Thu, 21 Feb 2008 17:59:19 -0800 (PST) Message-ID: Date: Fri, 22 Feb 2008 11:59:19 +1000 From: "Robert Backhaus" Sender: robbak@gmail.com To: "Dimitry Andric" In-Reply-To: <47BDBB1A.9040701@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> X-Google-Sender-Auth: 858f4b51e6fbb6c7 Cc: pyunyh@gmail.com, FreeBSD Current Subject: Re: Packet corruption in re0 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, 22 Feb 2008 01:59:21 -0000 On Fri, Feb 22, 2008 at 3:55 AM, Dimitry Andric wrote: > On 2008-02-21 06:06, Pyun YongHyeon wrote: > > > > Would you try re(4) in HEAD? > > > OK, I'll do that. What is the best way to do that? csupping to "." seems a > > > bit drastic, and I don't do much with cvs proper. I take it that I should use > > > anon-cvs to grab the directory, but I don't quite know how. > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > I've applied this on a RELENG_7_0 box with 2 re interfaces, and it > seems to run without any problems. Not that it had many problems > before, except sometimes it took a very long time (e.g. ~10 s) for the > re's to come up during booting. > > Let me know if anyone wants this as a ready-made patch file. > I have had trouble so far. I was tracking RELENG_7, which has the m_defrag() function. - adding it again caused the build to stop, and I munged things when pulling it back out again. I'm csupping again to have another go. Good to see that others are being helped by my question: I really should have asked it weeks ago! From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 02:14:07 2008 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 AB91616A400 for ; Fri, 22 Feb 2008 02:14:07 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3C213C478 for ; Fri, 22 Feb 2008 02:14:07 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4553:f20a:f619:870a] (unknown [IPv6:2001:7b8:3a7:0:4553:f20a:f619:870a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 616203C; Fri, 22 Feb 2008 03:14:06 +0100 (CET) Message-ID: <47BE2FEF.7010709@andric.com> Date: Fri, 22 Feb 2008 03:14:07 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.13pre (Windows/20080218) MIME-Version: 1.0 To: Robert Backhaus References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Current Subject: Re: Packet corruption in re0 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, 22 Feb 2008 02:14:07 -0000 On 2008-02-22 02:59, Robert Backhaus wrote: >> > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. >> > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add >> > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on >> > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > I have had trouble so far. I was tracking RELENG_7, which has the m_defrag() > function. Actually, m_defrag() DOES exist in RELENG_7, it's m_collapse() that isn't yet MFC'd, apparently. So that is the function that needs to copied from HEAD's uipc_mbuf.c instead. From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 02:15:09 2008 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 4783816A402 for ; Fri, 22 Feb 2008 02:15:09 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx2.synetsystems.com (mx2.synetsystems.com [76.10.206.15]) by mx1.freebsd.org (Postfix) with ESMTP id E8C8D13C459 for ; Fri, 22 Feb 2008 02:15:08 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx2.synetsystems.com (Postfix, from userid 66) id 2300C65D; Thu, 21 Feb 2008 21:15:08 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSMmi-0003zY-Hk; Thu, 21 Feb 2008 19:33:08 -0600 To: Gavin Atkinson References: <20080215231507.EAB7D641@mx2.synetsystems.com> <1203359855.43782.60.camel@buffy.york.ac.uk> From: Richard Todd Date: Thu, 21 Feb 2008 19:33:08 -0600 In-Reply-To: <1203359855.43782.60.camel@buffy.york.ac.uk> (Gavin Atkinson's message of "Mon, 18 Feb 2008 18:37:35 +0000") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS: data sometimes not getting correctly flushed to disk (possible mmap/write issue)? 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, 22 Feb 2008 02:15:09 -0000 Gavin Atkinson writes: > On Fri, 2008-02-15 at 16:59 -0600, Richard Todd wrote: >> Further investigation and coming up with test cases brought me to the >> surprising conclusion that ZFS was to blame -- under certain conditions ZFS >> seems not to be writing all the data in the file out to disk correctly. >> The file appears to be good only so long as the file's data is in cache, but >> the data actually on disk doesn't match what's in cache. > I don't currently have a system that I can test this with, but is there > any chance you could make the following change to your script? > > #!/bin/sh > NAME=$1 > LEN=$2 > rm $NAME > ./a.out $NAME $LEN > ./gen2.py $NAME > md5 $NAME > + cp $NAME /some/ufs/filesystem/$NAME.1 > ls -l $NAME > sudo umount /u3 > sudo mount -t zfs u3 /u3 > md5 $NAME > + cp $NAME /some/ufs/filesystem/$NAME.2 > ls -l $NAME > + md5 /some/ufs/filesystem/$NAME.? > > and when you find files that differ, compare the two copies stored on > the UFS filesystem with cmp(1)? I'd be interested to know exactly what > the corruption looks like - is a single bit differen? Or was an entire > page destroyed? Neither, oddly enough. I modified the script in much the way you requested, copying the file to a file named "before" on a UFS filesystem before the unmount and to one named "after" after the remount. The cmp -l shows a difference of 10 bytes that are non-zero in the good copy and 0 in the bad "after" copy. Script started on Mon Feb 18 14:09:47 2008 1 ichotolot ~/bug[ 2:09PM] Z% sh -x test.sh /u3/tmp/foo1.ogg 403 + NAME=/u3/tmp/foo1.ogg + LEN=403 + rm /u3/tmp/foo1.ogg + ./a.out /u3/tmp/foo1.ogg 403 + ./gen2.py /u3/tmp/foo1.ogg + md5 /u3/tmp/foo1.ogg MD5 (/u3/tmp/foo1.ogg) = 72b9b992f31332fc1682cad1e97fa7e5 + cp /u3/tmp/foo1.ogg /bootsy/tmp/before + ls -l /u3/tmp/foo1.ogg -rw-r--r-- 1 rmtodd wheel 6238218 Feb 18 14:10 /u3/tmp/foo1.ogg + sudo umount /u3 + sudo mount -t zfs u3 /u3 + md5 /u3/tmp/foo1.ogg MD5 (/u3/tmp/foo1.ogg) = 3abd285e657684f4a2f89043f230b164 + ls -l /u3/tmp/foo1.ogg -rw-r--r-- 1 rmtodd wheel 6238218 Feb 18 14:10 /u3/tmp/foo1.ogg + cp /u3/tmp/foo1.ogg /bootsy/tmp/after 2 ichotolot ~/bug[ 2:10PM] Z% md5 /bootsy/tmp/{before,after} MD5 (/bootsy/tmp/before) = 72b9b992f31332fc1682cad1e97fa7e5 MD5 (/bootsy/tmp/after) = 3abd285e657684f4a2f89043f230b164 3 ichotolot ~/bug[ 2:10PM] Z% cmp -l !$ cmp -l /bootsy/tmp/{before,after} 6238209 236 0 6238210 71 0 6238211 310 0 6238212 372 0 6238213 16 0 6238214 45 0 6238215 220 0 6238216 112 0 6238217 376 0 6238218 1 0 4 ichotolot ~/bug[ 2:10PM] Z% exit Script done on Mon Feb 18 14:11:28 2008 An additional, important, note: I've discovered that this program can trigger more serious lossage in ZFS than I mentioned above: not only can you get corrupted data on disk, you can manage to corrupt the ZFS pool space maps, possibly to the point that ZFS panics on boot. So if anyone out there wants to test this, best do it on a ZFS pool you don't mind losing. (I *did* manage to recover the data off of the ZFS pool I did trash, and this info might prove useful to someone else in similar situations. The procedure was, roughly described, as follows: 1) Boot the system, record where the ZFS panic was. 2) Turn off the disks with the corrupted pool. (Fortunately, mine was on an external Firewire disk pair.) 3) Reboot the system, study where the panic was, and hack on space_map.c to disable the sanity checks on the space map that triggered the panic. Build and install the new kernel. 4) Turn the external disks back on, and reiterate 1)-3) until you can manage to get the external pool mounted. 5) My external pool (u3) was a mirrored pair of disks, so what I did next was detach one disk from u3 and make it a ZFS pool of its own, call it u3new. 6) Rsync everything from /u3 to /u3new. 7) Destroy the old u3 pool and add its disk as a mirror to the u3new mirror. 8) Reset the mountpoint property of u3new to make it mount at /u3 as before. 9) Wonder briefly why the ZFS designers implemented "zfs rename" but not a "zpool rename". :-) Fortunately, I had relatively decent backups of u3 in case the above didn't work.) Anyway, I've done further testing on a different machine, one whose only ZFS pool isn't used for anything more irreplacable than local cvsup storage. The panic/filesystem corruption doesn't seem to be as reliably repeatable as the data corruption -- the data corruption I mentioned in my original message seems to *always* happen when the program is run with the same arguments, the FS corruption doesn't. I do have some coredumps from this testing, though. Here's the one where it paniced while running the program; note that the crash is apparently somewhere in one of the syncer threads. Script started on Thu Feb 21 19:23:47 2008 blo-rakane# kgdb kernel.debug /u2/tmp/vmcore.183 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Reading symbols from /boot/kernel/geom_mirror.ko...done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/zfs.ko...done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/green_saver.ko Unread portion of the kernel message buffer: ZFS(panic): freeing free segment (vdev=0 offset=3d40000 size=20000) panic: ZFS cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(80b3e6ee,a7880840,8079a70f,80b6c6e0,1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(80b6c6e0,1,838e4615,a788084c,1,...) at kdb_backtrace+0x29 panic(838e4615,a7880970,838e4605,838e4657,2853465a,...) at panic+0x10f zfs_panic_recover(838e4657,0,0,3d40000,0,...) at zfs_panic_recover+0x9a metaslab_free_dva(297,0,0,83795000,297,...) at metaslab_free_dva+0x340 metaslab_free(83795000,84377374,297,0,0,...) at metaslab_free+0x8a zio_free_blk(83795000,84377374,297,0,83b8b210,...) at zio_free_blk+0x55 zil_sync(842afc00,84453700,7,3,2,...) at zil_sync+0x160 dmu_objset_sync(842af200,83ab38a0,84453700,0,83728498,...) at dmu_objset_sync+0x1a9 dsl_pool_sync(83728400,297,0,0,0,...) at dsl_pool_sync+0x98 spa_sync(83795000,297,0,13a,83728540,...) at spa_sync+0x3f8 txg_sync_thread(83728400,a7880d38,80b37e3c,30c,83beeab0,...) at txg_sync_thread+0x1ea fork_exit(838ab370,83728400,a7880d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xa7880d70, ebp = 0 --- KDB: enter: panic Physical memory: 625 MB Dumping 146 MB: 131 115 99 83 67 51 35 19 3 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x80492f49 in db_fncall (dummy1=-2141834399, dummy2=0, dummy3=-1484257740, dummy4=0xa7880624 "\200\233D\203@ºB\203\001") at /usr/src/sys/ddb/db_command.c:514 #2 0x804934cc in db_command (last_cmdp=0x80c361d4, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:411 #3 0x804935da in db_command_loop () at /usr/src/sys/ddb/db_command.c:464 #4 0x80494d7d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #5 0x807c3826 in kdb_trap (type=3, code=0, tf=0xa78807cc) at /usr/src/sys/kern/subr_kdb.c:510 #6 0x80aa2a5b in trap (frame=0xa78807cc) at /usr/src/sys/i386/i386/trap.c:647 #7 0x80a8872b in calltrap () at /usr/src/sys/i386/i386/exception.s:146 #8 0x807c39aa in kdb_enter (why=0x80b3b898 "panic", msg=0x80b3b898 "panic") at cpufunc.h:60 #9 0x8079a72c in panic (fmt=0x838e4615 "ZFS") at /usr/src/sys/kern/kern_shutdown.c:556 #10 0x838a75ea in zfs_panic_recover (fmt=Variable "fmt" is not available. ) at cmn_err.h:73 #11 0x8389b0c0 in metaslab_free_dva (spa=0x83795000, dva=Variable "dva" is not available. ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/metaslab.c:906 #12 0x8389b17a in metaslab_free (spa=0x83795000, bp=0x84377374, txg=663, now=0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/metaslab.c:1005 #13 0x838c51e5 in zio_free_blk (spa=0x83795000, bp=0x84377374, txg=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zio.c:1858 #14 0x838c2600 in zil_sync (zilog=0x842afc00, tx=0x84453700) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zil.c:1156 #15 0x838859f9 in dmu_objset_sync (os=0x842af200, pio=0x83ab38a0, tx=0x84453700) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:821 #16 0x838964f8 in dsl_pool_sync (dp=0x83728400, txg=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:188 #17 0x838a3cb8 in spa_sync (spa=0x83795000, txg=663) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/spa.c:2989 #18 0x838ab55a in txg_sync_thread (arg=0x83728400) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/txg.c:331 #19 0x80779628 in fork_exit (callout=0x838ab370 , arg=0x83728400, frame=0xa7880d38) at /usr/src/sys/kern/kern_fork.c:788 #20 0x80a887a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:212 (kgdb) fr 11 #11 0x8389b0c0 in metaslab_free_dva (spa=0x83795000, dva=Variable "dva" is not available. ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/metaslab.c:906 906 zfs_panic_recover("freeing free segment " (kgdb) l 901 } 902 } 903 } 904 905 if (!allocd) { 906 zfs_panic_recover("freeing free segment " 907 "(vdev=%llu offset=%llx size=%llx)", 908 (longlong_t)vdev, (longlong_t)offset, 909 (longlong_t)size); 910 } (kgdb) q blo-rakane# And here's the later crash on reboot as /etc/rc.d/zfs tries to mount the ZFS pool: Script started on Thu Feb 21 19:25:16 2008 blo-rakane# kgdb kernel.debug /u2/tmp/vmcore.184 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Reading symbols from /boot/kernel/geom_mirror.ko...done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/zfs.ko...done. Loaded symbols for /boot/kernel/zfs.ko Unread portion of the kernel message buffer: [I deleted all but the last bits--rmtodd] <118>Setting hostuuid: 84d7a50d-e797-11db-98e4-02004c01aaf5. <118>Setting hostid: 0x5241ef96. <118>Mounting local file systems: <118>. WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 6 ZFS storage pool version 6 ZFS(panic): freeing free segment (vdev=0 offset=3d40000 size=20000) panic: ZFS cpuid = 0 Uptime: 15s Got here! #1 Physical memory: 625 MB Dumping 46 MB: 31 15 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x8079a46a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:417 #2 0x8079a743 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0x838a65ea in zfs_panic_recover (fmt=Variable "fmt" is not available. ) at cmn_err.h:73 #4 0x8389a0c0 in metaslab_free_dva (spa=0x8360d000, dva=Variable "dva" is not available. ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/metaslab.c:906 #5 0x8389a17a in metaslab_free (spa=0x8360d000, bp=0xa78688d0, txg=665, now=0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/metaslab.c:1005 #6 0x838c41e5 in zio_free_blk (spa=0x8360d000, bp=0xa78688d0, txg=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zio.c:1858 #7 0x838c3165 in zil_parse (zilog=0x83735c00, parse_blk_func=0x838c13f0 , parse_lr_func=0x838c2f60 , arg=0x83bbeb80, txg=663) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zil.c:254 #8 0x838c34c4 in zil_destroy (zilog=0x83735c00, keep_first=0) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zil.c:449 #9 0x838c3771 in zil_replay (os=0x83737be0, arg=0x83613000, txgp=0x83613024, replay_func=0x838e9660) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zil.c:1562 #10 0x838d4338 in zfs_mount (vfsp=0x8379c538, td=0x83a86440) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:507 #11 0x80813829 in vfs_donmount (td=0x83a86440, fsflags=0, fsoptions=0x837c2e00) at /usr/src/sys/kern/vfs_mount.c:1014 #12 0x80814aa2 in nmount (td=0x83a86440, uap=0xa7868cfc) at /usr/src/sys/kern/vfs_mount.c:423 #13 0x80aa21a3 in syscall (frame=0xa7868d38) at /usr/src/sys/i386/i386/trap.c:1034 #14 0x80a88790 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:203 #15 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 4 #4 0x8389a0c0 in metaslab_free_dva (spa=0x8360d000, dva=Variable "dva" is not available. ) at /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/metaslab.c:906 906 zfs_panic_recover("freeing free segment " (kgdb) l 901 } 902 } 903 } 904 905 if (!allocd) { 906 zfs_panic_recover("freeing free segment " 907 "(vdev=%llu offset=%llx size=%llx)", 908 (longlong_t)vdev, (longlong_t)offset, 909 (longlong_t)size); 910 } (kgdb) qiut Undefined command: "qiut". Try "help". (kgdb) quit blo-rakane# exit blo-rakane# exit Script done on Thu Feb 21 19:26:13 2008 From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 03:36:48 2008 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 3CB1F16A408 for ; Fri, 22 Feb 2008 03:36:48 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-7-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFCD13C448 for ; Fri, 22 Feb 2008 03:36:48 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-7-int.cis.tamu.edu (Postfix) with ESMTP id 3DF0656958 for ; Thu, 21 Feb 2008 21:21:39 -0600 (CST) Received: from [192.168.1.2] (pool-71-113-234-22.herntx.dsl-w.verizon.net [71.113.234.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-7-int.cis.tamu.edu (Postfix) with ESMTP id 2B0375627E for ; Thu, 21 Feb 2008 21:21:37 -0600 (CST) Message-Id: From: David Duchscher To: current@FreeBSD.org Content-Type: multipart/signed; boundary=Apple-Mail-2--142486184; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 21:21:36 -0600 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Winbond IO chip driver 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, 22 Feb 2008 03:36:48 -0000 --Apple-Mail-2--142486184 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have started work on a WinBond chip driver (currently only the W83627HF chip) to provide access to the chips watchdog timer and sensors. I have never written a driver before and my C is rather rusty so I figured I would post what I currently have in hopes that some kind soul would take pity on me. What I have so far is located here: http://freebsd.tamu.edu/wbio/ The driver does attach and the watchdog timer works for the chip in my test machine running FreeBSD 6.3. TData sheets are here: http://www.winbond-usa.com/en/content/view/143/273/ Any advice, pointers, documents would be much appreciated. Thanks for your time... -- DaveD --Apple-Mail-2--142486184-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 04:17:24 2008 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 AC3E916A400 for ; Fri, 22 Feb 2008 04:17:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7A16C13C45B for ; Fri, 22 Feb 2008 04:17:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so161822wfa.7 for ; Thu, 21 Feb 2008 20:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=3fiT+sA4JJmh7sZ8uB6NO9EpvboBPIpERtykTiW/C1o=; b=qtLJqPiYEKWZIIkzGefEe6tdQeSwSPWLb2UTBg8y6dW9mt5WPR5bUKd+nMQVdTNf6edEglEYdvBN54e5usdY79gZybKO/KPOYJDIjqGYyJ2TRZeqktgZEpHhOL7U6pfZa4ik0tb1gBq8EWs0Cwq8M+WgOMGU3yKzUMtjFQd/Jww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=andbQgKLxFuKY0fAD1PNJrs8rWZPQznM6hDCyZEpYYIVbKRFoeE3tinWJrB+QiZ0CE+bO58gUPT76Xu9OSHcmtTmHk8ZrEBokZH0eUZHrDcqqeYfhfwBW79+p4TmU44R5CI3kW/qlAdxGfEDK/djuec050uXBv1Wwri8QeVY2dM= Received: by 10.143.168.14 with SMTP id v14mr5440576wfo.210.1203653844065; Thu, 21 Feb 2008 20:17:24 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 28sm1538388wfg.17.2008.02.21.20.17.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 20:17:22 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1M4HHQQ031200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 13:17:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1M4HGY3031199; Fri, 22 Feb 2008 13:17:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 13:17:15 +0900 From: Pyun YongHyeon To: Dimitry Andric Message-ID: <20080222041715.GA30497@cdnetworks.co.kr> References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BE2FEF.7010709@andric.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 04:17:24 -0000 On Fri, Feb 22, 2008 at 03:14:07AM +0100, Dimitry Andric wrote: > On 2008-02-22 02:59, Robert Backhaus wrote: > >> > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > >> > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > >> > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > >> > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > I have had trouble so far. I was tracking RELENG_7, which has the m_defrag() > > function. > > Actually, m_defrag() DOES exist in RELENG_7, it's m_collapse() that > isn't yet MFC'd, apparently. So that is the function that needs to > copied from HEAD's uipc_mbuf.c instead. Ah... yes, you're right. I need more coffee. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 04:27:10 2008 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 51CEE16A404 for ; Fri, 22 Feb 2008 04:27:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id E69A613C46B for ; Fri, 22 Feb 2008 04:27:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so436867wri.3 for ; Thu, 21 Feb 2008 20:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=ulBz+7iwWirp6KKAuHmq6PcQAOMmtRK4qSvXvlyWh8o=; b=mOBi4hbDRmTwVndo9vxwXWtk/F4tn6BWAyPpz4T4/Unw8KMISnDXo5tqLNsSpN8mghmxLvL9UQSNMTW6lFvqbBYVwrFMcXXmD43zQK4/TaCt4eamQjblYAH+GEVfzao0Y47xsLA9/XxoTzt4j50eVvvfsAVVcvb90Lrclhu5GeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=EXbgFFvMu3rhrKO4UShUhoUMqpjyS/vIxgr+heqaykhxPG2sgiN18tAx/F73jinO453aPPfJvHw0c/+hVzwo2hC3AWjOjnCIKM0oBSrROMD2+4FuWZ4FUxpYqRlDZwYAutpYrL+dpG8ywXAYaiHu/cu7hmM/tzxsN0VMSoUgpDU= Received: by 10.142.12.14 with SMTP id 14mr8336066wfl.152.1203654428195; Thu, 21 Feb 2008 20:27:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 30sm1541458wff.11.2008.02.21.20.27.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 20:27:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1M4R1dB031231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 13:27:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1M4R0j6031230; Fri, 22 Feb 2008 13:27:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 13:27:00 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20080222042700.GB30497@cdnetworks.co.kr> References: <20080221050635.GC26427@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 04:27:10 -0000 On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wrote: > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > > I am experiencing roughly 15% packet corruption on the re interface > on > > > > > my freebsd 7/amd64 box. > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #8 > : > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > Just to make troubleshooting difficult, this problem only shows up > > > > > after the system has been up for roughly 36 hours, depending on the > > > > > amount of traffic. > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > I'll handle it in a week. > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." seems a > > > bit drastic, and I don't do much with cvs proper. I take it that I should > use > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > It basically shows up as quagga establishing OSPF neighours as > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > VLAN hardware tagging is disabled on the interface. > > I'll do more debugging. > Hmm. That sounds like different issue to me. I guess I din't change any semantics in VLAN H/W tagging. Do you still the same VLAN H/W tagging related issues on RELENG_7? To narrow down the issue it would be even better to know which parts of H/W assistance was broken. For example, - Disable checksum offload for VLAN interface first and check whether quagga works. - Disable checksum offload for parent interface and check again. If you can post tcpdump output for broken conntection it may help a lot to diagnose the issue. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 04:28:48 2008 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 5E84C16A406 for ; Fri, 22 Feb 2008 04:28:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1001913C458 for ; Fri, 22 Feb 2008 04:28:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1M3vtpO056834; Thu, 21 Feb 2008 22:57:55 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m1M3vt1u025891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 22:57:55 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802220357.m1M3vt1u025891@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Feb 2008 22:57:58 -0500 To: David Duchscher , current@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Winbond IO chip driver 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, 22 Feb 2008 04:28:48 -0000 At 10:21 PM 2/21/2008, David Duchscher wrote: >I have started work on a WinBond chip driver (currently only the >W83627HF chip) to provide access to the chips watchdog timer and Hi, We have a similar one at http://www.tancsa.com/watchdog/ its for the W83697UF/UG Not sure how different your chip is. I used the old ichwd driver as a template ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 04:34:14 2008 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 661E316A401 for ; Fri, 22 Feb 2008 04:34:14 +0000 (UTC) (envelope-from joseph.koshy@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 EB0AC13C4F7 for ; Fri, 22 Feb 2008 04:34:13 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so225060fgg.35 for ; Thu, 21 Feb 2008 20:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tjnBItgfRpWGDrI+ZOtA+TzJmY2Ji1HtM8B8AaiaJqc=; b=MIPriOQ6CvxogfsaD+i8HfhRXYIvFiCmisihTnLf/1c7bf0O2i22moGt40bsZXHKoGJb6PyHWKL9bFDJ1jI0ojK6YqOo2ki3M0d9DUMxlxUKHYodLHZ+4Zg62UUxZY4BjtRBQH6Awyol5CKHK42bKQ3N4Ejx2uvcAGkrYyTXA8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ow3W+RC24sSNCIEpxVaxewusSx06qA4q89YlMZlBqyjntvnfpubzJvgV9eT+oHPAX0vbiFCDioCOE46lPro0sKBZpO+M7PDbep6+VzOkC4tUX7GkrybPqOqJdEozpdqVhR+hswc47apHgK/zgk9VzrhkLunHsZbtuYSrD0GqXHQ= Received: by 10.86.62.3 with SMTP id k3mr10309233fga.24.1203653148753; Thu, 21 Feb 2008 20:05:48 -0800 (PST) Received: by 10.86.90.11 with HTTP; Thu, 21 Feb 2008 20:05:48 -0800 (PST) Message-ID: <84dead720802212005u126dc5d0h6654a64fa1fcb581@mail.gmail.com> Date: Fri, 22 Feb 2008 09:35:48 +0530 From: "Joseph Koshy" To: "Ruslan Ermilov" In-Reply-To: <20080221151627.GA21518@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221151627.GA21518@team.vega.ru> Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 04:34:14 -0000 > With this change, we also bump the minimum requirement for source > upgrades from 6.0-RELEASE to "7.0-CURRENT at some point" because > new ar(1) requires libelf which is not available in previous > releases of FreeBSD. libelf should work fine on RELENG_6; we can merge it if needed. Regards, Koshy From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 04:42:36 2008 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 974BC16A401 for ; Fri, 22 Feb 2008 04:42:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id 42F2A13C46A for ; Fri, 22 Feb 2008 04:42:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so425980wra.13 for ; Thu, 21 Feb 2008 20:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=EkirH+l1t5lCH2tHOTbHegjoO+k6m4PrRtDXpqQvz4E=; b=RCV8t78m6ieYgP8nFANEHpQGZXxge53hv0vpIuwNzNLYkgKq6N9qnbmdrHg7wVZ6VcXXh7sP5Ep66w62yndAEKY+OhQ8oSN4ejMSts1K6V0lmAtmbyO0KuKOVBx6yuM0r2/gOF4kfU39E+37+e8Nvc81UxJdEg38wTNrzpLCroU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=jEhqn1uYQ72Va3BIDd3dPYhPYs1x+RRX/K8bMmTiWqoG4pfvsvdetf76jbXJDCI3drvd3JWW6n5HYWqzWxwpfNzWBFFUB0r+7WAKvUosi92J9aDGPShDzwd4cVqmlkDlKwsKKQIPjsTyinMJFOMavn1y4h2ECsNNU/EX6SefDL0= Received: by 10.142.141.21 with SMTP id o21mr8377927wfd.56.1203655353321; Thu, 21 Feb 2008 20:42:33 -0800 (PST) Received: from ?10.2.0.49? ( [67.96.45.122]) by mx.google.com with ESMTPS id 32sm1555263wfa.13.2008.02.21.20.42.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 20:42:32 -0800 (PST) Message-Id: <77944CFE-0BDB-433A-BA5C-6F776A5531AD@gmail.com> From: Garrett Cooper To: Mike Tancsa In-Reply-To: <200802220357.m1M3vt1u025891@lava.sentex.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 20:43:43 -0800 References: <200802220357.m1M3vt1u025891@lava.sentex.ca> X-Mailer: Apple Mail (2.919.2) Cc: David Duchscher , current@freebsd.org Subject: Re: Winbond IO chip driver 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, 22 Feb 2008 04:42:36 -0000 On Feb 21, 2008, at 7:57 PM, Mike Tancsa wrote: > At 10:21 PM 2/21/2008, David Duchscher wrote: >> I have started work on a WinBond chip driver (currently only the >> W83627HF chip) to provide access to the chips watchdog timer and > > Hi, > We have a similar one at > http://www.tancsa.com/watchdog/ > > its for the W83697UF/UG > > Not sure how different your chip is. I used the old ichwd driver as > a template > > ---Mike Looking at the relevant datasheets the pin config is different for all sides of the chip. Thus, you'll have to change the OP codes and methods used in read, writing, and polling operations. Plus the WDT setting procedure may be different... I too haven't written drivers for FreeBSD, but given my [limited] experience with C and PLDs (PICs to be exact), you may want to see whether or not the timing specs aren't being met as shown in the datasheet (assuming you're running into some level of deterministic errors). Using NOPs or verifying via readback for write operations (although inefficient) would most likely work to your advantage. May also want to try hackers@ instead of current@ Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 05:07:54 2008 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 A03C616A400 for ; Fri, 22 Feb 2008 05:07:54 +0000 (UTC) (envelope-from robbak@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id 3583D13C448 for ; Fri, 22 Feb 2008 05:07:53 +0000 (UTC) (envelope-from robbak@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so232010tid.3 for ; Thu, 21 Feb 2008 21:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=cL9pJiMNsaCrjqpf+DPJ4NzJ5IYWRtHEbcwPBhE43Bk=; b=oatMvLwA6xl06FumCHJ87NzExDyNiRLdrOCX1YjLzROdwY+/qNuoIaOlZVgUBvfoYEYqf8KabBa6VgolkqCKTnimyK+O+30z9Ns7ZatD3pytQsBNxeWjdt5CokoBvy/kY/bDjfT7yEFW/IU9Gv+SwhbfNjRsZGhsZ1gO0uhXSAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=c/bZv1A1KYDddzW22WzMUI7vq4AaX6iTtsMxwg0TtZAxKIjPrMGPYbzDGCbw4X/yU9+Sve44NlhpoI/gc26nFwaDp6dqSjaJ2s8lLT0QWSwWyr0i9afIQhDxpLydMZUoMuN9Sg9ujphb8uxb0/zwZ8ju96+PR73ar+FfHlrp008= Received: by 10.110.41.17 with SMTP id o17mr7576589tio.29.1203656872913; Thu, 21 Feb 2008 21:07:52 -0800 (PST) Received: by 10.110.26.11 with HTTP; Thu, 21 Feb 2008 21:07:52 -0800 (PST) Message-ID: Date: Fri, 22 Feb 2008 15:07:52 +1000 From: "Robert Backhaus" Sender: robbak@gmail.com To: "FreeBSD Current" In-Reply-To: <20080222041715.GA30497@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> X-Google-Sender-Auth: f9248156ddbe822c Subject: Re: Packet corruption in re0 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, 22 Feb 2008 05:07:54 -0000 On Fri, Feb 22, 2008 at 2:17 PM, Pyun YongHyeon wrote: > > On Fri, Feb 22, 2008 at 03:14:07AM +0100, Dimitry Andric wrote: > > On 2008-02-22 02:59, Robert Backhaus wrote: > > >> > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > >> > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > >> > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > >> > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > I have had trouble so far. I was tracking RELENG_7, which has the m_defrag() > > > function. > > > > Actually, m_defrag() DOES exist in RELENG_7, it's m_collapse() that > > isn't yet MFC'd, apparently. So that is the function that needs to > > copied from HEAD's uipc_mbuf.c instead. > > Ah... yes, you're right. I need more coffee. > > -- > Regards, > Pyun YongHyeon > You guys aren't making this troubleshooting any easier, you know. I just stripped out m_defrag, and inserted m_collapse, to my newly csupped RELENG_7. RELENG_7 does contain m_collapse. At least, buildkernel complains about it if i insert it into if_re.c It probably hasn't been rfc'd to RELENG_7_0. if_re.c is a different version, though. I'm using version 1.103. From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 05:41:10 2008 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 5807316A403 for ; Fri, 22 Feb 2008 05:41:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 257CF13C459 for ; Fri, 22 Feb 2008 05:41:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so172995wfa.7 for ; Thu, 21 Feb 2008 21:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=CeNfXfpxwR9FM6XkV0DzL4jRIInFdq3Ngu1vRcbv3z8=; b=rvk5afXS+hewDQ0J9RaRv0KekRl9+xytfR7fmcUgZP3Z5ZPRPQ0UiWJg3rj3GtKfGhzXbcXsnv729/FXoVKzGg1Fuuf8NnIevaDIreInPCj9tz6tNGoeXB3XahsVUpZFbkbK1E3ndRPPSivBqnfDC1uwj7q+BAnxEMmd3iM8qoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=IzQHCzTEUlVUUpRnrSjrykprKPHDrg+OTDK/SYQoY2Ij6hXAmviN1JrHh35TD06QAgWTIx6OkEBEl6ajDBAIrdE/Cub5qU9NlE9fV2gL000MMipTmK+LCRb3ihs1XKnPjaR2u33+fRQE2REOHGdbQvafhZ13trPcCHNnW+1ruQk= Received: by 10.142.245.10 with SMTP id s10mr1166507wfh.15.1203658869751; Thu, 21 Feb 2008 21:41:09 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 22sm1644777wfg.15.2008.02.21.21.41.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 21:41:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1M5f46S031568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 14:41:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1M5f3i9031567; Fri, 22 Feb 2008 14:41:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 14:41:03 +0900 From: Pyun YongHyeon To: Robert Backhaus Message-ID: <20080222054103.GD30497@cdnetworks.co.kr> References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 05:41:10 -0000 On Fri, Feb 22, 2008 at 03:07:52PM +1000, Robert Backhaus wrote: > On Fri, Feb 22, 2008 at 2:17 PM, Pyun YongHyeon wrote: > > > > On Fri, Feb 22, 2008 at 03:14:07AM +0100, Dimitry Andric wrote: > > > On 2008-02-22 02:59, Robert Backhaus wrote: > > > >> > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > >> > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > > >> > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > > >> > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > I have had trouble so far. I was tracking RELENG_7, which has the m_defrag() > > > > function. > > > > > > Actually, m_defrag() DOES exist in RELENG_7, it's m_collapse() that > > > isn't yet MFC'd, apparently. So that is the function that needs to > > > copied from HEAD's uipc_mbuf.c instead. > > > > Ah... yes, you're right. I need more coffee. > > > > -- > > Regards, > > Pyun YongHyeon > > > > You guys aren't making this troubleshooting any easier, you know. > > I just stripped out m_defrag, and inserted m_collapse, to my newly > csupped RELENG_7. > > RELENG_7 does contain m_collapse. At least, buildkernel complains > about it if i insert > it into if_re.c It probably hasn't been rfc'd to RELENG_7_0. > > if_re.c is a different version, though. I'm using version 1.103. Download if_re.c and if_rlreg.h in the following URL and rebuild the driver. http://people.freebsd.org/~yongari/re/7.0R/if_re.c http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 05:44:06 2008 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 3C61516A403 for ; Fri, 22 Feb 2008 05:44:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0D04213C447 for ; Fri, 22 Feb 2008 05:44:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so173409wfa.7 for ; Thu, 21 Feb 2008 21:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=eUnsOjiYvm2fabucB04enKXF4oXmTMFFXA5YLM66MKY=; b=KGcdA+Li0yewi9oABjgsThxwrKuAMwfP3glBm9rCVg5jJYis7WIitLy003U24qc5DaMbXqX9L4CTs0lemEhZRfF6ZTjaOnB+8N/+ya3T280C7DWGmynBbjKSH9/DT0r2gB0/Mm5IT36YNxVl+D0sMVcVbDFttuf/GOn2STHQ2MM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=UZxrF5QNDHNzrRZUFGbxbTVGJ8DlCkJkNp1Nm4bylKIX8ycpO2ciGX6v9b6lgw40pjU7gtmqIdArDiB5bL6kMgowa7EdCx/cPsBf24FoongHllpbGtJAFQtRy32oaO53vHG9TjOq93jJ0nk8Hizmv+c1HRJcK4UL1hfx8CZ1s4M= Received: by 10.142.212.19 with SMTP id k19mr8373488wfg.154.1203659045744; Thu, 21 Feb 2008 21:44:05 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 28sm1492750wfd.1.2008.02.21.21.44.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Feb 2008 21:44:02 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1M5hwSh031593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 14:43:58 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1M5hu1s031592; Fri, 22 Feb 2008 14:43:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 14:43:56 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20080222054356.GE30497@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080218081801.GB14601@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 05:44:06 -0000 On Mon, Feb 18, 2008 at 05:18:01PM +0900, To Milan Obuch wrote: > On Sun, Feb 17, 2008 at 03:17:26PM +0100, Milan Obuch wrote: > > On Sunday 17 February 2008, Milan Obuch wrote: > > > On Sunday 17 February 2008, Robert Watson wrote: > > > > On Sat, 16 Feb 2008, Milan Obuch wrote: > > > > >> I have tested 4-port Rhine III(6105LOM) and I never seen this hangs. > > > > >> Does this also happen on other network interface too? When the system > > > > >> hangs, would you break into DDB and show me the output of 'show > > > > >> alllocks' and 'ps'? > > > > > > > > > > I need some tests with another box. I was not able to break into DDB. > > > > > Ctrl-Alt-Esc worked until hang. Hang was really hard, Ctrl-Alt-Esc did > > > > > not invoke DDB. I do not feel if_vr is culprit here, more probably PCI > > > > > bus got somehow locked, but I have no idea how could I test it > > > > > currently. > > > > > > > > FYI, there are known issues with the effectiveness of syscons > > > > ctrl-alt-esc to get into the debugger -- if you haven't tried with a > > > > serial break on a serial console, you might want to do so. This is > > > > because syscons's interrupt handler acquires the Giant lock in an > > > > ithread, requiring a lot more things to be happy to succeed. In > > > > constrast, sio (and friends) use fast interrupt handlers and no Giant > > > > lock on the way to processing the break request. It may well be that a > > > > serial break doesn't get into DDB for you, but it's worth trying... > > > > > > > > Robert N M Watson > > > > Computer Laboratory > > > > University of Cambridge > > > > > > You are right, after rebuilding kernel with BREAK_TO_DEBUGGER I am able to > > > get requested data. BTW, I can't find just now what ALT_BREAK_TO_DEBUGGER > > > means... > > > > > > After kldload if_vr, dhclient vr0 and ping -f in a minute > > > system freezes. > > > > > > > Correction... as I moved cable from on-board re0 to vr0, system remembered arp > > table entry and did not actually try to use vr0. Now I repeated it, but boot > > system with cable in vr0. This time it hangs right after ping <>, and break > > does not enter debugger... hard hang. I tried it twice, the same result... > > > > So no data to check, actually, only hard hang. > > > > I've put up a new version under the old URL. > It's not tested in sparc64 but it seems to work on i386. > Would you give it spin? > Any progress here? Does the updated one works on your box? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 06:36:59 2008 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 7971616A400 for ; Fri, 22 Feb 2008 06:36:59 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5297813C43E for ; Fri, 22 Feb 2008 06:36:59 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1M6atYw070763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 22:36:55 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47BE6D86.6050801@errno.com> Date: Thu, 21 Feb 2008 22:36:54 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dimitry Andric References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> In-Reply-To: <47BE2FEF.7010709@andric.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: pyunyh@gmail.com, FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 22 Feb 2008 06:36:59 -0000 Dimitry Andric wrote: > On 2008-02-22 02:59, Robert Backhaus wrote: >>> > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. >>> > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add >>> > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on >>> > HEAD/RELENG_7 to if_re.c). That would make it build on your box. >> I have had trouble so far. I was tracking RELENG_7, which has the m_defrag() >> function. > > Actually, m_defrag() DOES exist in RELENG_7, it's m_collapse() that > isn't yet MFC'd, apparently. So that is the function that needs to > copied from HEAD's uipc_mbuf.c instead. m_collapsed has been mfc'd: revision 1.174.2.1 date: 2008/02/08 20:58:18; author: sam; state: Exp; lines: +86 -0 MFC: promote ath_defrag to m_collapse From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 07:25:39 2008 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 CB26516A400 for ; Fri, 22 Feb 2008 07:25:39 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE6413C4D3 for ; Fri, 22 Feb 2008 07:25:39 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so573941pyb.10 for ; Thu, 21 Feb 2008 23:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=g5/cYXOPGjHVb+6MVYAUPTB28QT1QxL1udQUTtZlIDw=; b=NuLuwAkFv7wHJLm6IC9w+UxAj3sGKOk3e7Meex27vBdjQR8YGFo9PukKlPIc5haWoXqTPb0S9GN8tsdnRUQw1cBi+CBP/d/eSRDUvLlz0muTNPbjRC3rKIX2hJcUslqWez2+bcpOOZmfPHEAYHs1e399KpOnf04ZDTIM8BW7taw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dE+cqb3PUL2vqEQ4b+Kb/USx0hefNUKMHJwpGEXFvmsrCXcF3sDZgtQNtb2XVQD03RUu5q52Odmbjkj6YQecqOt3PC4+kRpSLfI6TeFSWamqXq7f3npXNG+A9kLDDiNqIfQNfjLtNyDvcQUhsoEVKeZsvoMxg46OqXqMFXXUjww= Received: by 10.65.81.10 with SMTP id i10mr21506311qbl.75.1203665138091; Thu, 21 Feb 2008 23:25:38 -0800 (PST) Received: by 10.64.195.8 with HTTP; Thu, 21 Feb 2008 23:25:38 -0800 (PST) Message-ID: <5f67a8c40802212325x7f52c483y9d636def40d902cf@mail.gmail.com> Date: Fri, 22 Feb 2008 07:25:38 +0000 From: "Zaphod Beeblebrox" To: "Derek Ragona" In-Reply-To: <6.0.0.22.2.20080221162331.024b0dc8@mail.computinginnovations.com> MIME-Version: 1.0 References: <5f67a8c40802211035n3b6db2fcvd4309ebd1222cb69@mail.gmail.com> <6.0.0.22.2.20080221162331.024b0dc8@mail.computinginnovations.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: 100% of one CPU for nvidia 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, 22 Feb 2008 07:25:39 -0000 On Thu, Feb 21, 2008 at 10:24 PM, Derek Ragona < derek@computinginnovations.com> wrote: [ my report of 100% of one cpu going to nvidia, deleted] > > I have seen this using xorg 7.3.1 with legacy 96 nvidia drivers too. > > I didn't have the problem until I went from xorg 7.1 to 7.3. > Are you using 8xxx series nvidia chips? Ie: is this a problem with that series, or is it more general? From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 07:36:15 2008 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 E9EA016A400 for ; Fri, 22 Feb 2008 07:36:15 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id A24F613C465 for ; Fri, 22 Feb 2008 07:36:15 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=1622 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSS21-0001l3-3b; Fri, 22 Feb 2008 07:09:17 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1M79Gfc056952; Fri, 22 Feb 2008 10:09:16 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1M79F2F056951; Fri, 22 Feb 2008 10:09:15 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 10:09:15 +0300 From: Ruslan Ermilov To: Peter Jeremy Message-ID: <20080222070915.GB56282@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221151627.GA21518@team.vega.ru> <20080221181426.GM51095@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221181426.GM51095@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 07:36:16 -0000 On Fri, Feb 22, 2008 at 05:14:26AM +1100, Peter Jeremy wrote: > On Thu, Feb 21, 2008 at 06:16:27PM +0300, Ruslan Ermilov wrote: > >With this change, we also bump the minimum requirement for source > >upgrades from 6.0-RELEASE to "7.0-CURRENT at some point" because > >new ar(1) requires libelf which is not available in previous > >releases of FreeBSD. > > Can't libelf be added to the bootstrap toolchain if it doesn't already exist? > Theoretically yes, but then there's also libarchive, and I'm not sure which versions of libelf/libarchive were tested to work with BSD ar(1). I have a different idea of how to fix things. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 07:36:17 2008 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 3EC1116A401; Fri, 22 Feb 2008 07:36:17 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id E088813C46E; Fri, 22 Feb 2008 07:36:16 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=54238 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSS0H-0001jv-92; Fri, 22 Feb 2008 07:07:29 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1M77Sws056942; Fri, 22 Feb 2008 10:07:28 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1M77SKN056941; Fri, 22 Feb 2008 10:07:28 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 10:07:28 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Ivan Voras , freebsd-current@freebsd.org Message-ID: <20080222070728.GA56282@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221173150.GA93693@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 07:36:17 -0000 On Thu, Feb 21, 2008 at 09:31:51AM -0800, David O'Brien wrote: > On Thu, Feb 21, 2008 at 06:25:49PM +0300, Ruslan Ermilov wrote: > > in turn means that we won't be able to upgrade to 8.0 > > (when it's released) from <7.0 (libelf exists only > > starting from 7.0). > > And many of us don't feel that is a bad limitation. > Upgrading to FreeBSD Y+2.x from Y.x is not _required_ to work. > I was just pointing out the fact, because now we have it set to 600034. And breaking it for no good reason makes no sense. I'll post a patch soon (after local testing) that should make everyone happy. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 08:44:13 2008 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 C2DCE16A405 for ; Fri, 22 Feb 2008 08:44:13 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 88FAB13C45E for ; Fri, 22 Feb 2008 08:44:12 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=LAP6yzbAFgZ1XzcPcovJJ49c6EO98ciTdiqk2JGsyfbtERO6PHUz5CepOTwWDaryWN7gTwNVXkJdkNEM82zTclxB0RKf98HY+W6PWhH83+gsehGkn86pt0gmfNilMEq+zMF8Ou4nXXQsceszO2zIg67A+3/QrrCdnX3Cdz96W9rtV8KSDEPdo4Pg9vqCXRnNpW1vZJBBrvEXyIm2f3Q/jcDgLIcbzzIvNj5sHgMmnD5XBMt1Pct9ABtYR/f4am1L; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1JSTVr-0006vq-TU; Fri, 22 Feb 2008 08:44:11 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSTV5-0000Mr-R6; Fri, 22 Feb 2008 08:43:23 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSTV4-0000l2-EE; Fri, 22 Feb 2008 10:43:22 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: Message from Pyun YongHyeon of "Fri, 22 Feb 2008 13:27:00 +0900." <20080222042700.GB30497@cdnetworks.co.kr> X-Attribution: BOFH Date: Fri, 22 Feb 2008 10:43:22 +0200 Message-Id: Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 22 Feb 2008 08:44:13 -0000 Pyun YongHyeon wrote: > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wr ote: > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > > > I am experiencing roughly 15% packet corruption on the re inter face > > on > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEA SE #8 > > : > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > Just to make troubleshooting difficult, this problem only shows up > > > > > > after the system has been up for roughly 36 hours, depending on the > > > > > > amount of traffic. > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > I'll handle it in a week. > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." se ems a > > > > bit drastic, and I don't do much with cvs proper. I take it that I sh ould > > use > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > It basically shows up as quagga establishing OSPF neighours as > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > VLAN hardware tagging is disabled on the interface. > > > > I'll do more debugging. > > > > Hmm. That sounds like different issue to me. I guess I din't change > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > tagging related issues on RELENG_7? > > To narrow down the issue it would be even better to know which parts > of H/W assistance was broken. For example, > - Disable checksum offload for VLAN interface first and check > whether quagga works. You can only disable offload on the parent interface. > - Disable checksum offload for parent interface and check again. > If you can post tcpdump output for broken conntection it may help a > lot to diagnose the issue. The only flag affecting this behaviour is vlanhwtag. Various permutations of the interface flags make no difference to this behaviour as long as hardware tagging is enabled. It seems like it's corrupting large packets on transmit when vlanhwtag is enabled. From the tcpdump output it looks like a padding or packet length issue. Here's what tcpdump on the re(4) device thinks it's transmitting: 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 Here's what was actually recieved by the em(4) device on the neighbour. Note the absense of the 801.1Q header: 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype IPv4 (0x0800), length 1506: 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 When vlanhwtagging is disabled, the re(4) device transmits: 00:90:fb:0c:89:7d > 00:08:a1:3c:32:9c, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.89 > 196.22.138.92: OSPFv2, Database Description, length: 1472 and the em(4) device recieves: 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 Let me know if you need more detailed tcpdump output than I've provided. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 08:56:33 2008 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 61ECD16A401 for ; Fri, 22 Feb 2008 08:56:33 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED9313C457 for ; Fri, 22 Feb 2008 08:56:32 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=55442 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSThm-0006bo-BW; Fri, 22 Feb 2008 08:56:30 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1M8uTKv064613; Fri, 22 Feb 2008 11:56:29 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1M8uS19064612; Fri, 22 Feb 2008 11:56:28 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 11:56:28 +0300 From: Ruslan Ermilov To: Joseph Koshy Message-ID: <20080222085628.GA57428@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221151627.GA21518@team.vega.ru> <84dead720802212005u126dc5d0h6654a64fa1fcb581@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720802212005u126dc5d0h6654a64fa1fcb581@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 08:56:33 -0000 On Fri, Feb 22, 2008 at 09:35:48AM +0530, Joseph Koshy wrote: > > With this change, we also bump the minimum requirement for source > > upgrades from 6.0-RELEASE to "7.0-CURRENT at some point" because > > new ar(1) requires libelf which is not available in previous > > releases of FreeBSD. > > libelf should work fine on RELENG_6; we can merge it if needed. > I don't think it's needed. On systems that don't have libelf/libarchive, we can simply fall back to using GNU ar(1) for the purposes of build. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:03:00 2008 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 964FB16A401 for ; Fri, 22 Feb 2008 09:03:00 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id E829A13C43E for ; Fri, 22 Feb 2008 09:02:59 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.13.8) with ESMTP id m1LMN0DT047865; Thu, 21 Feb 2008 16:23:01 -0600 (CST) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20080221162331.024b0dc8@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 21 Feb 2008 16:24:55 -0600 To: "Zaphod Beeblebrox" , freebsd-current@freebsd.org From: Derek Ragona In-Reply-To: <5f67a8c40802211035n3b6db2fcvd4309ebd1222cb69@mail.gmail.co m> References: <5f67a8c40802211035n3b6db2fcvd4309ebd1222cb69@mail.gmail.com> Mime-Version: 1.0 X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: 100% of one CPU for nvidia 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, 22 Feb 2008 09:03:00 -0000 At 12:35 PM 2/21/2008, Zaphod Beeblebrox wrote: >Has anyone noticed the latest nvidia binary driver driving their interrupt >load up? I have: > >nvidia0: port 0xef00-0xef7f mem >0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 16 at >device 0.0 on pci3 >nvidia0: [GIANT-LOCKED] >nvidia0: [ITHREAD] >nvidia1: port 0xdf00-0xdf7f mem >0xf7000000-0xf7ffffff,0xe0000000-0xefffffff,0xf8000000-0xf9ffffff irq 17 at >device 0.0 on pci4 >nvidia1: [GIANT-LOCKED] >nvidia1: [ITHREAD] > >and > >nvidia-driver-169.07 NVidia graphics card binary drivers for hardware OpenGL >ren > >FreeBSD canoe 7.0-RC3 FreeBSD 7.0-RC3 #0: Wed Feb 20 15:19:37 EST 2008 >root@canoe.dclg.ca:/usr/obj/d/64/usr/src/sys/CANOE32 i386 > >(and 7.3_1 of xorg) > >and my top shows the following whenever X is active (note the 43.2%interrupt): > >last pid: 9412; load averages: 1.14, 0.89, 1.84 up 0+13:35:32 >13:33:15 >145 processes: 1 running, 133 sleeping, 11 stopped >CPU states: 0.2% user, 0.2% nice, 1.7% system, 43.2% interrupt, 54.7%idle >Mem: 648M Active, 2018M Inact, 309M Wired, 31M Cache, 112M Buf, 181M Free >Swap: 16G Total, 16G Free > > >My xorg.conf is configured to only use one of the GPU devices. I have seen this using xorg 7.3.1 with legacy 96 nvidia drivers too. I didn't have the problem until I went from xorg 7.1 to 7.3. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:16:48 2008 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 0020C16A404; Fri, 22 Feb 2008 09:16:47 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 305A313C4E1; Fri, 22 Feb 2008 09:16:46 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=54582 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSU1N-0008Zk-9b; Fri, 22 Feb 2008 09:16:45 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1M9Ghns064947; Fri, 22 Feb 2008 12:16:43 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1M9Ghu5064946; Fri, 22 Feb 2008 12:16:43 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 12:16:42 +0300 From: Ruslan Ermilov To: "David O'Brien" , Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy Message-ID: <20080222091642.GB57428@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: <20080222070728.GA56282@team.vega.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@FreeBSD.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 09:16:48 -0000 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Here's the promised patch. What it does: - Switch again to using BSD ar(1) by default, but provide a knob to use GNU ar(1) as the system ar(1). (Option WITH_BSDAR is replaced with option WITH_GNUAR.) - Install BSD ar(1) as bsdar(1) with the necessary links: bsdranlib(1), ar(1), and ranlib(1) (the latter two unless we build WITH_GNUAR). - ar.1 moved to bsdar.1 along with some bugfixing. - Don't proceed with bsdar(1) if option WITHOUT_TOOLCHAIN is set. - Handle upgrades nicely: use GNU ar(1) during the build on older systems, and use BSD ar(1) on newer systems. For now, always bootstrap BSD ar(1) on newer systems during the build (in case some bugs pop up), but after some period of testing, we can stop unconditionally bootstrapping it. Please review. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: sys/sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.337 diff -u -p -r1.337 param.h --- sys/sys/param.h 21 Feb 2008 16:12:46 -0000 1.337 +++ sys/sys/param.h 22 Feb 2008 07:43:33 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800021 /* Master, propagated to newvers */ +#define __FreeBSD_version 800022 /* Master, propagated to newvers */ #ifndef LOCORE #include Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.598 diff -u -p -r1.598 Makefile.inc1 --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 +++ Makefile.inc1 22 Feb 2008 08:32:50 -0000 @@ -885,8 +885,13 @@ _crunchgen= usr.sbin/crunch/crunchgen _mklocale= usr.bin/mklocale .endif +.if ${BOOTSTRAPPING} >= 800022 +_ar= usr.bin/ar +.endif + bootstrap-tools: .for _tool in \ + ${_ar} \ ${_mklocale} \ ${_strfile} \ ${_gperf} \ @@ -967,6 +972,10 @@ _kgzip= usr.sbin/kgzip .endif .endif +.if make(cross-tools) && ${BOOTSTRAPPING} < 800022 +.MAKEFLAGS+= -DWITH_GNUAR +.endif + cross-tools: .for _tool in \ gnu/usr.bin/binutils \ Index: gnu/usr.bin/binutils/ar/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ar/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- gnu/usr.bin/binutils/ar/Makefile 21 Feb 2008 16:59:02 -0000 1.16 +++ gnu/usr.bin/binutils/ar/Makefile 22 Feb 2008 06:56:10 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ar -#MAN= gnu-ar.1 -.else -PROG= ar +.if !defined(WITH_GNUAR) +PROGNAME= gnu-ar +MAN= gnu-ar.1 +gnu-ar.1: ar.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gnu-ar.1 .endif + +PROG= ar SRCS= ar.c not-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: gnu/usr.bin/binutils/ranlib/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ranlib/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- gnu/usr.bin/binutils/ranlib/Makefile 21 Feb 2008 16:59:02 -0000 1.17 +++ gnu/usr.bin/binutils/ranlib/Makefile 22 Feb 2008 06:54:04 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ranlib -#MAN= gnu-ranlib.1 -.else -PROG= ranlib +.if !defined(WITH_GNUAR) +PROGNAME= gnu-ranlib +MAN= gnu-ranlib.1 +gnu-ranlib.1: ranlib.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gnu-ranlib.1 .endif + +PROG= ranlib SRCS= ar.c is-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: usr.bin/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/Makefile,v retrieving revision 1.309 diff -u -p -r1.309 Makefile --- usr.bin/Makefile 22 Feb 2008 06:47:44 -0000 1.309 +++ usr.bin/Makefile 22 Feb 2008 07:12:21 -0000 @@ -11,7 +11,7 @@ SUBDIR= alias \ apply \ - ar \ + ${_ar} \ asa \ at \ ${_atm} \ @@ -292,6 +292,7 @@ _vacation= vacation .endif .if ${MK_TOOLCHAIN} != "no" +_ar= ar _c89= c89 _c99= c99 _gprof= gprof Index: usr.bin/ar/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- usr.bin/ar/Makefile 22 Feb 2008 06:53:52 -0000 1.19 +++ usr.bin/ar/Makefile 22 Feb 2008 07:21:05 -0000 @@ -1,10 +1,8 @@ # $FreeBSD: src/usr.bin/ar/Makefile,v 1.19 2008/02/22 06:53:52 obrien Exp $ -.if defined(WITH_BSDAR) -PROG= ar -.else PROG= bsdar -.endif +LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib +MLINKS= bsdar.1 bsdranlib.1 SRCS= ar.c read.c util.c write.c WARNS?= 5 @@ -12,17 +10,13 @@ WARNS?= 5 DPADD= ${LIBARCHIVE} ${LIBBZ2} ${LIBZ} ${LIBELF} LDADD= -larchive -lbz2 -lz -lelf -.if defined(WITH_BSDAR) -NO_SHARED?= yes -LINKS= ${BINDIR}/ar ${BINDIR}/ranlib -MLINKS= ar ranlib +.if !defined(WITH_GNUAR) +NO_SHARED?= yes +LINKS+= ${BINDIR}/bsdar ${BINDIR}/ar +MLINKS+= bsdar.1 ar.1 +LINKS+= ${BINDIR}/bsdranlib ${BINDIR}/ranlib +MLINKS+= bsdranlib.1 ranlib.1 .else -LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib -MLINKS= bsdar.1 bsdranlib.1 - -CLEANFILES+= bsdar.1 -bsdar.1: ar.1 - ln -sf ${.ALLSRC} ${.TARGET} .endif .include Index: usr.bin/ar/ar.1 =================================================================== RCS file: usr.bin/ar/ar.1 diff -N usr.bin/ar/ar.1 --- usr.bin/ar/ar.1 21 Feb 2008 10:52:31 -0000 1.17 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,407 +0,0 @@ -.\" Copyright (c) 2007 Joseph Koshy. 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 Joseph Koshy ``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 Joseph Koshy 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. -.\" -.\" $FreeBSD: src/usr.bin/ar/ar.1,v 1.17 2008/02/21 10:52:31 kaiw Exp $ -.\" -.Dd August 31, 2007 -.Os -.Dr AR 1 -.Dt RANLIB 1 -.Sh NAME -.Nm ar , -.Nm ranlib -.Nd manage archives -.Sh SYNOPSIS -.Nm -.Fl d -.Op Fl T -.Op Fl j -.Op Fl v -.Op Fl z -.Ar archive -.Ar files ... -.Nm -.Fl m -.Op Fl T -.Op Fl a Ar position-after -.Op Fl b Ar position-before -.Op Fl i Ar position-before -.Op Fl j -.Op Fl s -.Op Fl z -.Ar archive -.Ar files ... -.Nm -.Fl p -.Op Fl T -.Op Fl v -.Ar archive -.Op Ar files ... -.Nm -.Fl r -.Op Fl T -.Op Fl a Ar position-after -.Op Fl b Ar position-before -.Op Fl c -.Op Fl i Ar position-before -.Op Fl j -.Op Fl s -.Op Fl u -.Op Fl v -.Op Fl z -.Ar archive -.Ar files ... -.Nm -.Fl s -.Op Fl j -.Op Fl z -.Ar archive -.Nm -.Fl t -.Op Fl T -.Op Fl v -.Ar archive -.Op Ar files ... -.Nm -.Fl x -.Op Fl C -.Op Fl T -.Op Fl o -.Op Fl u -.Op Fl v -.Ar archive -.Op Ar files ... -.Nm ranlib -.Ar archive ... -.Sh DESCRIPTION -The -.Nm -utility creates and maintains groups of files combined into an -archive. -Once an archive has been created, new files can be added to it, and -existing files can be extracted, deleted or replaced. -.Pp -Files are named in the archive by their last file name component, -so if a file referenced by a path containing a -.Dq / -is archived, it will be named by the last component of the path. -Similarly when matching paths listed on the command line against -file names stored in the archive, only the last component of the -path will be compared. -.Pp -The normal use of -.Nm -is for the creation and maintenance of libraries suitable for use -with the link editor -.Xr ld 1 , -although it is not restricted to this purpose. -The -.Nm -utility can create and manage an archive symbol table (see -.Xr ar 5 ) -used to speed up link editing operations. -If a symbol table is present in an archive, it will be -kept upto-date by subsequent operations on the archive (excepting -the quick update specified by the -.Fl q -option). -.Pp -The -.Nm ranlib -utility is used to add an archive symbol table -to an existing archive. -.Sh OPTIONS -The -.Nm -utility supports the following options: -.Bl -tag -width indent -.It Fl a Ar member-after -When used with option -.Fl m -this option specifies that the archive members specified by -arguments -.Ar files ... -are moved to after the archive member named by argument -.Ar member-after . -When used with option -.Fl r -this option specifies that the files specified by arguments -.Ar files ... -are added after the archive member named by argument -.Ar member-after . -.It Fl b Ar member-before -When used with option -.Fl m -this option specifies that the archive members specified by -arguments -.Ar files ... -are moved to before the archive member named by argument -.Ar member-before . -When used with option -.Fl r -this option specifies that the files specified by arguments -.Ar files ... -are added before the archive member named by argument -.Ar member-before . -.It Fl c -Suppress the informational message printed when a new archive is -created using the -.Fl r -and -.Fl q -options. -.It Fl C -Prevent extracted files from replacing like-named files -in the file system. -.It Fl d -Delete the members named by arguments -.Ar files ... -from the archive specified by argument -.Ar archive . -The archive's symbol table, if present, is updated to reflect -the new contents of the archive. -.It Fl f -Synonymous with option -.Fl T . -.It Fl i Ar member-before -Synonymous with option -.Fl b . -.It Fl j -Compress the resulting archive with -.Xr bzip2 1 . -.It Fl m -Move archive members specified by arguments -.Ar files ... -within the archive. -If a position has been specified by one of the -.Fl a , -.Fl b -or -.Fl i -options, the members are moved to before or after the specified -position. -If no position has been specified, the specified members are moved -to the end of the archive. -If the archive has a symbol table, it is updated to reflect the -new contents of the archive. -.It Fl o -Preserve the original modification times of members when extracting -them. -.It Fl p -Write the contents of the specified archive members named by -arguments -.Ar files ... -to standard output. -If no members were specified, the contents of all the files in the -archive are written in the order they appear in the archive. -.It Fl q -Append the files specified by arguments -.Ar files ... -to the archive specified by argument -.Ar archive -without checking if the files already exist in the archive and -without updating the archive's symbol table. -If the archive file -.Ar archive -does not already exist, a new archive is created. -However, to be compatible with GNU -.Nm , -.Fl q -is implemented as a synonym for -.Fl r . -.It Fl r -Replace (add) the files specified by arguments -.Ar files ... -in the archive specified by argument -.Ar archive , -creating the archive if necessary. -Files that replace existing files do not change the order of files -within the archive. -If a file named in arguments -.Ar files ... -does not exist, existing members in the archive that match that -name are not changed. -New files are added to the end of the archive unless one of the -positioning options -.Fl a , -.Fl b -or -.Fl i -is specified. -The archive symbol table, if it exists, is updated to reflect the -new state of the archive. -.It Fl s -Add an archive symbol table (see -.Xr ar 5 ) -to the archive specified by argument -.Ar archive . -Invoking -.Nm -with the -.Fl s -option alone is equivalent to invoking -.Nm ranlib . -.It Fl t -List the files specified by arguments -.Ar files ... -in the order in which they appear in the archive, one per line. -If no files are specified, all files in the archive are listed. -.It Fl T -Use only the first fifteen characters of the archive member name or -command line file name argument when naming archive members. -.It Fl u -Conditionally update the archive or extract members. -When used with the -.Fl r -option, files named by arguments -.Ar files ... -will be replaced in the archive if they are newer than their -archived versions. -When used with the -.Fl x -option, the members specified by arguments -.Ar files ... -will be extracted only if they are newer than the corresponding -files in the file system. -.It Fl v -Provide verbose output. -When used with the -.Fl d , -.Fl m , -.Fl q -or -.Fl x -options, -.Nm -gives a file-by-file description of the archive modification being -performed, which consists of three white-space seperated fields: -the option letter, a dash -.Dq "-" , -and the file name. -When used with the -.Fl r -option, -.Nm -displays the description as above, but the initial letter is an -.Dq a -if the file is added to the archive, or an -.Dr r -if the file replaces a file already in the archive. -When used with the -.Fl p -option, the name of the file enclosed in -.Dq < -and -.Dq > -characters is written to standard output preceded by a single newline -character and followed by two newline characters. -The contents of the named file follow the file name. -When used with the -.Fl t -option, -.Nm -displays eight whitespace separated fields: -the file permissions as displayed by -.Xr strmode 3 , -decimal user and group IDs separated by a slash ( -.Dq / Ns ) , -the file size in bytes, the file modification time in -.Xr strftime 3 -format -.Dq "%b %e %H:%M %Y" , -and the name of the file. -.It Fl x -Extract archive members specified by arguments -.Ar files ... -into the current directory. -If no members have been specified, extract all members of the archive. -If the file corresponding to an extracted member does not exist it -will be created. -If the file corresponding to an extracted member does exist, its owner -and group will not be changed while its contents will be overwritten -and its permissions will set to that entered in the archive. -The file's access and modification time would be that of the time -of extraction unless the -.Fl o -option was specified. -.It Fl z -Compress the resulting archive with -.Xr gzip 1 . -.El -.Sh EXAMPLES -To create a new archive -.Pa ex.a -containing three files -.Pa ex1.o , -.Pa ex2.o -and -.Pa ex3.o , -use: -.Dl "ar -rc ex.a ex1.o ex2.o ex3.o" -.Pp -To add an archive symbol table to an existing archive -.Pa ex.a , -use: -.Dl "ar -s ex.a" -.Pp -To delete file -.Pa ex1.o -from archive -.Pa ex.a , -use: -.D1 "ar -d ex.a ex1.o" -.Pp -To verbosely list the contents of archive -.Pa ex.a , -use: -.D1 "ar -tv ex.a" -.Sh DIAGNOSTICS -.Ex -std -.Sh SEE ALSO -.Xr ld 1 , -.Xr archive 3 , -.Xr elf 3 , -.Xr strftime 3 , -.Xr strmode 3 , -.Xr ar 5 -.\" .Sh COMPATIBILITY -.\" .Nm -.\" is expected to be compatible with GNU and SVR4 -.\" .Nm . -.\" .Sh STANDARDS -.\" Do the POSIX/SuSv3 standards have anything to say about AR(1)? -.Sh HISTORY -An -.Nm -command first appeared in AT&T UNIX Version 1. -In -.Fx 8 , -.An "Kai Wang" Aq kaiw@FreeBSD.org -reimplemented -.Nm ar -and -.Nm ranlib -using the -.Lb libarchive -and the -.Lb libelf . Index: usr.bin/ar/bsdar.1 =================================================================== RCS file: usr.bin/ar/bsdar.1 diff -N usr.bin/ar/bsdar.1 --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ usr.bin/ar/bsdar.1 22 Feb 2008 07:03:09 -0000 @@ -0,0 +1,406 @@ +.\" Copyright (c) 2007 Joseph Koshy. 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 Joseph Koshy ``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 Joseph Koshy 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. +.\" +.\" $FreeBSD$ +.\" +.Dd August 31, 2007 +.Os +.Dt AR 1 +.Sh NAME +.Nm ar , +.Nm ranlib +.Nd manage archives +.Sh SYNOPSIS +.Nm +.Fl d +.Op Fl T +.Op Fl j +.Op Fl v +.Op Fl z +.Ar archive +.Ar files ... +.Nm +.Fl m +.Op Fl T +.Op Fl a Ar position-after +.Op Fl b Ar position-before +.Op Fl i Ar position-before +.Op Fl j +.Op Fl s +.Op Fl z +.Ar archive +.Ar files ... +.Nm +.Fl p +.Op Fl T +.Op Fl v +.Ar archive +.Op Ar files ... +.Nm +.Fl r +.Op Fl T +.Op Fl a Ar position-after +.Op Fl b Ar position-before +.Op Fl c +.Op Fl i Ar position-before +.Op Fl j +.Op Fl s +.Op Fl u +.Op Fl v +.Op Fl z +.Ar archive +.Ar files ... +.Nm +.Fl s +.Op Fl j +.Op Fl z +.Ar archive +.Nm +.Fl t +.Op Fl T +.Op Fl v +.Ar archive +.Op Ar files ... +.Nm +.Fl x +.Op Fl C +.Op Fl T +.Op Fl o +.Op Fl u +.Op Fl v +.Ar archive +.Op Ar files ... +.Nm ranlib +.Ar archive ... +.Sh DESCRIPTION +The +.Nm +utility creates and maintains groups of files combined into an +archive. +Once an archive has been created, new files can be added to it, and +existing files can be extracted, deleted or replaced. +.Pp +Files are named in the archive by their last file name component, +so if a file referenced by a path containing a +.Dq / +is archived, it will be named by the last component of the path. +Similarly when matching paths listed on the command line against +file names stored in the archive, only the last component of the +path will be compared. +.Pp +The normal use of +.Nm +is for the creation and maintenance of libraries suitable for use +with the link editor +.Xr ld 1 , +although it is not restricted to this purpose. +The +.Nm +utility can create and manage an archive symbol table (see +.Xr ar 5 ) +used to speed up link editing operations. +If a symbol table is present in an archive, it will be +kept upto-date by subsequent operations on the archive (excepting +the quick update specified by the +.Fl q +option). +.Pp +The +.Nm ranlib +utility is used to add an archive symbol table +to an existing archive. +.Sh OPTIONS +The +.Nm +utility supports the following options: +.Bl -tag -width indent +.It Fl a Ar member-after +When used with option +.Fl m +this option specifies that the archive members specified by +arguments +.Ar files ... +are moved to after the archive member named by argument +.Ar member-after . +When used with option +.Fl r +this option specifies that the files specified by arguments +.Ar files ... +are added after the archive member named by argument +.Ar member-after . +.It Fl b Ar member-before +When used with option +.Fl m +this option specifies that the archive members specified by +arguments +.Ar files ... +are moved to before the archive member named by argument +.Ar member-before . +When used with option +.Fl r +this option specifies that the files specified by arguments +.Ar files ... +are added before the archive member named by argument +.Ar member-before . +.It Fl c +Suppress the informational message printed when a new archive is +created using the +.Fl r +and +.Fl q +options. +.It Fl C +Prevent extracted files from replacing like-named files +in the file system. +.It Fl d +Delete the members named by arguments +.Ar files ... +from the archive specified by argument +.Ar archive . +The archive's symbol table, if present, is updated to reflect +the new contents of the archive. +.It Fl f +Synonymous with option +.Fl T . +.It Fl i Ar member-before +Synonymous with option +.Fl b . +.It Fl j +Compress the resulting archive with +.Xr bzip2 1 . +.It Fl m +Move archive members specified by arguments +.Ar files ... +within the archive. +If a position has been specified by one of the +.Fl a , +.Fl b +or +.Fl i +options, the members are moved to before or after the specified +position. +If no position has been specified, the specified members are moved +to the end of the archive. +If the archive has a symbol table, it is updated to reflect the +new contents of the archive. +.It Fl o +Preserve the original modification times of members when extracting +them. +.It Fl p +Write the contents of the specified archive members named by +arguments +.Ar files ... +to standard output. +If no members were specified, the contents of all the files in the +archive are written in the order they appear in the archive. +.It Fl q +Append the files specified by arguments +.Ar files ... +to the archive specified by argument +.Ar archive +without checking if the files already exist in the archive and +without updating the archive's symbol table. +If the archive file +.Ar archive +does not already exist, a new archive is created. +However, to be compatible with GNU +.Nm , +.Fl q +is implemented as a synonym for +.Fl r . +.It Fl r +Replace (add) the files specified by arguments +.Ar files ... +in the archive specified by argument +.Ar archive , +creating the archive if necessary. +Files that replace existing files do not change the order of files +within the archive. +If a file named in arguments +.Ar files ... +does not exist, existing members in the archive that match that +name are not changed. +New files are added to the end of the archive unless one of the +positioning options +.Fl a , +.Fl b +or +.Fl i +is specified. +The archive symbol table, if it exists, is updated to reflect the +new state of the archive. +.It Fl s +Add an archive symbol table (see +.Xr ar 5 ) +to the archive specified by argument +.Ar archive . +Invoking +.Nm +with the +.Fl s +option alone is equivalent to invoking +.Nm ranlib . +.It Fl t +List the files specified by arguments +.Ar files ... +in the order in which they appear in the archive, one per line. +If no files are specified, all files in the archive are listed. +.It Fl T +Use only the first fifteen characters of the archive member name or +command line file name argument when naming archive members. +.It Fl u +Conditionally update the archive or extract members. +When used with the +.Fl r +option, files named by arguments +.Ar files ... +will be replaced in the archive if they are newer than their +archived versions. +When used with the +.Fl x +option, the members specified by arguments +.Ar files ... +will be extracted only if they are newer than the corresponding +files in the file system. +.It Fl v +Provide verbose output. +When used with the +.Fl d , +.Fl m , +.Fl q +or +.Fl x +options, +.Nm +gives a file-by-file description of the archive modification being +performed, which consists of three white-space seperated fields: +the option letter, a dash +.Dq "-" , +and the file name. +When used with the +.Fl r +option, +.Nm +displays the description as above, but the initial letter is an +.Dq a +if the file is added to the archive, or an +.Dq r +if the file replaces a file already in the archive. +When used with the +.Fl p +option, the name of the file enclosed in +.Dq < +and +.Dq > +characters is written to standard output preceded by a single newline +character and followed by two newline characters. +The contents of the named file follow the file name. +When used with the +.Fl t +option, +.Nm +displays eight whitespace separated fields: +the file permissions as displayed by +.Xr strmode 3 , +decimal user and group IDs separated by a slash ( +.Dq / Ns ) , +the file size in bytes, the file modification time in +.Xr strftime 3 +format +.Dq "%b %e %H:%M %Y" , +and the name of the file. +.It Fl x +Extract archive members specified by arguments +.Ar files ... +into the current directory. +If no members have been specified, extract all members of the archive. +If the file corresponding to an extracted member does not exist it +will be created. +If the file corresponding to an extracted member does exist, its owner +and group will not be changed while its contents will be overwritten +and its permissions will set to that entered in the archive. +The file's access and modification time would be that of the time +of extraction unless the +.Fl o +option was specified. +.It Fl z +Compress the resulting archive with +.Xr gzip 1 . +.El +.Sh EXAMPLES +To create a new archive +.Pa ex.a +containing three files +.Pa ex1.o , +.Pa ex2.o +and +.Pa ex3.o , +use: +.Dl "ar -rc ex.a ex1.o ex2.o ex3.o" +.Pp +To add an archive symbol table to an existing archive +.Pa ex.a , +use: +.Dl "ar -s ex.a" +.Pp +To delete file +.Pa ex1.o +from archive +.Pa ex.a , +use: +.D1 "ar -d ex.a ex1.o" +.Pp +To verbosely list the contents of archive +.Pa ex.a , +use: +.D1 "ar -tv ex.a" +.Sh DIAGNOSTICS +.Ex -std +.Sh SEE ALSO +.Xr ld 1 , +.Xr archive 3 , +.Xr elf 3 , +.Xr strftime 3 , +.Xr strmode 3 , +.Xr ar 5 +.\" .Sh COMPATIBILITY +.\" .Nm +.\" is expected to be compatible with GNU and SVR4 +.\" .Nm . +.\" .Sh STANDARDS +.\" Do the POSIX/SuSv3 standards have anything to say about AR(1)? +.Sh HISTORY +An +.Nm +command first appeared in AT&T UNIX Version 1. +In +.Fx 8.0 , +.An "Kai Wang" Aq kaiw@FreeBSD.org +reimplemented +.Nm +and +.Nm ranlib +using the +.Lb libarchive +and the +.Lb libelf . --JYK4vJDZwFMowpUq-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:37:06 2008 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 DE02416A400 for ; Fri, 22 Feb 2008 09:37:06 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout4-sn1.fre.skanova.net (pne-smtpout4-sn1.fre.skanova.net [81.228.11.168]) by mx1.freebsd.org (Postfix) with ESMTP id 80CE013C502 for ; Fri, 22 Feb 2008 09:37:06 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from chaos.nox (80.221.12.61) by pne-smtpout4-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A7970A000F6F00; Fri, 22 Feb 2008 10:37:05 +0100 Date: Fri, 22 Feb 2008 11:36:46 +0200 From: Mikael Ikivesi To: freebsd-current , des@des.no, svein-listmail@d80.iso100.no Message-ID: <20080222113646.2dbb9ec1@chaos.nox> In-Reply-To: <47BDB92C.9050808@d80.iso100.no> References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: 2 core dumps 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, 22 Feb 2008 09:37:07 -0000 On Thu, 21 Feb 2008 18:40:36 +0100 Dag-Erling Sm=F8rgrav wrote: > Mikael Ikivesi writes: > I agree with Kris, it looks like hardware trouble. Are you sure your > laptop is not overheating? Does it run powerd? Are the fans or > exhaust louvers blocked? >=20 > Have you tried booting without X and running 'make -j8 buildworld' or > something similar? >=20 > DES I have checked for overheating as it was my first quess but the answer is no. And these dumps happened without powerd. I only manually enable 1800Mhz sometimes if I need extra speed. It seems to be highest sustainable speed for this machine. Powerd heats this laptop too much without manually setting _PSV value to much lower. And the result would be the same 1800Mhz. When I build world the system with 800Mhz temperature stays between 44-52C. I have successfully built world and lot of ports without problems. These dumps are rare. I have only had 3 of them. (don't have 1st coredump anymore, happened while building hplip..) As these dont happen very often it is hard to test with or without X. I am not sure, but if I remember correctly the first happened without X, but my memory might fail me here.. On Thu, 21 Feb 2008 18:47:24 +0100 Svein Skogen wrote: > Could you add the following extra info (in case this is more than an=20 > isolated hardware failure): >=20 > Your /var/run/dmesg.boot >=20 > Laptop make & model, and (if any) docking station used. And got no docking. -mikael Here is the info you asked: -------------/var/run/dmesg.boot----------------------- Copyright (c) 1992-2008 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 7.0-PRERELEASE #1: Fri Feb 15 12:25:21 EET 2008 root@localhost:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile AMD Athlon(tm) 64 Processor 3700+ (800.00-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x20f42 Stepping =3D 2 Features=3D0x78bfbff Features2=3D0x1 AMD Features=3D0xe2500800 AMD Features2=3D0x1 real memory =3D 938082304 (894 MB) avail memory =3D 908603392 (866 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 netsmb_dev: loaded acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, 1000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 powernow0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xc8000000-0xcfffffff,0xc0100000-0xc010ffff irq 17 at device 5.0 on pci1 ohci0: mem 0xc0000000-0xc0000fff irq 19 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered ehci0: mem 0xc0002000-0xc0002fff irq 19 at device 19.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 8 ports with 8 removable, self powered pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8410-0x841f irq 16 at device 20.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 pci2: at device 5.0 (no driver attached) rl0: port 0xa000-0xa0ff mem 0xc0208000-0xc02080ff irq 23 at device 7.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0a:e4:ac:90:fa rl0: [ITHREAD] cbb0: at device 9.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] pci2: at device 9.2 (no driver attached) pci2: at device 9.3 (no driver attached) pcm0: mem 0xc0003400-0xc00034ff irq 17 at device 20.5 on pci0 pcm0: [ITHREAD] pci0: at device 20.6 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x2000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Synaptics Touchpad, device ID 0 acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE battery0: on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xc3941300), AE_NO_HARDWARE_RESPONSE acpi_acad0: on acpi0 cryptosoft0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xdc000-0xdffff pnpid ORM0000 on isa0 ROMs> sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual ROMs> consoles, flags=3D0x300> sio0: configured irq 4 not in bitmap of ROMs> probed irqs 0 sio0: port may not be enabled sio0: configured irq ROMs> 4 not in bitmap of probed irqs 0 sio0: port may not be enabled ROMs> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 ROMs> or not responding sio0: [FILTER] sio1: configured irq 3 not in ROMs> bitmap of probed irqs 0 sio1: port may not be enabled vga0: ROMs> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on ROMs> isa0 SGI XFS with large block numbers, tracing, no debug enabled ROMs> Timecounter "TSC" frequency 800004707 Hz quality 800 Timecounters ROMs> tick every 1.000 msec Fast IPsec: Initialized Security ROMs> Association Processing. ncp_load: loaded ad0: 76319MB MHT2080AT 0022> at ata0-master UDMA100 acd0: DVDR DVD-RW GWA-4082N/CW02> at ata1-master UDMA33 pcm0: ALC655 AC97 Codec> GEOM_LABEL: Label for provider ad0s3 is ROMs> ext2fs/Linux. Trying to mount root from ufs:/dev/ad0s1a acd0: ROMs> FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 ROMs> 0x00 0x01 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present -------Copy pasted pieces from dmidecode------------- Handle 0x0000, DMI type 0, 20 bytes BIOS Information Vendor: Phoenix =20 Version: R01-A1E =20 Release Date: 06/21/2005 Address: 0xE8B50 Runtime Size: 95408 bytes ROM Size: 512 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available ACPI is supported USB legacy is supported Smart battery is supported BIOS boot specification is supported Handle 0x0001, DMI type 1, 25 bytes System Information Manufacturer: FUJITSU SIEMENS Product Name: AMILO A1650G Version: -1 =20 Wake-up Type: Power Switch Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: FUJITSU SIEMENS Product Name: AMILO A1650G Version: Rev.A =20 Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: N/A =20 Type: Notebook Lock: Not Present Version: N/A Serial Number: None Asset Tag: =20 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Handle 0x0004, DMI type 4, 32 bytes Processor Information Socket Designation: Socket 754 Type: Central Processor Family: Athlon 64 Manufacturer: AMD ID: 42 0F 02 00 FF FB 8B 07 Signature: Family 15, Model 36, Stepping 2 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) Version: C0 Voltage: 3.3 V External Clock: 800 MHz Max Speed: 2500 MHz Current Speed: 800 MHz Status: Populated, Enabled Upgrade: Socket 754 L1 Cache Handle: 0x0008 L2 Cache Handle: 0x0009 L3 Cache Handle: Not Provided ----------------------------- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:44:22 2008 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 BB2F816A409; Fri, 22 Feb 2008 09:44:22 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6BFD413C4CC; Fri, 22 Feb 2008 09:44:21 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=62625 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSUS3-0008yF-Ia; Fri, 22 Feb 2008 09:44:19 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1M9iIJm025087; Fri, 22 Feb 2008 12:44:18 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1M9iIOT025017; Fri, 22 Feb 2008 12:44:18 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 12:44:17 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org Message-ID: <20080222094416.GC57428@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222092713.GA17107@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222092713.GA17107@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 09:44:22 -0000 On Fri, Feb 22, 2008 at 01:27:13AM -0800, David O'Brien wrote: > On Fri, Feb 22, 2008 at 12:16:42PM +0300, Ruslan Ermilov wrote: > > RCS file: /home/ncvs/src/usr.bin/Makefile,v > .. > > - ar \ > > + ${_ar} \ > .. > > .if ${MK_TOOLCHAIN} != "no" > > +_ar= ar > > Please commit now - I should have done it this way. > Done. > > RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v > .. > > -.if defined(WITH_BSDAR) > > -PROG= ar > > -.else > > PROG= bsdar > > -.endif > > +LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib > > +MLINKS= bsdar.1 bsdranlib.1 > > LINKS and MLINKS don't belong here in a Makefile - they are better > located where I have them. > The only difference is that I prefer the "product order", while you seem to prefer the "build order". :-) Our versions don't match any of the documented orders in style.Makefile(5) because the conditional block is misplaced. If I move the conditional block from after the first set of links, the order will fully match "product order". I also had a no-op ".else" clause in my patch -- the result of the conflict resolution with your changes. Now it looks like this: : # $FreeBSD: src/usr.bin/ar/Makefile,v 1.19 2008/02/22 06:53:52 obrien Exp $ : : PROG= bsdar : LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib : MLINKS= bsdar.1 bsdranlib.1 : : .if !defined(WITH_GNUAR) : NO_SHARED?= yes : LINKS+= ${BINDIR}/bsdar ${BINDIR}/ar : MLINKS+= bsdar.1 ar.1 : LINKS+= ${BINDIR}/bsdranlib ${BINDIR}/ranlib : MLINKS+= bsdranlib.1 ranlib.1 : .endif : : SRCS= ar.c read.c util.c write.c : : WARNS?= 5 : : DPADD= ${LIBARCHIVE} ${LIBBZ2} ${LIBZ} ${LIBELF} : LDADD= -larchive -lbz2 -lz -lelf : : .include > > -NO_SHARED?= yes > > It looks like you're totally removing the NO_SHARED setting, or do you > still have it set when BSD-ar is the default 'ar'? > I think you misread my patch. It's still built statically when it's the default system ar(1), exactly as you programmed it. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:47:27 2008 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 7486216A40F; Fri, 22 Feb 2008 09:47:27 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3B113C4D1; Fri, 22 Feb 2008 09:47:27 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1M9RDGR022649; Fri, 22 Feb 2008 01:27:13 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1M9RDjl022648; Fri, 22 Feb 2008 01:27:13 -0800 (PST) (envelope-from obrien) Date: Fri, 22 Feb 2008 01:27:13 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080222092713.GA17107@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@FreeBSD.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222091642.GB57428@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Joseph Koshy , Kai Wang , "Dag-Erling C. Smorgrav" , current@FreeBSD.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 22 Feb 2008 09:47:27 -0000 On Fri, Feb 22, 2008 at 12:16:42PM +0300, Ruslan Ermilov wrote: > RCS file: /home/ncvs/src/usr.bin/Makefile,v .. > - ar \ > + ${_ar} \ .. > .if ${MK_TOOLCHAIN} != "no" > +_ar= ar Please commit now - I should have done it this way. > RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v .. > -.if defined(WITH_BSDAR) > -PROG= ar > -.else > PROG= bsdar > -.endif > +LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib > +MLINKS= bsdar.1 bsdranlib.1 LINKS and MLINKS don't belong here in a Makefile - they are better located where I have them. > -NO_SHARED?= yes It looks like you're totally removing the NO_SHARED setting, or do you still have it set when BSD-ar is the default 'ar'? From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:47:27 2008 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 BF58B16A413; Fri, 22 Feb 2008 09:47:27 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 85BFB13C4D9; Fri, 22 Feb 2008 09:47:27 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1M9WYZX022821; Fri, 22 Feb 2008 01:32:34 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1M9WY8Y022820; Fri, 22 Feb 2008 01:32:34 -0800 (PST) (envelope-from obrien) Date: Fri, 22 Feb 2008 01:32:34 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080222093234.GB17107@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@FreeBSD.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222091642.GB57428@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Joseph Koshy , Kai Wang , "Dag-Erling C. Smorgrav" , current@FreeBSD.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 22 Feb 2008 09:47:27 -0000 On Fri, Feb 22, 2008 at 12:16:42PM +0300, Ruslan Ermilov wrote: > Here's the promised patch. What it does: > - Switch again to using BSD ar(1) by default, but provide a knob > to use GNU ar(1) as the system ar(1). (Option WITH_BSDAR is > replaced with option WITH_GNUAR.) > > - Install BSD ar(1) as bsdar(1) with the necessary links: > bsdranlib(1), ar(1), and ranlib(1) (the latter two unless we > build WITH_GNUAR). .. > - ar.1 moved to bsdar.1 along with some bugfixing. I don't quite follow what you want the end state to be. If it is to quickly convert to the new BSDLed ar & ranlib, then I don't care for the "creatation" of a bsdar binary and manpage (below you delete src/usr.bin/ar/ar.1 and create bsdar.1). The FreeBSD 8 official 'ar' should have its man page named "ar.1" - I don't see what is gained otherwise. bsdtar could be mentioned as an example where we went this path - but I think bsdtar (and associated libarchive) has a large life outside of FreeBSD. I really see that for 'ar'. > - Handle upgrades nicely: use GNU ar(1) during the build on older > systems, and use BSD ar(1) on newer systems. If we need GNU ar for the upgrade path - then lets just install it (and its manage) as gnu-ar and let that be that. > Please review. You asked... 8-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:47:53 2008 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 082E416A400 for ; Fri, 22 Feb 2008 09:47:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by mx1.freebsd.org (Postfix) with ESMTP id 94D8F13C4EF for ; Fri, 22 Feb 2008 09:47:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so319133ele.3 for ; Fri, 22 Feb 2008 01:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=TDNdr5wikzJka4OV+lsrPt5++cb/I/7pL+1olUIfb2o=; b=WTuFBd7ajLy3GQjqDQirWzCRKcUGVC9ve2S7M/aiipEXkHkDx5N0LePHoyNiR8vFMzQ65kXrL0KCVe16PT/LZamMZ3o6qLPqwB7t3wj8wQtChMT6wuYjfiVlvROlklJASnLIqimjdL5aWiBLPAWio3gCJC3vKNzkecs122n7xrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=W+6AU46EYh3n3evGE/fU54lrolRf+boZC9Rdh0hB2PscdKIfmi47m7fPYQEbMaUBGpMfOasyI93dHF6Rnqjdw75lAvs6bRiHB2+SI8FHU4juw/OO03OMKBLO/9/5QkjJLipf8kMuf9Dg2C1DODPJlE99tle5/MOSY1i68s6HEXc= Received: by 10.142.104.9 with SMTP id b9mr8509894wfc.48.1203673670285; Fri, 22 Feb 2008 01:47:50 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 20sm1994111wfi.14.2008.02.22.01.47.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 01:47:49 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1M9lhdE032344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 18:47:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1M9lhm7032343; Fri, 22 Feb 2008 18:47:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 18:47:42 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20080222094742.GF30497@cdnetworks.co.kr> References: <20080222042700.GB30497@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 09:47:53 -0000 On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > > Pyun YongHyeon wrote: > > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wr > ote: > > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > > > > I am experiencing roughly 15% packet corruption on the re inter > face > > > on > > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEA > SE #8 > > > : > > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > > > Just to make troubleshooting difficult, this problem only shows > up > > > > > > > after the system has been up for roughly 36 hours, depending on > the > > > > > > > amount of traffic. > > > > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > > I'll handle it in a week. > > > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." se > ems a > > > > > bit drastic, and I don't do much with cvs proper. I take it that I sh > ould > > > use > > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > > It basically shows up as quagga establishing OSPF neighours as > > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > > VLAN hardware tagging is disabled on the interface. > > > > > > I'll do more debugging. > > > > > > > Hmm. That sounds like different issue to me. I guess I din't change > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > > tagging related issues on RELENG_7? > > > > To narrow down the issue it would be even better to know which parts > > of H/W assistance was broken. For example, > > - Disable checksum offload for VLAN interface first and check > > whether quagga works. > > You can only disable offload on the parent interface. > Hmm... I thought it should work. I have no idea why ioctl handler of vlan(4) rejects checksum offload configutation. I guess vlan(4) should be teached to handle this. If parent interface have IFCAP_VLAN_HWCSUM capability and IFCAP_VLAN_HWTAGGING, ifconfig(4) should be able to control checksum offload for vlan(4) interface. CCed to yar to get his opinions on controlling checksum offload on vlan(4). > > - Disable checksum offload for parent interface and check again. > > If you can post tcpdump output for broken conntection it may help a > > lot to diagnose the issue. > > The only flag affecting this behaviour is vlanhwtag. Various > permutations of the interface flags make no difference to this > behaviour as long as hardware tagging is enabled. > Disabling VLAN HW tagging also turns off checksum offload on vlan(4) interface. > It seems like it's corrupting large packets on transmit when vlanhwtag > is enabled. From the tcpdump output it looks like a padding or > packet length issue. > > Here's what tcpdump on the re(4) device thinks it's transmitting: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > Here's what was actually recieved by the em(4) device on the > neighbour. Note the absense of the 801.1Q header: > I see, I'll check it. > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype IPv4 (0x0800), length 1506: 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > When vlanhwtagging is disabled, the re(4) device transmits: > > 00:90:fb:0c:89:7d > 00:08:a1:3c:32:9c, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.89 > 196.22.138.92: OSPFv2, Database Description, length: 1472 > > and the em(4) device recieves: > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > Let me know if you need more detailed tcpdump output than I've provided. > > Ian > > -- > Ian Freislich > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:01:06 2008 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 0C6DD16A409 for ; Fri, 22 Feb 2008 10:01:06 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id C451B13C474 for ; Fri, 22 Feb 2008 10:01:05 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from [10.100.147.125] (opera.isdefe.es [194.15.213.193]) by mail1.isdefe.es (Postfix) with ESMTP id 033835C36; Fri, 22 Feb 2008 10:42:41 +0100 (CET) Message-ID: <47BE9910.7030501@pop.isdefe.es> Date: Fri, 22 Feb 2008 10:42:40 +0100 From: Raul User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christoph Schug References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <20080221143748.GE10726@lega.schug.net> In-Reply-To: <20080221143748.GE10726@lega.schug.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Pyun YongHyeon , FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 (and em0 too) 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, 22 Feb 2008 10:01:06 -0000 First of all, it's my first post here ... Thanks to everybody that made FreeBSD possible. Christoph Schug escribió: > I am having the very same problem on a rented Hetzner DS8000 root Sorry to say, I think that 'me too' My re0 comes with the motherboard, a Gigabyte GA-MA69G-S3H (AMD 690G chipset). I've tried yesterday with RELENG_7_0 (RC3) and RELENG_7, same behavior on both. I've returned to RELENG_7_0 and plug an em0 but, in my case, the same behavior happens. I left the box by night compiling CURRENT and this morning I've run my 'stress tests' (once again with re0) ... the box break to gdb as far I remember (too sleepy, sorry). Well, at least no garbage over the link BD. The fastest method I found to reproduce the problem is receive a compresed tar (with good compression ratio) over the network (using nc, 100 Mbps fdx), pipe through tar that decompress and write it on disk (a lot of MB/s and tps looking at 'systat -vm'). The source tar file is about 5Gb and link always fails before EOF :|. The em0 is brand new so no idea if it works right. It would be the first one that fail to me (great stuff intel ;) ... I'm pretty confident about the switch and allow setting flow control, duplex negotiation, dot1q and so on. I'll be glad to test whatever you suggest on that box. Regards, Raul From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:08:52 2008 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 426B016A402; Fri, 22 Feb 2008 10:08:52 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC6013C474; Fri, 22 Feb 2008 10:08:52 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id m1MA8pgI023965; Fri, 22 Feb 2008 02:08:51 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m1MA8pZn023964; Fri, 22 Feb 2008 02:08:51 -0800 (PST) (envelope-from obrien) Date: Fri, 22 Feb 2008 02:08:51 -0800 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20080222100851.GA23756@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222092713.GA17107@dragon.NUXI.org> <20080222094416.GC57428@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222094416.GC57428@team.vega.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Joseph Koshy , Kai Wang , "Dag-Erling C. Smorgrav" , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@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: Fri, 22 Feb 2008 10:08:52 -0000 On Fri, Feb 22, 2008 at 12:44:17PM +0300, Ruslan Ermilov wrote: > On Fri, Feb 22, 2008 at 01:27:13AM -0800, David O'Brien wrote: > > On Fri, Feb 22, 2008 at 12:16:42PM +0300, Ruslan Ermilov wrote: > > LINKS and MLINKS don't belong here in a Makefile - they are better > > located where I have them. > > The only difference is that I prefer the "product order", > while you seem to prefer the "build order". :-) Ah, yes - very true. > order". I also had a no-op ".else" clause in my patch -- > the result of the conflict resolution with your changes. > Now it looks like this: Removing the ".else" does help. > > > -NO_SHARED?= yes > > > > It looks like you're totally removing the NO_SHARED setting, or do you > > still have it set when BSD-ar is the default 'ar'? > > I think you misread my patch. I had. So my NO_SHARED concern is taken care of. I hope you'll still answer the other email I sent about the "larger picture". -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:20:35 2008 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 3526016A408 for ; Fri, 22 Feb 2008 10:20:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 05D9D13C459 for ; Fri, 22 Feb 2008 10:20:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so212254wfa.7 for ; Fri, 22 Feb 2008 02:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=hY8GYL4Q1Y9HeXI1he4ZoDpKW5rIyxlC0ttpxWwfSqM=; b=xbcNLrrcRADS1lMBzzh/di62YjiprxRUvEMhpRf5Y4Mf8PFljyK+28SzZkG8Q3lfWgPM/ct1MnJP7DCtzRJqmmBMgK8IlGag8sNj7QG+vObDp6p1lwM3o7qpeQtpUb54zNJQkN/CRd5usBxjfgEFswLv3yk+C/Sza6pUBnIUAks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=vQDfYrOgj0f4DIWjvYqusU8aW4Wdu79ioFXLd1C9ucskcf8+iCvVnVnov3E09jBOb6b7rqnPco+i5cjOMO/CLJFaG9eGoIIX2q8JWsyFaXe3c1lVcZSyqVGbD+YkpSTHpO4MfeVbq+9vBuiLvu91CKQnworLyaJEQOnZJ1WmXRg= Received: by 10.142.158.17 with SMTP id g17mr8518594wfe.127.1203675634666; Fri, 22 Feb 2008 02:20:34 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 22sm2076237wfi.12.2008.02.22.02.20.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 02:20:33 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1MAKRGq032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 19:20:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1MAKQM5032536; Fri, 22 Feb 2008 19:20:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 22 Feb 2008 19:20:26 +0900 From: Pyun YongHyeon To: Ian FREISLICH Message-ID: <20080222102026.GH30497@cdnetworks.co.kr> References: <20080222042700.GB30497@cdnetworks.co.kr> <20080222094742.GF30497@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <20080222094742.GF30497@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 10:20:35 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 22, 2008 at 06:47:42PM +0900, To Ian FREISLICH wrote: [...] > > It seems like it's corrupting large packets on transmit when vlanhwtag > > is enabled. From the tcpdump output it looks like a padding or > > packet length issue. > > > > Here's what tcpdump on the re(4) device thinks it's transmitting: > > > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > > > Here's what was actually recieved by the em(4) device on the > > neighbour. Note the absense of the 801.1Q header: > > > > I see, I'll check it. > > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype IPv4 (0x0800), length 1506: 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > > > When vlanhwtagging is disabled, the re(4) device transmits: > > > > 00:90:fb:0c:89:7d > 00:08:a1:3c:32:9c, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.89 > 196.22.138.92: OSPFv2, Database Description, length: 1472 > > > > and the em(4) device recieves: > > > > 00:08:a1:3c:32:9c > 00:90:fb:0c:89:7d, ethertype 802.1Q (0x8100), length 1510: vlan 1000, p 0, ethertype IPv4, 196.22.138.92 > 196.22.138.89: OSPFv2, Database Description, length: 1472 > > > > Let me know if you need more detailed tcpdump output than I've provided. > > Apply attached patch and let me know how it goes. It just disables checksum offload for vlan interface. -- Regards, Pyun YongHyeon --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.vcsum.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.103 diff -u -r1.103 if_re.c --- if_re.c 17 Jan 2008 23:37:47 -0000 1.103 +++ if_re.c 22 Feb 2008 10:16:26 -0000 @@ -1332,8 +1332,10 @@ /* VLAN capability setup */ ifp->if_capabilities |= IFCAP_VLAN_MTU | IFCAP_VLAN_HWTAGGING; +#if 0 if (ifp->if_capabilities & IFCAP_HWCSUM) ifp->if_capabilities |= IFCAP_VLAN_HWCSUM; +#endif ifp->if_capenable = ifp->if_capabilities; #ifdef DEVICE_POLLING ifp->if_capabilities |= IFCAP_POLLING; --vGgW1X5XWziG23Ko-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:24:13 2008 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 2053B16A405; Fri, 22 Feb 2008 10:24:13 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id C654A13C474; Fri, 22 Feb 2008 10:24:11 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=60019 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSV4c-000BEm-Mg; Fri, 22 Feb 2008 10:24:10 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1MAO9aW094152; Fri, 22 Feb 2008 13:24:09 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1MAO95H094151; Fri, 22 Feb 2008 13:24:09 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 13:24:09 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org Message-ID: <20080222102409.GD57428@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222093234.GB17107@dragon.NUXI.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 10:24:13 -0000 On Fri, Feb 22, 2008 at 01:32:34AM -0800, David O'Brien wrote: > On Fri, Feb 22, 2008 at 12:16:42PM +0300, Ruslan Ermilov wrote: > > Here's the promised patch. What it does: > > - Switch again to using BSD ar(1) by default, but provide a knob > > to use GNU ar(1) as the system ar(1). (Option WITH_BSDAR is > > replaced with option WITH_GNUAR.) > > > > - Install BSD ar(1) as bsdar(1) with the necessary links: > > bsdranlib(1), ar(1), and ranlib(1) (the latter two unless we > > build WITH_GNUAR). > .. > > - ar.1 moved to bsdar.1 along with some bugfixing. > > I don't quite follow what you want the end state to be. If it is to > quickly convert to the new BSDLed ar & ranlib, then I don't care for the > "creatation" of a bsdar binary and manpage (below you delete > src/usr.bin/ar/ar.1 and create bsdar.1). The FreeBSD 8 official 'ar' > should have its man page named "ar.1" - I don't see what is gained > otherwise. bsdtar could be mentioned as an example where we went this > path - but I think bsdtar (and associated libarchive) has a large life > outside of FreeBSD. I really see that for 'ar'. > I don't mind reverting this. > > - Handle upgrades nicely: use GNU ar(1) during the build on older > > systems, and use BSD ar(1) on newer systems. > > If we need GNU ar for the upgrade path - then lets just install it (and > its manage) as gnu-ar and let that be that. > I don't get you, GNU ar(1) is always installed. Only the name is changes. But let me explain more about the upgrades. Currently, we always build binutils as part of cross-tools, including GNU ar(1) and ranlib(1). These binaries are then used during the build. The BSD ar(1) doesn't need to be a cross-tool -- it doesn't depend on TARGET_ARCH/TARGET and is platform-neutral. (I hope I'm right about it, otherwise it all doesn't make sense and cross-builds are broken.) We could just use /usr/bin/ar and don't bother bootstrapping it if we knew it's a BSD ar(1) without known bugs (determined by __FreeBSD_version). If it has compatibility issues or bugs, we can bootstrap it. Unfortunalely, since we provide the WITH_GNUAR option, we don't know if /usr/bin/ar and /usr/bin/ranlib are GNU or BSD versions, so we should always bootstrap BSD ar(1). The short version is as simple as this: You have You specified ar(1) used for builds =================== ======================= ===================== OS before bsdar WITH_GNUAR GNU ar OS before bsdar - GNU ar OS after bsdar WITH_GNUAR GNU ar OS after bsdar - BSD ar (*) (*) We need to bootstrap BSD ar(1) because we don't know if /usr/bin/ar is GNU ar(1) or BSD ar(1), and GNU ar(1) for one arch cannot be used to cross-build to a different arch. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:30:44 2008 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 A18A216A405 for ; Fri, 22 Feb 2008 10:30:44 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 7824513C45D for ; Fri, 22 Feb 2008 10:30:44 +0000 (UTC) (envelope-from mfl-commissioner@marino.st) Received: by shepard.synsport.net (Postfix, from userid 108) id 50144435EC; Fri, 22 Feb 2008 04:30:43 -0600 (CST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on shepard X-Spam-Level: X-Spam-Status: No, score=-4.4 required=6.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from secure.synsport.net (unknown [208.69.230.150]) by shepard.synsport.net (Postfix) with ESMTP id DA6C643578; Fri, 22 Feb 2008 04:30:42 -0600 (CST) Received: from 195.169.141.54 (SquirrelMail authenticated user marst2) by secure.synsport.net with HTTP; Fri, 22 Feb 2008 04:30:42 -0600 (CET) Message-ID: <24097.195.169.141.54.1203676242.squirrel@secure.synsport.net> In-Reply-To: <20080221213945.GA97273@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217231126.GA68779@saturn.kn-bremen.de> <51702.82.234.78.29.1203318499.squirrel@secure.synsport.net> <20080221213945.GA97273@saturn.kn-bremen.de> Date: Fri, 22 Feb 2008 04:30:42 -0600 (CET) From: "John Marino" To: "Juergen Lock" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 22 Feb 2008 10:30:44 -0000 Hi Juergen, If there is nobody capable of tracking down and fixing the problem, I suggest that the kqemu-mod port be marked as i386 only, to prevent people with systems like mine from installing it in the first place. It appears that it is completely unusable for AMD64. I'm happy to continue to assist and offer up my machine to help identify the problem(s) though, if the qemu/freebsd community doesn't want to give up yet. Regards, John > > Another bad crash that doesn't tell me whats wrong... I guess this > is a lost cause. > Juergen > From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:36:44 2008 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 73C4A16A407 for ; Fri, 22 Feb 2008 10:36:44 +0000 (UTC) (envelope-from cs@legacy.schug.net) Received: from legacy.schug.net (legacy.schug.Net [194.97.148.165]) by mx1.freebsd.org (Postfix) with ESMTP id 35F7D13C474 for ; Fri, 22 Feb 2008 10:36:43 +0000 (UTC) (envelope-from cs@legacy.schug.net) Received: by legacy.schug.net (Postfix, from userid 10000) id AB92D10F664E; Fri, 22 Feb 2008 11:36:42 +0100 (CET) Date: Fri, 22 Feb 2008 11:36:42 +0100 From: Christoph Schug To: Raul Message-ID: <20080222103642.GB45806@lega.schug.net> References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <20080221143748.GE10726@lega.schug.net> <47BE9910.7030501@pop.isdefe.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BE9910.7030501@pop.isdefe.es> User-Agent: Mutt/1.5.13 OpenPKG/2-STABLE (2006-08-11) Cc: Pyun YongHyeon , FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 (and em0 too) 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, 22 Feb 2008 10:36:44 -0000 On Fri, Feb 22, 2008, Raul wrote: > The fastest method I found to reproduce the problem is receive a > compresed tar (with good compression ratio) over the network (using nc, > 100 Mbps fdx), pipe through tar that decompress and write it on disk (a > lot of MB/s and tps looking at 'systat -vm'). The source tar file is > about 5Gb and link always fails before EOF :|. I've just synced again against RELENG_7 and copied the drivers mentioned in this thread (thanks BTW!): http://people.freebsd.org/~yongari/re/7.0R/if_re.c http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h Up to now, no problems, but I certainly need more uptime to be sure. Maybe I can tell more later that day. -cs From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:48:10 2008 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 0321316A403; Fri, 22 Feb 2008 10:48:10 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B154513C455; Fri, 22 Feb 2008 10:48:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 996DD2084; Fri, 22 Feb 2008 11:48:06 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1E16F2049; Fri, 22 Feb 2008 11:48:06 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 05BB984499; Fri, 22 Feb 2008 11:48:06 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ruslan Ermilov References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> Date: Fri, 22 Feb 2008 11:48:05 +0100 In-Reply-To: <20080222091642.GB57428@team.vega.ru> (Ruslan Ermilov's message of "Fri\, 22 Feb 2008 12\:16\:42 +0300") Message-ID: <864pc1s1wa.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , Kai Wang , David O'Brien , current@FreeBSD.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 10:48:10 -0000 Ruslan Ermilov writes: > - Handle upgrades nicely: use GNU ar(1) during the build on older > systems, and use BSD ar(1) on newer systems. For now, always > bootstrap BSD ar(1) on newer systems during the build (in case > some bugs pop up), but after some period of testing, we can stop > unconditionally bootstrapping it. I would *really* like BSD ar to be used to build world regardless of host system version, at least on the tinderbox. Isn't it possible to use GNU ar just for the toolchain, then BSD ar for the "real" world? Doesn't adding ar to bootstrap-tools take care of that? Note that the tinderbox *always* cross-builds, even when building for the platform it runs on. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:52:42 2008 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 5AAC716A400; Fri, 22 Feb 2008 10:52:42 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD4313C43E; Fri, 22 Feb 2008 10:52:42 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=59796 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSVWD-00006N-2s; Fri, 22 Feb 2008 10:52:41 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1MAqdhc094964; Fri, 22 Feb 2008 13:52:39 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1MAqdVg094963; Fri, 22 Feb 2008 13:52:39 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 13:52:39 +0300 From: Ruslan Ermilov To: Dag-Erling Sm??rgrav Message-ID: <20080222105239.GC94607@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864pc1s1wa.fsf@ds4.des.no> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joseph Koshy , Kai Wang , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 10:52:42 -0000 On Fri, Feb 22, 2008 at 11:48:05AM +0100, Dag-Erling Sm??rgrav wrote: > Ruslan Ermilov writes: > > - Handle upgrades nicely: use GNU ar(1) during the build on older > > systems, and use BSD ar(1) on newer systems. For now, always > > bootstrap BSD ar(1) on newer systems during the build (in case > > some bugs pop up), but after some period of testing, we can stop > > unconditionally bootstrapping it. > > I would *really* like BSD ar to be used to build world regardless of > host system version, at least on the tinderbox. Isn't it possible to > use GNU ar just for the toolchain, then BSD ar for the "real" world? > Doesn't adding ar to bootstrap-tools take care of that? > > Note that the tinderbox *always* cross-builds, even when building for > the platform it runs on. > BSD ar(1) depends on libelf and libarchive. Do you know which versions of them are safe to produce a working BSD ar(1)? Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 10:54:16 2008 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 7D9F916A400; Fri, 22 Feb 2008 10:54:16 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2E80413C447; Fri, 22 Feb 2008 10:54:16 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=55934 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSVXi-000094-UI; Fri, 22 Feb 2008 10:54:14 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1MAsDbI094971; Fri, 22 Feb 2008 13:54:13 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1MAsD3w094970; Fri, 22 Feb 2008 13:54:13 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 13:54:13 +0300 From: Ruslan Ermilov To: obrien@freebsd.org, Kai Wang , "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org Message-ID: <20080222105413.GD94607@team.vega.ru> References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20080222102409.GD57428@team.vega.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 10:54:16 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's an updated patch. It differs in that we don't bootstrap BSD ar(1) if we were told to build WITH_GNUAR, and we don't install BSD ar(1) with "bsd" prefixes if it's to be the system ar(1) (requested by David). Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: sys/sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.337 diff -u -p -r1.337 param.h --- sys/sys/param.h 21 Feb 2008 16:12:46 -0000 1.337 +++ sys/sys/param.h 22 Feb 2008 07:43:33 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800021 /* Master, propagated to newvers */ +#define __FreeBSD_version 800022 /* Master, propagated to newvers */ #ifndef LOCORE #include Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.598 diff -u -p -r1.598 Makefile.inc1 --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 +++ Makefile.inc1 22 Feb 2008 10:02:05 -0000 @@ -885,8 +885,13 @@ _crunchgen= usr.sbin/crunch/crunchgen _mklocale= usr.bin/mklocale .endif +.if ${BOOTSTRAPPING} >= 800022 && !defined(WITH_GNUAR) +_ar= usr.bin/ar +.endif + bootstrap-tools: .for _tool in \ + ${_ar} \ ${_mklocale} \ ${_strfile} \ ${_gperf} \ @@ -967,6 +972,10 @@ _kgzip= usr.sbin/kgzip .endif .endif +.if make(cross-tools) && ${BOOTSTRAPPING} < 800022 +.MAKEFLAGS+= -DWITH_GNUAR +.endif + cross-tools: .for _tool in \ gnu/usr.bin/binutils \ Index: gnu/usr.bin/binutils/ar/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ar/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- gnu/usr.bin/binutils/ar/Makefile 21 Feb 2008 16:59:02 -0000 1.16 +++ gnu/usr.bin/binutils/ar/Makefile 22 Feb 2008 06:56:10 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ar -#MAN= gnu-ar.1 -.else -PROG= ar +.if !defined(WITH_GNUAR) +PROGNAME= gnu-ar +MAN= gnu-ar.1 +gnu-ar.1: ar.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gnu-ar.1 .endif + +PROG= ar SRCS= ar.c not-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: gnu/usr.bin/binutils/ranlib/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ranlib/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- gnu/usr.bin/binutils/ranlib/Makefile 21 Feb 2008 16:59:02 -0000 1.17 +++ gnu/usr.bin/binutils/ranlib/Makefile 22 Feb 2008 06:54:04 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ranlib -#MAN= gnu-ranlib.1 -.else -PROG= ranlib +.if !defined(WITH_GNUAR) +PROGNAME= gnu-ranlib +MAN= gnu-ranlib.1 +gnu-ranlib.1: ranlib.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gnu-ranlib.1 .endif + +PROG= ranlib SRCS= ar.c is-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: usr.bin/ar/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- usr.bin/ar/Makefile 22 Feb 2008 06:53:52 -0000 1.19 +++ usr.bin/ar/Makefile 22 Feb 2008 10:31:44 -0000 @@ -1,10 +1,21 @@ # $FreeBSD: src/usr.bin/ar/Makefile,v 1.19 2008/02/22 06:53:52 obrien Exp $ -.if defined(WITH_BSDAR) PROG= ar + +.if !defined(WITH_GNUAR) +NO_SHARED?= yes +LINKS= ${BINDIR}/ar ${BINDIR}/ranlib +MLINKS= ar.1 ranlib.1 .else -PROG= bsdar +PROGNAME= bsdar +MAN= bsdar.1 +bsdar.1: ar.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= bsdar.1 +LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib +MLINKS= bsdar.1 bsdranlib.1 .endif + SRCS= ar.c read.c util.c write.c WARNS?= 5 @@ -12,17 +23,4 @@ WARNS?= 5 DPADD= ${LIBARCHIVE} ${LIBBZ2} ${LIBZ} ${LIBELF} LDADD= -larchive -lbz2 -lz -lelf -.if defined(WITH_BSDAR) -NO_SHARED?= yes -LINKS= ${BINDIR}/ar ${BINDIR}/ranlib -MLINKS= ar ranlib -.else -LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib -MLINKS= bsdar.1 bsdranlib.1 - -CLEANFILES+= bsdar.1 -bsdar.1: ar.1 - ln -sf ${.ALLSRC} ${.TARGET} -.endif - .include --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 11:09:34 2008 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 E594416A407 for ; Fri, 22 Feb 2008 11:09:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id AB32913C46E for ; Fri, 22 Feb 2008 11:09:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A6C7C2084; Fri, 22 Feb 2008 12:09:27 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2C17E2049; Fri, 22 Feb 2008 12:09:27 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 0895584499; Fri, 22 Feb 2008 12:09:27 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mikael Ikivesi References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> Date: Fri, 22 Feb 2008 12:09:26 +0100 In-Reply-To: <20080222113646.2dbb9ec1@chaos.nox> (Mikael Ikivesi's message of "Fri\, 22 Feb 2008 11\:36\:46 +0200") Message-ID: <86zlttqmc9.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svein-listmail@d80.iso100.no, freebsd-current Subject: Re: 2 core dumps 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, 22 Feb 2008 11:09:35 -0000 Mikael Ikivesi writes: > I have checked for overheating as it was my first quess but the answer > is no. And these dumps happened without powerd. I only manually enable > 1800Mhz sometimes if I need extra speed. It seems to be highest > sustainable speed for this machine. Powerd heats this laptop too much > without manually setting _PSV value to much lower. And the result would > be the same 1800Mhz. Your laptop overheats when running at its rated frequency? That's your answer. Hardware error. Most likely incorrect application of heat transfer compound between the CPU and the heatsink, or blocked or defective fans. If your CPU has overheated even once, you can't trust it any more, unless it has an automatic cutoff like Core and Core 2. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 11:11:19 2008 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 1097516A412 for ; Fri, 22 Feb 2008 11:11:19 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id BE96413C4EC for ; Fri, 22 Feb 2008 11:11:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:c0c5:e0bd:595c:f41b] (unknown [IPv6:2001:7b8:3a7:0:c0c5:e0bd:595c:f41b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 858533C; Fri, 22 Feb 2008 12:11:17 +0100 (CET) Message-ID: <47BEADD5.3000506@andric.com> Date: Fri, 22 Feb 2008 12:11:17 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.13pre (Windows/20080218) MIME-Version: 1.0 To: Sam Leffler References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <47BE6D86.6050801@errno.com> In-Reply-To: <47BE6D86.6050801@errno.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 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, 22 Feb 2008 11:11:19 -0000 On 2008-02-22 07:36, Sam Leffler wrote: >> Actually, m_defrag() DOES exist in RELENG_7, it's m_collapse() that >> isn't yet MFC'd, apparently. So that is the function that needs to >> copied from HEAD's uipc_mbuf.c instead. > m_collapsed has been mfc'd: Ah I see, to RELENG_7, but not to RELENG_7_0 (I'm using the latter). From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 12:10:19 2008 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 7A1C416A406; Fri, 22 Feb 2008 12:10:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3428A13C45A; Fri, 22 Feb 2008 12:10:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E5C8D2091; Fri, 22 Feb 2008 13:10:12 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D5EB32087; Fri, 22 Feb 2008 13:10:12 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id B6F7084499; Fri, 22 Feb 2008 13:10:12 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ruslan Ermilov References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> Date: Fri, 22 Feb 2008 13:10:12 +0100 In-Reply-To: <20080222105239.GC94607@team.vega.ru> (Ruslan Ermilov's message of "Fri\, 22 Feb 2008 13\:52\:39 +0300") Message-ID: <86abltqjiz.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , Kai Wang , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 12:10:19 -0000 Ruslan Ermilov writes: > BSD ar(1) depends on libelf and libarchive. Do you know which > versions of them are safe to produce a working BSD ar(1)? __FreeBSD_version wasn't bumped specifically for it, but 700044 should be fine (first bump after the last significant bug fix to ar support, as far as I can tell) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 09:47:53 2008 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 CD6C016A407 for ; Fri, 22 Feb 2008 09:47:53 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (host3.dynacom.ondsl.gr [62.103.35.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3CEB613C4F0 for ; Fri, 22 Feb 2008 09:47:52 +0000 (UTC) (envelope-from achill@matrix.gatewaynet.com) Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.14.2/8.14.2) with ESMTP id m1M9lmrv093305; Fri, 22 Feb 2008 11:47:48 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Received: from localhost (localhost [[UNIX: localhost]]) by smadev.internal.net (8.14.2/8.14.2/Submit) id m1M9ljVA093304; Fri, 22 Feb 2008 11:47:45 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: "Poul-Henning Kamp" Date: Fri, 22 Feb 2008 11:47:44 +0200 User-Agent: KMail/1.9.7 References: <74067.1203596816@critter.freebsd.dk> In-Reply-To: <74067.1203596816@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802221147.45159.achill@matrix.gatewaynet.com> X-Mailman-Approved-At: Fri, 22 Feb 2008 12:23:00 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Crazy md5, sha256, bzip2 behaviour, frequent crashes RAM problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 09:47:53 -0000 =D3=F4=E9=F2 Thursday 21 February 2008 14:26:56 =EF/=E7 Poul-Henning Kamp = =DD=E3=F1=E1=F8=E5: > In message <200802211406.40612.achill@matrix.gatewaynet.com>, Achilleas M= antzio > s writes: > >Hi, > >i've struggling to build sysutils/coreutils and a crazy thing happens: > >each time i do=20 > >fetch ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2 > >and while ls -l gives the exact same size (5384378), md5,sha256 give dif= ferent checksums each time! >=20 > Bad hardware. >=20 Indeed. Changing memory dims and the port built/installed ok. What worries me, is if i can trust the system as is, (while i have some 600= ports installed) or rebuild everything. artsd from kde behaves in a strange way (noatun skiping every 2nd second of= mp3), and i wander that if a rebuild of artsd solves the problem, then maybe i mi= ght worry of the correctness of the whole system. =2D-=20 Achilleas Mantzios KOSOVO IS SERBIA FOR EVER From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 12:46:24 2008 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 404B616A406; Fri, 22 Feb 2008 12:46:24 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id E5DCD13C478; Fri, 22 Feb 2008 12:46:23 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=53884 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JSXIA-0005Ml-JS; Fri, 22 Feb 2008 12:46:18 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1MCkHjm016592; Fri, 22 Feb 2008 15:46:17 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1MCkHk6016591; Fri, 22 Feb 2008 15:46:17 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 22 Feb 2008 15:46:17 +0300 From: Ruslan Ermilov To: Dag-Erling Sm??rgrav Message-ID: <20080222124617.GA16580@team.vega.ru> References: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86abltqjiz.fsf@ds4.des.no> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joseph Koshy , Kai Wang , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 12:46:24 -0000 On Fri, Feb 22, 2008 at 01:10:12PM +0100, Dag-Erling Sm??rgrav wrote: > Ruslan Ermilov writes: > > BSD ar(1) depends on libelf and libarchive. Do you know which > > versions of them are safe to produce a working BSD ar(1)? > > __FreeBSD_version wasn't bumped specifically for it, but 700044 should > be fine And for 8xxxxx? > (first bump after the last significant bug fix to ar support, as > far as I can tell) > After I commit my changes (I'll wait for a review from David), we can play with these numbers. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 12:59:39 2008 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 15D5416A408; Fri, 22 Feb 2008 12:59:39 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C56C113C468; Fri, 22 Feb 2008 12:59:38 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 153A42099; Fri, 22 Feb 2008 13:59:33 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8019D2091; Fri, 22 Feb 2008 13:59:32 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 56D658448C; Fri, 22 Feb 2008 13:59:32 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ruslan Ermilov References: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> Date: Fri, 22 Feb 2008 13:59:32 +0100 In-Reply-To: <20080222124617.GA16580@team.vega.ru> (Ruslan Ermilov's message of "Fri\, 22 Feb 2008 15\:46\:17 +0300") Message-ID: <86wsoxp2ob.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , Kai Wang , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 12:59:39 -0000 Ruslan Ermilov writes: > Dag-Erling Sm=C3=B8rgrav writes: > > __FreeBSD_version wasn't bumped specifically for it, but 700044 > > should be fine. > And for 8xxxxx? 700044 is from before the branch, so anything > 700044 is fine. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 13:17:51 2008 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 761A816A400 for ; Fri, 22 Feb 2008 13:17:51 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDD513C457 for ; Fri, 22 Feb 2008 13:17:51 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWN009LP697A8V1@vms046.mailsrvcs.net> for freebsd-current@freebsd.org; Fri, 22 Feb 2008 07:17:33 -0600 (CST) Date: Fri, 22 Feb 2008 08:17:24 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <86zlttqmc9.fsf@ds4.des.no> To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-id: <1203686245.63435.12.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> Cc: svein-listmail@d80.iso100.no, freebsd-current , Mikael Ikivesi Subject: Re: 2 core dumps 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, 22 Feb 2008 13:17:51 -0000 On Fri, 2008-02-22 at 12:09 +0100, Dag-Erling Smørgrav wrote: > Mikael Ikivesi writes: > > I have checked for overheating as it was my first quess but the answer > > is no. And these dumps happened without powerd. I only manually enable > > 1800Mhz sometimes if I need extra speed. It seems to be highest > > sustainable speed for this machine. Powerd heats this laptop too much > > without manually setting _PSV value to much lower. And the result would > > be the same 1800Mhz. > > Your laptop overheats when running at its rated frequency? That's your > answer. Hardware error. Most likely incorrect application of heat > transfer compound between the CPU and the heatsink, or blocked or > defective fans. If your CPU has overheated even once, you can't trust > it any more, unless it has an automatic cutoff like Core and Core 2. If "overheated" in this context means "initiated critical shutdown" neither statement needs to be true. For instance, there is the patch from Umemoto-san floating around acpi@ that enables use of passive cooling for the thermal zones other that tz0, and there is at least one model of laptop that I know of, which uses tz1 for its CPU. This means that FreeBSD *will not* handle passive cooling on such laptop and it might reach _CRT and shut itself down. Also, some manufacturers put _PSV dangerously close to _CRT, assuming that OS will take over in time, which might or might not happen in the real life. However, if "overheated" means "discolored and deformed plastic parts", you are absolutely right. > > DES -- Alexandre "Sunny" Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 13:56:59 2008 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 8251416A402 for ; Fri, 22 Feb 2008 13:56:59 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail1.isdefe.es (mail1.isdefe.es [194.15.213.239]) by mx1.freebsd.org (Postfix) with ESMTP id 490A113C4CC for ; Fri, 22 Feb 2008 13:56:59 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from [10.100.147.125] (opera.isdefe.es [194.15.213.193]) by mail1.isdefe.es (Postfix) with ESMTP id 333405C35; Fri, 22 Feb 2008 14:56:57 +0100 (CET) Message-ID: <47BED4A9.1020901@pop.isdefe.es> Date: Fri, 22 Feb 2008 14:56:57 +0100 From: Raul User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christoph Schug References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <20080221143748.GE10726@lega.schug.net> <47BE9910.7030501@pop.isdefe.es> <20080222103642.GB45806@lega.schug.net> In-Reply-To: <20080222103642.GB45806@lega.schug.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Pyun YongHyeon , FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 (and em0 too) 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, 22 Feb 2008 13:56:59 -0000 Christoph Schug escribió: >> The fastest method I found to reproduce the problem is receive a >> compresed tar (with good compression ratio) over the network (using nc, >> 100 Mbps fdx), pipe through tar that decompress and write it on disk (a >> lot of MB/s and tps looking at 'systat -vm'). The source tar file is >> about 5Gb and link always fails before EOF :|. [....] > Up to now, no problems, but I certainly need more uptime to be sure. > Maybe I can tell more later that day. My box used to also need a couple or three days to exhibit the problem until I realize that my previous example made it happen in minutes: RELENG_7_0 i386 - em0 - dot1q - switch - clear - re0 - RELENG_7_0 amd64 on the i386: cat files_with_lots_of_zeros.tgz | nc -l 3000 on the amd64: nc i386_box_address 3000 | tar xzvf - My files_with_lots_of_zeros.tgz is about 5Gb, and the i386 box flood the re0 link (1000baseTX vs 100baseTX). I've never seen the end of the file on the re0 side. No problem on the i386 side, just to illustrate my setup. I see the same behavior on the amd64 box using an em0 card (pci one). No clue if my problem differs from yours but in my case it doesn't look like only a re0 problem :/. Regards, Raul From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 14:29:09 2008 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 D9B3A16A401; Fri, 22 Feb 2008 14:29:09 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id AA77213C4EA; Fri, 22 Feb 2008 14:29:09 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m1MET2NY096167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 09:29:02 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sqWt6IoV40Qa3lSJXSgZ" Organization: U. Buffalo CSE Department Date: Fri, 22 Feb 2008 09:29:02 -0500 Message-Id: <1203690542.10026.19.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Subject: FreeBSD 7.0-RC3 (for amd64/i386 only) Available 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, 22 Feb 2008 14:29:09 -0000 --=-sqWt6IoV40Qa3lSJXSgZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We're doing a "mini-RC3" to encourage testing of the Highpoint driver (hptrr) backout. Testing of 7.0-RC2 showed there were problems with the driver update done between RC1 and RC2. Because it's a "mini-RC" targetted at testing of one particular thing we have not bothered with setting up FreeBSD Update. You can use the normal cvsup-and-build method of doing an update for machines that are already up and running (branch tag RELENG_7_0) or install from scratch using the ISOs available on the FTP sites. If those who experienced problems related to the hptrr driver update could let us know one way or another whether or not you are still having problems with it that would be appreciated. Thanks. Sums for the ISOs: MD5 (7.0-RC3-amd64-bootonly.iso) =3D f2a546a58026651069d2e332df1c9861 MD5 (7.0-RC3-amd64-disc1.iso) =3D 1f1ab0c6006150f075acf0c14aa381e4 MD5 (7.0-RC3-amd64-disc2.iso) =3D 172d0e28a283d6ca6c4334887a80c10b MD5 (7.0-RC3-amd64-disc3.iso) =3D 20bbfadcf4c77466541f817ded520a03 MD5 (7.0-RC3-amd64-docs.iso) =3D 3bd7f636bce99a8276af91b512efe9d1 MD5 (7.0-RC3-amd64-livefs.iso) =3D cef35c58ef525818cb7a451db670312e MD5 (7.0-RC3-i386-bootonly.iso) =3D a201126726b3ce8f0c64ee5bd58c64f4 MD5 (7.0-RC3-i386-disc1.iso) =3D b2424432eaca4741a9df0d87165c1285 MD5 (7.0-RC3-i386-disc2.iso) =3D 51646452d777fbe875462384e924c39a MD5 (7.0-RC3-i386-disc3.iso) =3D 23450ec1bfaeeeda3945201975bb117a MD5 (7.0-RC3-i386-docs.iso) =3D 0c6963cf39c63471eeebbdc6494a4e04 MD5 (7.0-RC3-i386-livefs.iso) =3D b08c3761085e8ad63fe220f9ef279e22 SHA256 (7.0-RC3-amd64-bootonly.iso) =3D f71a8ee8151f72bcb91e6ce8d06eadccded= 333fac0ac617dc9cd4b9d5ab27e7c SHA256 (7.0-RC3-amd64-disc1.iso) =3D 7f8248711909fac0fef1a4be4d8845f69e32cc= 27dfc5bf2998f3548677d20068 SHA256 (7.0-RC3-amd64-disc2.iso) =3D bb7a426dc8e73f3cfa8fb9849d8b64423c5f3d= 765d33c03492b14d5ee362422e SHA256 (7.0-RC3-amd64-disc3.iso) =3D 6918c68ee49fa3d6382e380d36018438b4060e= b6637c48712c8df69eb03d12b3 SHA256 (7.0-RC3-amd64-docs.iso) =3D fa7c714cc7aac4ba02d538b2d08fd276c6ff212= dedb34d9cf275885a7ce3044a SHA256 (7.0-RC3-amd64-livefs.iso) =3D 078a21078904caf1f3a205031432a018ead5f= fd8834f4348b31e148ae162f186 SHA256 (7.0-RC3-i386-bootonly.iso) =3D 886fde7fc85cec484c03f5ac53ce842133a8= 1853418bffe429fcf13f5699fd08 SHA256 (7.0-RC3-i386-disc1.iso) =3D febbbdf5e632aacf73ef118d0310c8bbc0360d8= 51e3c5986301dd01bb7994690 SHA256 (7.0-RC3-i386-disc2.iso) =3D e16e6141f5f2e97024ad28215e9f8c70b4232b6= 63859b74538061908a2e1bb2e SHA256 (7.0-RC3-i386-disc3.iso) =3D 994ef5741f74c805c106bcdf1ebb2ef7b23bddd= fa2667f2df9f64169acb4b434 SHA256 (7.0-RC3-i386-docs.iso) =3D ce9a2c6b4b918fc19203cb8ce3bcb427b6957a28= a3c34925d66c6ecb12845ec7 SHA256 (7.0-RC3-i386-livefs.iso) =3D 04e79cd45a6498ffc71a033f3d4e6f2dcb34d1= 07f371a349d8db74edd7568712 --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-sqWt6IoV40Qa3lSJXSgZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHvtwk/G14VSmup/YRAsv7AJ440h9Td5MwktLO5U4Q0E/qBzV1cACffR6b UXJ5/tN5tTUnqQNVk1FqwC0= =8m1o -----END PGP SIGNATURE----- --=-sqWt6IoV40Qa3lSJXSgZ-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 14:31:37 2008 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 827CF16A408 for ; Fri, 22 Feb 2008 14:31:37 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id 2292F13C474 for ; Fri, 22 Feb 2008 14:31:36 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.13.8) with ESMTP id m1MEVLJp064139; Fri, 22 Feb 2008 08:31:21 -0600 (CST) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20080222083112.02526d70@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 22 Feb 2008 08:33:15 -0600 To: "Zaphod Beeblebrox" From: Derek Ragona In-Reply-To: <5f67a8c40802212325x7f52c483y9d636def40d902cf@mail.gmail.co m> References: <5f67a8c40802211035n3b6db2fcvd4309ebd1222cb69@mail.gmail.com> <6.0.0.22.2.20080221162331.024b0dc8@mail.computinginnovations.com> <5f67a8c40802212325x7f52c483y9d636def40d902cf@mail.gmail.com> Mime-Version: 1.0 X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: 100% of one CPU for nvidia 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, 22 Feb 2008 14:31:37 -0000 At 01:25 AM 2/22/2008, Zaphod Beeblebrox wrote: >On Thu, Feb 21, 2008 at 10:24 PM, Derek Ragona < >derek@computinginnovations.com> wrote: > >[ my report of 100% of one cpu going to nvidia, deleted] > > > > > > I have seen this using xorg 7.3.1 with legacy 96 nvidia drivers too. > > > > I didn't have the problem until I went from xorg 7.1 to 7.3. > > > >Are you using 8xxx series nvidia chips? Ie: is this a problem with that >series, or is it more general? Mine is an older card, the GeForce2 MX/MX 400 in an AGP slot. So I think this is a more widespread problem. I did post to the nvidia forum, but I don't think much has happened from that. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 14:42:11 2008 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 D3E5816A400 for ; Fri, 22 Feb 2008 14:42:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4A613C4D3 for ; Fri, 22 Feb 2008 14:42:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 0F18B208E; Fri, 22 Feb 2008 15:42:06 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id F1DD8207E; Fri, 22 Feb 2008 15:42:05 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id DD1B184499; Fri, 22 Feb 2008 15:42:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Alexandre \"Sunny\" Kovalenko" References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> Date: Fri, 22 Feb 2008 15:42:05 +0100 In-Reply-To: <1203686245.63435.12.camel@RabbitsDen> (Alexandre Kovalenko's message of "Fri\, 22 Feb 2008 08\:17\:24 -0500") Message-ID: <86oda9oxxe.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svein-listmail@d80.iso100.no, freebsd-current , Mikael Ikivesi Subject: Re: 2 core dumps 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, 22 Feb 2008 14:42:11 -0000 "Alexandre \"Sunny\" Kovalenko" writes: > Dag-Erling Sm=C3=B8rgrav writes: >> Your laptop overheats when running at its rated frequency? That's your >> answer. Hardware error. [...] > If "overheated" in this context means "initiated critical shutdown" > [...] No, unless the Athlon has an internal temperature sensor and shuts itself down when it reaches critical temperature, like the Intel Core and Core 2 do. You can't rely on the BIOS or the OS to do it, because you have no idea where the temperature sensor they rely on is placed. > However, if "overheated" means "discolored and deformed plastic parts", > you are absolutely right. Right. Your laptop is dead. Deal with it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 14:58:34 2008 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 71E2016A402 for ; Fri, 22 Feb 2008 14:58:34 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 3A13013C4F0 for ; Fri, 22 Feb 2008 14:58:34 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1JSZAf-0006J3-6e for freebsd-current@FreeBSD.org; Fri, 22 Feb 2008 17:46:41 +0300 To: freebsd-current@FreeBSD.org From: Boris Samorodov Date: Fri, 22 Feb 2008 17:44:55 +0300 Message-ID: <62733928@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: default /etc/hosts and ftp 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, 22 Feb 2008 14:58:34 -0000 Hello List! I'm seeing a strange /etc/hosts effect with ftp to the host itself. The file /etc/hosts was created while installing (this is a fresh 8-CURRENT install). The lines in question from /etc/hosts: ----- 192.168.1.100 testbox.bsam.ru testbox 192.168.1.100 testbox.bsam.ru. ----- The ftp service is invoked by indetd: ----- ftp stream tcp nowait/100/100/10 root /usr/libexec/ftpd ftpd -ll4A ----- The effect: ----- % fetch ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz load: 0.02 cmd: fetch 8217 [connec] 0.00u 0.00s 0% 2216k fetch: ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz: Operation timed out ----- The relevant part from netstat: ----- Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 testbox.61799 testbox.ftp SYN_SENT tcp4 0 0 *.ftp *.* LISTEN ----- If the first line at /etc/hosts is deletted/commented out (changing an order of those lines doesn't help): ----- % fetch ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz portupgrade.tbz 100% of 127 kB 91 MBps ----- The host resolves direct and revers just fine. Some additional info (GENERIC-FAST is GENERIC without INVARIANTS/WITNESS): ----- % uname -a FreeBSD testbox.bsam.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Feb 21 16:54:25 MSK 2008 root@testbox.bsam.ru:/usr/obj/usr/src/sys/GENERIC-FAST amd64 ----- Any comments? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 15:01:42 2008 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 554A816A408 for ; Fri, 22 Feb 2008 15:01:42 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 395F013C459 for ; Fri, 22 Feb 2008 15:01:42 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWN00E6RAY1U202@vms173003.mailsrvcs.net> for freebsd-current@freebsd.org; Fri, 22 Feb 2008 08:58:50 -0600 (CST) Date: Fri, 22 Feb 2008 10:01:32 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <86oda9oxxe.fsf@ds4.des.no> To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-id: <1203692492.63435.16.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> Cc: svein-listmail@d80.iso100.no, freebsd-current , Mikael Ikivesi Subject: Re: 2 core dumps 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, 22 Feb 2008 15:01:42 -0000 On Fri, 2008-02-22 at 15:42 +0100, Dag-Erling Smørgrav wrote: > "Alexandre \"Sunny\" Kovalenko" writes: > > Dag-Erling Smørgrav writes: > >> Your laptop overheats when running at its rated frequency? That's your > >> answer. Hardware error. [...] > > If "overheated" in this context means "initiated critical shutdown" > > [...] > > No, unless the Athlon has an internal temperature sensor and shuts > itself down when it reaches critical temperature, like the Intel Core > and Core 2 do. > > You can't rely on the BIOS or the OS to do it, because you have no idea > where the temperature sensor they rely on is placed. If I rephrase my point as "The fact that OS initiated shutdown because it thinks that your laptop has reached certain temperature threshold does not necessarily mean that your hardware is damaged." would you be more amenable to agreeing with it? > > > However, if "overheated" means "discolored and deformed plastic parts", > > you are absolutely right. > > Right. Your laptop is dead. Deal with it. > > DES -- Alexandre "Sunny" Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 16:03:12 2008 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 39CC516A402 for ; Fri, 22 Feb 2008 16:03:12 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout4-sn1.fre.skanova.net (pne-smtpout4-sn1.fre.skanova.net [81.228.11.168]) by mx1.freebsd.org (Postfix) with ESMTP id 04D9E13C459 for ; Fri, 22 Feb 2008 16:03:11 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from chaos.nox (80.221.12.61) by pne-smtpout4-sn1.fre.skanova.net (7.3.129) (authenticated as tansmi-f) id 47A7970A000FD06F; Fri, 22 Feb 2008 17:03:10 +0100 Date: Fri, 22 Feb 2008 18:02:46 +0200 From: Mikael Ikivesi To: freebsd-current@freebsd.org, des@des.no, alex.kovalenko@verizon.net Message-ID: <20080222180246.0ceb273e@chaos.nox> In-Reply-To: <1203692492.63435.16.camel@RabbitsDen> References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> <1203692492.63435.16.camel@RabbitsDen> X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: 2 core dumps 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, 22 Feb 2008 16:03:12 -0000 On Fri, 22 Feb 2008 12:09:26 +0100 Dag-Erling Sm=F8rgrav wrote: > Your laptop overheats when running at its rated frequency? That's > your answer. Hardware error. Most likely incorrect application of > heat transfer compound between the CPU and the heatsink, or blocked or > defective fans. If your CPU has overheated even once, you can't trust > it any more, unless it has an automatic cutoff like Core and Core 2. >=20 > DES Fans are working and clean. Dried silverpaste was replaced few weeks ago as I cleaned heatsink..Everything works. As I wrote earlier it cannot maintain 2.4Ghz constantly but has to speed down. On Fri, 22 Feb 2008 08:17:24 -0500 "Alexandre \"Sunny\" Kovalenko" wrote: > If "overheated" in this context means "initiated critical shutdown" > neither statement needs to be true. For instance, there is the patch > from Umemoto-san floating around acpi@ that enables use of passive > cooling for the thermal zones other that tz0, and there is at least > one model of laptop that I know of, which uses tz1 for its CPU. This > means that FreeBSD *will not* handle passive cooling on such laptop > and it might reach _CRT and shut itself down. Also, some > manufacturers put _PSV dangerously close to _CRT, assuming that OS > will take over in time, which might or might not happen in the real > life. Overheating in this case means my own judgement and usability. If I use powerd and stress this machine by compiling lot of stuff in background while doing some work this laptop heats a lot. Temperature seems to stay between 85-95 degress and fans screams constantly. I have not let it stay in that condition for long time, because I dont know if it will shutdown properly if I let it heat more...if it heats more. Or does it throttle down like with linux.. So the definaton would be: Overheating is system getting uncomfortable to use (lot of noise and the fact that my machine becomes something that cannot be called LAPtop) AND this does NOT mean my laptop is toast(er).. tz0 is my cpu and it show right values. When this laptop heats it seems to be more like powerd related. 800-1800Mhz fans kick in every now and then and keep system in sane temperature. Powerd seems to work better if I set user.override and lower value to _PSV. It seems to kick machine into constant loop of changing 800->1800 after heat has risen and then stays there until compilation (or etc.) has finished. This way powerd cab be used and my system works as usable LAPtop. As currently I use this laptop mostly for writing and some desktop publishing jobs I dont currently need powerd as I am comfortable with lowest value and longes battery life. And I guess this laptop throttles quite nicely to safe cpu freq when it needs to. With linux I noticed that if let compiling (former gentoo user) get too intensive and heat builds up machine goes to strange frequency of 1920Mhz which is not available in any other way. And it locks it as highest value that this machine is capable for sometime and then releases it and lets cpu to go 2.4Ghz (Or is this something that linux does without my knowing???) On Fri, 22 Feb 2008 15:42:05 +0100 Dag-Erling Sm=F8rgrav wrote: > Right. Your laptop is dead. Deal with it. Not yet accepting that as a fact ;) And to get back to possible reasons for those coredumps I guess that the fact that this machine rebooted and dumped at frequency of 800Mhz that has NEVER overheated I cannot see heating as reason for them... I am currently try to find out what causes them by doing lot of things with X and without X to get the idea if this is caused by FreeBSD itself or somehow by some new port behaving badly on FreeBSD. And as this has not happened with linux I cannot blame hardware alone... -Mikael From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 16:16:13 2008 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 A80A716A40F for ; Fri, 22 Feb 2008 16:16:13 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 6E98613C50A for ; Fri, 22 Feb 2008 16:16:12 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1JSaZH-0006Pr-FJ; Fri, 22 Feb 2008 19:16:11 +0300 To: admin@su29.net References: <62733928@bb.ipt.ru> <47BEF10D.2050404@su29.net> From: Boris Samorodov Date: Fri, 22 Feb 2008 19:14:25 +0300 In-Reply-To: <47BEF10D.2050404@su29.net> (Alexander V. Chernikov's message of "Fri\, 22 Feb 2008 18\:58\:05 +0300") Message-ID: <96658558@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: default /etc/hosts and ftp 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, 22 Feb 2008 16:16:13 -0000 On Fri, 22 Feb 2008 18:58:05 +0300 Alexander V. Chernikov wrote: > Boris Samorodov wrote: > > I'm seeing a strange /etc/hosts effect with ftp to the host itself. > > The file /etc/hosts was created while installing (this is a fresh > > 8-CURRENT install). The lines in question from /etc/hosts: > > ----- > > 192.168.1.100 testbox.bsam.ru testbox > > 192.168.1.100 testbox.bsam.ru. > > ----- > > > > The ftp service is invoked by indetd: > > ----- > > ftp stream tcp nowait/100/100/10 root /usr/libexec/ftpd ftpd -ll4A > > ----- > > > > The effect: > > ----- > > % fetch ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz > > load: 0.02 cmd: fetch 8217 [connec] 0.00u 0.00s 0% 2216k > > fetch: ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz: Operation timed out > > ----- > > > > The relevant part from netstat: > > ----- > > Proto Recv-Q Send-Q Local Address Foreign Address (state) > > tcp4 0 0 testbox.61799 testbox.ftp SYN_SENT > > tcp4 0 0 *.ftp *.* LISTEN > > ----- > > > > If the first line at /etc/hosts is deletted/commented out (changing an > > order of those lines doesn't help): > > ----- > > % fetch ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz > > portupgrade.tbz 100% of 127 kB 91 MBps > > ----- > I'm not able to reproduce this on Feb 15 current. > Can you check ftp availability with telnet and use 'netstat -n' ? Yes, telnet showed me my fault -- it was a typo at /etc/hosts with ip-address. Thanks for your help! And sorry for the noise. > Do you have any firewall rules possibly blocking localhost traffic? > Host appears to use DNS in second case which can provide different IP > address > > > > The host resolves direct and revers just fine. > > > > Some additional info (GENERIC-FAST is GENERIC without INVARIANTS/WITNESS): > > ----- > > % uname -a > > FreeBSD testbox.bsam.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Feb 21 16:54:25 MSK 2008 root@testbox.bsam.ru:/usr/obj/usr/src/sys/GENERIC-FAST amd64 > > ----- > > > > > > Any comments? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 16:19:02 2008 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 38C9416A407 for ; Fri, 22 Feb 2008 16:19:02 +0000 (UTC) (envelope-from admin@su29.net) Received: from aliska.alo.ru (aliska.alo.ru [80.251.131.12]) by mx1.freebsd.org (Postfix) with ESMTP id E661713C448 for ; Fri, 22 Feb 2008 16:19:01 +0000 (UTC) (envelope-from admin@su29.net) Received: from aliska (aliska.alo.ru [80.251.131.12]) by aliska.alo.ru (Postfix) with SMTP id E122E24CE97 for ; Fri, 22 Feb 2008 18:58:29 +0300 (MSK) Received: from ws.su29.net (ppp85-141-155-218.pppoe.mtu-net.ru [85.141.155.218]) by aliska.alo.ru (Postfix) with ESMTP id 7AB0524CEC9; Fri, 22 Feb 2008 18:58:29 +0300 (MSK) Message-ID: <47BEF10D.2050404@su29.net> Date: Fri, 22 Feb 2008 18:58:05 +0300 From: "Alexander V. Chernikov" Organization: AlmazTelecom User-Agent: Thunderbird 2.0.0.9 (X11/20080219) MIME-Version: 1.0 To: Boris Samorodov References: <62733928@bb.ipt.ru> In-Reply-To: <62733928@bb.ipt.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: default /etc/hosts and ftp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: admin@su29.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 16:19:02 -0000 Boris Samorodov wrote: > Hello List! > > > I'm seeing a strange /etc/hosts effect with ftp to the host itself. > The file /etc/hosts was created while installing (this is a fresh > 8-CURRENT install). The lines in question from /etc/hosts: > ----- > 192.168.1.100 testbox.bsam.ru testbox > 192.168.1.100 testbox.bsam.ru. > ----- > > The ftp service is invoked by indetd: > ----- > ftp stream tcp nowait/100/100/10 root /usr/libexec/ftpd ftpd -ll4A > ----- > > The effect: > ----- > % fetch ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz > load: 0.02 cmd: fetch 8217 [connec] 0.00u 0.00s 0% 2216k > fetch: ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz: Operation timed out > ----- > > The relevant part from netstat: > ----- > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp4 0 0 testbox.61799 testbox.ftp SYN_SENT > tcp4 0 0 *.ftp *.* LISTEN > ----- > > If the first line at /etc/hosts is deletted/commented out (changing an > order of those lines doesn't help): > ----- > % fetch ftp://testbox.bsam.ru/pub/FreeBSD/ports/amd64/packages/8-bsam/Latest/portupgrade.tbz > portupgrade.tbz 100% of 127 kB 91 MBps > ----- I'm not able to reproduce this on Feb 15 current. Can you check ftp availability with telnet and use 'netstat -n' ? Do you have any firewall rules possibly blocking localhost traffic? Host appears to use DNS in second case which can provide different IP address > > The host resolves direct and revers just fine. > > Some additional info (GENERIC-FAST is GENERIC without INVARIANTS/WITNESS): > ----- > % uname -a > FreeBSD testbox.bsam.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Thu Feb 21 16:54:25 MSK 2008 root@testbox.bsam.ru:/usr/obj/usr/src/sys/GENERIC-FAST amd64 > ----- > > > Any comments? Thanks! > > > WBR From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:00:15 2008 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 BAC5A16A406 for ; Fri, 22 Feb 2008 17:00:15 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id AF27113C447 for ; Fri, 22 Feb 2008 17:00:14 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so301378nfb.33 for ; Fri, 22 Feb 2008 09:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=4vz842VZWirlf84dOtv/9QwL3whAWUcIV3P3+GQyxPM=; b=KJu5tIHDvGeZ4by/QuikdCrZw+4B+gb/6HK1cFvw6f1rrdnC/Ghu8daO2UMt1GZcopXjnpXEgc4eibCKmDs7DpTpyObOj0g7oHhRImGZBfOF0YbI8gK/La8kcnYijxuCtRdf2wt/bA7ugvQInfXr5rWtc5qPLFdGU1QlwZx9XF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=g9GQp6E/KwMSrSSzWP7m8q6WdtCz4ULfQAGOqaaA1HxVS7ahoNH7yN/bJCiy78qSeFICxMK6+YYOQnWMU7yhsIXF15uzkrDv41dWWuUrzOnZ/MB/AZxx//KkV5e+hi4rdxA0jq+aQkypv+1gW9NUhGV9nIfeFKuWEjZqrHilelI= Received: by 10.78.129.16 with SMTP id b16mr448571hud.3.1203699612143; Fri, 22 Feb 2008 09:00:12 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id z37sm2582250ikz.1.2008.02.22.09.00.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 09:00:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JSbFo-0000hS-2Y; Fri, 22 Feb 2008 18:00:08 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1MH07mc002693; Fri, 22 Feb 2008 18:00:07 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Fri, 22 Feb 2008 18:00:07 +0100 From: Kai Wang To: Ruslan Ermilov Message-ID: <20080222170007.GA2622@plan0.kaiwan.csbnet.se> Mail-Followup-To: Ruslan Ermilov , obrien@freebsd.org, "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org References: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222105413.GD94607@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080222105413.GD94607@team.vega.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joseph Koshy , "Dag-Erling C. Smorgrav" , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 17:00:15 -0000 On Fri, Feb 22, 2008 at 01:54:13PM +0300, Ruslan Ermilov wrote: > Here's an updated patch. It differs in that we don't > bootstrap BSD ar(1) if we were told to build WITH_GNUAR, > and we don't install BSD ar(1) with "bsd" prefixes if > it's to be the system ar(1) (requested by David). > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > Index: sys/sys/param.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/param.h,v > retrieving revision 1.337 > diff -u -p -r1.337 param.h > --- sys/sys/param.h 21 Feb 2008 16:12:46 -0000 1.337 > +++ sys/sys/param.h 22 Feb 2008 07:43:33 -0000 > @@ -57,7 +57,7 @@ > * is created, otherwise 1. > */ > #undef __FreeBSD_version > -#define __FreeBSD_version 800021 /* Master, propagated to newvers */ > +#define __FreeBSD_version 800022 /* Master, propagated to newvers */ > > #ifndef LOCORE > #include > Index: Makefile.inc1 > =================================================================== > RCS file: /home/ncvs/src/Makefile.inc1,v > retrieving revision 1.598 > diff -u -p -r1.598 Makefile.inc1 > --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 > +++ Makefile.inc1 22 Feb 2008 10:02:05 -0000 > @@ -885,8 +885,13 @@ _crunchgen= usr.sbin/crunch/crunchgen > _mklocale= usr.bin/mklocale > .endif > > +.if ${BOOTSTRAPPING} >= 800022 && !defined(WITH_GNUAR) > +_ar= usr.bin/ar > +.endif > + > bootstrap-tools: > .for _tool in \ > + ${_ar} \ > ${_mklocale} \ > ${_strfile} \ > ${_gperf} \ > @@ -967,6 +972,10 @@ _kgzip= usr.sbin/kgzip > .endif > .endif > > +.if make(cross-tools) && ${BOOTSTRAPPING} < 800022 > +.MAKEFLAGS+= -DWITH_GNUAR > +.endif > + > cross-tools: > .for _tool in \ > gnu/usr.bin/binutils \ > Index: gnu/usr.bin/binutils/ar/Makefile > =================================================================== > RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ar/Makefile,v > retrieving revision 1.16 > diff -u -p -r1.16 Makefile > --- gnu/usr.bin/binutils/ar/Makefile 21 Feb 2008 16:59:02 -0000 1.16 > +++ gnu/usr.bin/binutils/ar/Makefile 22 Feb 2008 06:56:10 -0000 > @@ -4,12 +4,15 @@ > > .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc > > -.if defined(WITH_BSDAR) > -PROG= gnu-ar > -#MAN= gnu-ar.1 > -.else > -PROG= ar > +.if !defined(WITH_GNUAR) > +PROGNAME= gnu-ar Would it be better if we call them gar and granlib? Solaris did that. Also if I remember correctly, some ports probes gar. We also call GNU make as gmake... -- Kai From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 16:00:04 2008 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 B8CB016A404; Fri, 22 Feb 2008 16:00:04 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 25E1613C455; Fri, 22 Feb 2008 15:59:58 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 9C5194A8BD; Sat, 23 Feb 2008 00:59:56 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [10.0.0.249]) by hub.bbnest.net (8.14.2/8.14.1) with ESMTP id m1MFxt10073926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Feb 2008 00:59:55 +0900 (JST) (envelope-from bland@bbnest.net) Message-Id: <20CD87E3-27BC-4789-A51F-BBFDB3258B47@bbnest.net> From: Alexander Nedotsukov To: Kostik Belousov In-Reply-To: <20080221154714.GS57756@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 23 Feb 2008 01:01:59 +0900 References: <4792C32C.5010205@gmail.com> <20080122133835.GT57756@deviant.kiev.zoral.com.ua> <4796356D.9080809@gmail.com> <20080123051648.GV57756@deviant.kiev.zoral.com.ua> <479796E1.4000500@gmail.com> <1201118159.38742.17.camel@shumai.marcuscom.com> <20080123211149.GA57756@deviant.kiev.zoral.com.ua> <1201123933.62127.9.camel@shumai.marcuscom.com> <20080124124213.GD57756@deviant.kiev.zoral.com.ua> <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> <20080221154714.GS57756@deviant.kiev.zoral.com.ua> X-Mailer: Apple Mail (2.919.2) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on hub.bbnest.net X-Mailman-Approved-At: Fri, 22 Feb 2008 17:11:46 +0000 Cc: yokota@freebsd.org, FreeBSD Current , Joe Marcus Marcus Clarke Subject: Re: page fault panic in scioctl and console-kit-daemon 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, 22 Feb 2008 16:00:04 -0000 On 22.02.2008, at 0:47, Kostik Belousov wrote: > On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov wrote: >> Hi, >> >> May I ask to revisit this issue? To me ENXIO is not semantically >> correct in this particular case. It also turns out that doing >> workaround in userspace may not be that good as we used to think. I >> propose is to fix VT_WAITACTIVE so it simply wait for bound device >> activation. For my understanding this change should not have any >> impact on existing code. I also removed really strange console >> cleanup >> bit sticked in a long time ago (see ioctl() part). >> It will be nice to see this patch > > >> (successfully tested by our affected users) committed to all >> branches. >> >> Thanks, >> Alexander. > > I mostly agree with the patch, given it is tested. > > The first (not important) note is that change of the wait channel from > the address of the private structure to the address of the cdev could > cause more spurious wakeups then before. I expect you usermode code to > deal with it properly. Do you know any potential wakeup()s around the kernel? I did not see any spurious wakeups myself nor user reported it so far. However they are not welcome so if it considered to be unsafe we can use address of cdev pointer (&SC_DEV()) which is private to syscons. > > > Second one is that I do not understand the reason to have > sc_clean_up() > there except that it might be to help the screen switching. The commit > message for the rev. 1.307, where it seems to be introduced, is not > useful at all. Any comments ? In fact it was introduced in rev. 1.293 for the first time. According to the commit log it was a part of screensaver interaction improvement. I doubt that it was actually required for VT_WAITACTIVE case. I CCed yokota@ to shed the light on it. > >> >> On 24.01.2008, at 21:42, Kostik Belousov wrote: >> >>> On Wed, Jan 23, 2008 at 04:32:13PM -0500, Joe Marcus Clarke wrote: >>>> >>>> On Wed, 2008-01-23 at 23:11 +0200, Kostik Belousov wrote: >>>>> On Wed, Jan 23, 2008 at 02:55:59PM -0500, Joe Marcus Clarke wrote: >>>>>> >>>>>> On Wed, 2008-01-23 at 20:34 +0100, Pawel Worach wrote: >>>>>>> Kostik Belousov wrote: >>>>>>>> On Tue, Jan 22, 2008 at 07:26:53PM +0100, Pawel Worach wrote: >>>>>>>>> Kostik Belousov wrote: >>>>>>>>>> On Sun, Jan 20, 2008 at 04:42:36AM +0100, Pawel Worach wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> While starting console-kit-daemon (sysutils/consolekit >>>>>>>>>>> 0.2.3) during >>>>>>>>>>> boot or in single-user mode the system panics. If I start it >>>>>>>>>>> post-boot >>>>>>>>>>> it runs fine. This is on 8.0-CURRENT from about 12 hours >>>>>>>>>>> ago, another >>>>>>>>>>> user also reported the same on RELENG_7. Any other >>>>>>>>>>> information I can >>>>>>>>>>> provide ? >>>>>>>>>>> >>>>>>>>>>> Fatal trap 12: page fault while in kernel mode >>>>>>>>>>> fault virtual address = 0x4 >>>>>>>>>>> fault code = supervisor read, page not present >>>>>>>>>>> instruction pointer = 0x20:0xc04d2ab4 >>>>>>>>>>> stack pointer = 0x28:0xe6499b18 >>>>>>>>>>> frame pointer = 0x28:0xe6499b80 >>>>>>>>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>>>>>>>> = DPL 0, pres 1, def32 1, gran 1 >>>>>>>>>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>>>>>>>>> current process = 134 (console-kit-daemon) >>>>>>>>>>> Physical memory: 1014 MB >>>>>>>>>>> Dumping 43 MB: 28 12 >>>>>>>>>>> >>>>>>>>>>> #8 0xc07a34a2 in trap (frame=0xe6499ad8) at >>>>>>>>>>> /usr/src/sys/i386/i386/trap.c:489 >>>>>>>>>>> #9 0xc079183b in calltrap () at /usr/src/sys/i386/i386/ >>>>>>>>>>> exception.s:146 >>>>>>>>>>> #10 0xc04d2ab4 in scioctl (dev=0xc3b20d00, cmd=537163270, >>>>>>>>>>> data=0xe6499c70 "\002", flag=1, td=0xc3d3c880) >>>>>>>>>>> at /usr/src/sys/dev/syscons/syscons.c:1073 >>>>>>>>>>> #11 0xc051ed1a in giant_ioctl (dev=0xc3b20d00, >>>>>>>>>>> cmd=537163270, >>>>>>>>>>> data=0xe6499c70 "\002", fflag=1, td=0xc3d3c880) >>>>>>>>>>> at /usr/src/sys/kern/kern_conf.c:349 >>>>>>>>>>> #12 0xc0598194 in cnioctl (dev=0xc3b20d00, cmd=537163270, >>>>>>>>>>> data=0xe6499c70 "\002", flag=1, td=0xc3d3c880) >>>>>>>>>>> ---Type to continue, or q to quit--- >>>>>>>>>>> at /usr/src/sys/kern/tty_cons.c:521 >>>>>>>>>> Unless the virtual screen is opened, the screen state >>>>>>>>>> scr_stat structure >>>>>>>>>> is not allocated. The following patch would fix the panic, >>>>>>>>>> but I do not >>>>>>>>>> know how the console-kit would react to the ENXIO from the >>>>>>>>>> VT_WAITACTIVE ioctl. Please, test it. >>>>>>>>> Thanks! The patch works. >>>>>>>> >>>>>>>> To clarify: do you see any problems with the console-kit after >>>>>>>> the patch ? >>>>>>>> In particular, can you verify that the program functions >>>>>>>> correctly, esp. >>>>>>>> on the virtual terminals 1, 2 ... , whatever this means ? >>>>>>> >>>>>>> The panic is of course gone, while chatting a bit with Marcus >>>>>>> (CCd) it >>>>>>> looks like console-kit does not do any error handling at all. >>>>>>> I've not >>>>>>> looked at what c-k does so maybe Marcus can answer the question >>>>>>> better. >>>>>> >>>>>> It tries to install a wait thread on each available VT. That >>>>>> thread >>>>>> sets the WAITACTIVE ioctl, and waits for its VT to become >>>>>> active. When >>>>>> it does, it sets the CK active VT accordingly, and reattaches the >>>>>> wait. >>>>>> >>>>>> When an error occurs in the ioctl, no wait is attached, and CK >>>>>> will not >>>>>> know when a particular VT becomes active. This will essentially >>>>>> cripple >>>>>> CK (assuming the VT really does become available at a later >>>>>> point). >>>>>> >>>>>> Now, admittedly, there is no error correction in CK for this >>>>>> situation. >>>>>> It would be trivial to add something that periodically attempts >>>>>> to >>>>>> reestablish a failed wait. However, I am very curious why only a >>>>>> few >>>>>> users are seeing this panic (me excluded on two different >>>>>> machines). It >>>>>> seems to me that the scp should be initialized when >>>>>> sc_attach_unit() is >>>>>> called during device probing. I don't see anything special in >>>>>> init(8)'s >>>>>> code that would cause these VT devices to become initialized. I >>>>>> would >>>>>> assume that if one can open(2) them, then they should be >>>>>> available for >>>>>> ioctls? >>>>> >>>>> From my reading of the code, scp would be non-NULL after the first >>>>> open >>>>> of the corresponding /dev/ttyvX. sc_attach_unit() creates the scp >>>>> for >>>>> the console and the consolectl devices. >>>>> >>>>> VT_WAITACTIVE ioctl is performed on arbitrary syscons /dev node, >>>>> and >>>>> can wait for any other screens, in particular, the screens that >>>>> are >>>>> not opened at the moment (the reason for the reported panic). >>>> >>>> Right, and this is where I was confused. I had thought from an old >>>> reading of the CK code that CK opened each ttyvX device to perform >>>> the >>>> ioctl. It does not. Instead, it opens /dev/console, and performs >>>> the >>>> ioctl for each ttyvX on that fd. That does explain the panic, but >>>> not >>>> exactly why I did not see it. I'm guessing a race condition, but I >>>> can't be sure. >>>> >>>>> >>>>> The patch I posted may be improved by making the VT_WAITACTIVE >>>>> ioctl >>>>> to wait for the scp being allocated, and only then for the screen >>>>> to be >>>>> switched too. Please, test. >>>> >>>> I really appreciate your attention to this. Funny thing is, CK >>>> 0.2.4 >>>> was just released, and it is no longer started out of rc.d. I've >>>> also >>>> added error correcting in the CK code path. The problem may >>>> disappear >>>> depending on when CK is executed out of D-BUS. However, it would >>>> be >>>> good to prevent this in the kernel. Pawel said he would try and >>>> test >>>> this patch. >>> >>> This must be fixed in the kernel, at least because it allows any >>> console >>> user to panic the system. The question I have to you is what >>> approach shall >>> we use: >>> - return the ENXIO (1) >>> - do the wait for the open, then wait for the switch (2) >>> >>> I would prefer (1), both due to putting the decision to the >>> userspace, and >>> to not have the algorithm that could be implemented in userspace, in >>> the >>> kernel. On the other hand, as the maintainer of the one of the major >>> API >>> consumer there, you may have the different opinion, that is crusial. >> > From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:15:34 2008 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 03C5716A408 for ; Fri, 22 Feb 2008 17:15:34 +0000 (UTC) (envelope-from cs@legacy.schug.net) Received: from legacy.schug.net (legacy.schug.Net [194.97.148.165]) by mx1.freebsd.org (Postfix) with ESMTP id BD3DF13C474 for ; Fri, 22 Feb 2008 17:15:33 +0000 (UTC) (envelope-from cs@legacy.schug.net) Received: by legacy.schug.net (Postfix, from userid 10000) id B27C010F664E; Fri, 22 Feb 2008 18:15:31 +0100 (CET) Date: Fri, 22 Feb 2008 18:15:31 +0100 From: Christoph Schug To: Pyun YongHyeon Message-ID: <20080222171531.GE45806@lega.schug.net> References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> <20080222054103.GD30497@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222054103.GD30497@cdnetworks.co.kr> User-Agent: Mutt/1.5.13 OpenPKG/2-STABLE (2006-08-11) Cc: FreeBSD Current Subject: Re: Packet corruption in re0 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, 22 Feb 2008 17:15:34 -0000 On Fri, Feb 22, 2008, Pyun YongHyeon wrote: > Download if_re.c and if_rlreg.h in the following URL and rebuild the driver. > http://people.freebsd.org/~yongari/re/7.0R/if_re.c > http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h Hi, I stress tested my box using this driver all day long. Typically first problems show up after a few hours, but up to now using the new driver no problems at all anymore. Therefore I am very confident that at least my specific problem is being fixed. Nevertheless I will report back in a few days whether this status persists. Thanks again! -cs From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:18:59 2008 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 79E2816A409; Fri, 22 Feb 2008 17:18:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 44C7313C458; Fri, 22 Feb 2008 17:18:58 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1MHIsPx068700; Fri, 22 Feb 2008 12:18:54 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m1MHIrL6029816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 12:18:53 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802221718.m1MHIrL6029816@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 22 Feb 2008 12:18:56 -0500 To: Ken Smith , freebsd-current@freebsd.org, freebsd-stable From: Mike Tancsa In-Reply-To: <1203690542.10026.19.camel@bauer.cse.buffalo.edu> References: <1203690542.10026.19.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: FreeBSD 7.0-RC3 (for amd64/i386 only) Available 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, 22 Feb 2008 17:18:59 -0000 At 09:29 AM 2/22/2008, Ken Smith wrote: >If those who experienced problems related to the hptrr driver update >could let us know one way or another whether or not you are still having >problems with it that would be appreciated. Hi, I just did a fresh test install with RC3 on a HighPoint hptrr controller with 2 disks in RAID1 config and all looks good. hpoint# dmesg | grep hpt hptrr: HPT RocketRAID controller driver v1.1 (Feb 20 2008 18:33:35) hptrr0: port 0x2000-0x20ff mem 0x30100000-0x301fffff irq 16 at device 0.0 on pci1 hptrr: adapter at PCI 1:0:0, IRQ 16 hptrr: start channel [0,0] hptrr: start channel [0,1] hptrr: start channel [0,2] hptrr: start channel [0,3] hptrr: channel [0,2] started successfully hptrr: channel [0,3] started successfully hptrr: channel [0,0]: failed to perform Hard Reset hptrr: channel [0,1]: failed to perform Hard Reset hptrr0: [GIANT-LOCKED] hptrr0: [ITHREAD] da0 at hptrr0 bus 0 target 0 lun 0hpoint# hptrr0@pci0:1:0:0: class=0x010000 card=0x11ab11ab chip=0x23101103 rev=0x02 hdr=0x00 vendor = 'Triones Technologies Inc. (HighPoint)' device = 'RocketRAID 231x SATA Controller' class = mass storage subclass = SCSI cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[60] = PCI-Express 1 legacy endpoint hpoint# dd if=/dev/zero of=/tmp/junk bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 1.415491 secs (74078613 bytes/sec) hpoint# hpoint# uname -a FreeBSD hpoint.sentex.ca 7.0-RC3 FreeBSD 7.0-RC3 #0: Wed Feb 20 18:34:00 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 hpoint# From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:29:50 2008 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 7E7A816A402; Fri, 22 Feb 2008 17:29:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 2483A13C44B; Fri, 22 Feb 2008 17:29:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSbiS-000MKG-9V; Fri, 22 Feb 2008 19:29:48 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1MHTAKx071245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 19:29:10 +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.2/8.14.2) with ESMTP id m1MHTWhP095304; Fri, 22 Feb 2008 19:29:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1MHTUev095302; Fri, 22 Feb 2008 19:29:30 +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: Fri, 22 Feb 2008 19:29:30 +0200 From: Kostik Belousov To: Alexander Nedotsukov Message-ID: <20080222172930.GZ57756@deviant.kiev.zoral.com.ua> References: <4796356D.9080809@gmail.com> <20080123051648.GV57756@deviant.kiev.zoral.com.ua> <479796E1.4000500@gmail.com> <1201118159.38742.17.camel@shumai.marcuscom.com> <20080123211149.GA57756@deviant.kiev.zoral.com.ua> <1201123933.62127.9.camel@shumai.marcuscom.com> <20080124124213.GD57756@deviant.kiev.zoral.com.ua> <72E58ECA-D743-4D5E-9222-7129104E4BAC@bbnest.net> <20080221154714.GS57756@deviant.kiev.zoral.com.ua> <20CD87E3-27BC-4789-A51F-BBFDB3258B47@bbnest.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/CLVNuQCc5gNsroI" Content-Disposition: inline In-Reply-To: <20CD87E3-27BC-4789-A51F-BBFDB3258B47@bbnest.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 3f6c5f504711b4b2e39067d20b60c9d6 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2291 [Feb 22 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: yokota@freebsd.org, FreeBSD Current , Joe Marcus Marcus Clarke Subject: Re: page fault panic in scioctl and console-kit-daemon 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, 22 Feb 2008 17:29:50 -0000 --/CLVNuQCc5gNsroI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2008 at 01:01:59AM +0900, Alexander Nedotsukov wrote: >=20 > On 22.02.2008, at 0:47, Kostik Belousov wrote: >=20 > >On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov wrote: > >>Hi, > >> > >>May I ask to revisit this issue? To me ENXIO is not semantically > >>correct in this particular case. It also turns out that doing > >>workaround in userspace may not be that good as we used to think. I > >>propose is to fix VT_WAITACTIVE so it simply wait for bound device > >>activation. For my understanding this change should not have any > >>impact on existing code. I also removed really strange console =20 > >>cleanup > >>bit sticked in a long time ago (see ioctl() part). > >>It will be nice to see this patch > > > > > >>(successfully tested by our affected users) committed to all =20 > >>branches. > >> > >>Thanks, > >>Alexander. > > > >I mostly agree with the patch, given it is tested. > > > >The first (not important) note is that change of the wait channel from > >the address of the private structure to the address of the cdev could > >cause more spurious wakeups then before. I expect you usermode code to > >deal with it properly. > Do you know any potential wakeup()s around the kernel? I did not see =20 > any spurious wakeups myself nor user reported it so far. However they =20 > are not welcome so if it considered to be unsafe we can use address of = =20 > cdev pointer (&SC_DEV()) which is private to syscons. Nothing prevents any code in the the kernel from performing wakeup on any wait channel. Due to tradition, wait channel is usually an address of some data structure that is owned by the code performing wakeup. I do not know of any other code that uses cdev address as wait channel, The issue of spurious wakeup is not very important per se. I think more essential for the correct operation is the fact that when the user-mode code is executed, console may already be inactive (again). This is quite similar to the unintended wakeups. Does the code handle this ? If yes, I think it shall handle the wakeups too without any additional actions. I underline that this is not an objection against the patch. --/CLVNuQCc5gNsroI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke/BnoACgkQC3+MBN1Mb4jzZACcCTZFQLD6WbdRJJvBiJ6EUMQO XckAoLnJNLyW2hm9gsur4QqHIX05btMA =6GpF -----END PGP SIGNATURE----- --/CLVNuQCc5gNsroI-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 17:52:36 2008 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 68C2C16A402; Fri, 22 Feb 2008 17:52:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.77]) by mx1.freebsd.org (Postfix) with ESMTP id 4192613C478; Fri, 22 Feb 2008 17:52:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout014/MantshX 4.0) with ESMTP id m1MHqaTO005361; Fri, 22 Feb 2008 09:52:36 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp004/MantshX 4.0) with ESMTP id m1MHqXgx021997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2008 09:52:33 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Ruslan Ermilov In-Reply-To: <20080222102409.GD57428@team.vega.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 09:52:32 -0800 References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> X-Mailer: Apple Mail (2.919.2) Cc: current@freebsd.org, "Dag-Erling C. Smorgrav" , Kai Wang , Joseph Koshy Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 17:52:36 -0000 On Feb 22, 2008, at 2:24 AM, Ruslan Ermilov wrote: >>> - Handle upgrades nicely: use GNU ar(1) during the build on older >>> systems, and use BSD ar(1) on newer systems. >> >> If we need GNU ar for the upgrade path - then lets just install it >> (and >> its manage) as gnu-ar and let that be that. >> > I don't get you, GNU ar(1) is always installed. Only the name is > changes. But let me explain more about the upgrades. > > Currently, we always build binutils as part of cross-tools, including > GNU ar(1) and ranlib(1). These binaries are then used during the > build. > The BSD ar(1) doesn't need to be a cross-tool -- it doesn't depend on > TARGET_ARCH/TARGET and is platform-neutral. I'm very pleased to read this. Thank you Kai, Joseph and Tim of course! > Unfortunalely, since we provide the WITH_GNUAR option, we don't know > if > /usr/bin/ar and /usr/bin/ranlib are GNU or BSD versions, so we should > always bootstrap BSD ar(1). Can we determine this at runtime by running ar -v. If the output is more than 20 lines, it's GNU ar :-) Seriously: we could run ar --version (provided we add the support for that to BSD ar) and check the first word. It's either GNU or BSD (provided the output of BSD ar starts with BSD). This should eliminate any and all kind of guessing and should help in getting FreeBSD buildable on non-FreeBSD systems as well. Just a thought... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 18:10:11 2008 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 720A316A409 for ; Fri, 22 Feb 2008 18:10:11 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id 7A78613C46E for ; Fri, 22 Feb 2008 18:10:10 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so626662fka.11 for ; Fri, 22 Feb 2008 10:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=0j0o1OpE5RYf9v/S8DdNpEcNbP6ABNrQY612zncOGU4=; b=IhlugeAle9Jbm3y0/E8beNAc5h57z9W/G//6/9cK3ZMnEJ9Q4QgZlBpeiwavSTcJfEEoZnoXDrUAylefm/mF218xnxBkow6OiFcH2I/FhTiQ8Svgd60DRd/gpJOHt1g3qEmF4tAe5uA99/8Xx9zBE7ZqGndcm6kV6uHgGTsef0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=UhPmOPrB0ni+pyG+27XPGkRmpyrmm3BvRYRVOJMpD3R3cXxgs7UM8w/FeLepH1NvQwF/VXsakRkkdvkbYWZBXtH67qWDYLKR0u7A/r2lKvD/DLbLpVeZMquOiqPMXegufcSvXe8P8lfQ5rEigxF6zJIjA8Fpf3tP9OdKEXoyNQ8= Received: by 10.82.114.3 with SMTP id m3mr546747buc.2.1203703807702; Fri, 22 Feb 2008 10:10:07 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id z37sm2698698ikz.1.2008.02.22.10.10.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 10:10:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JScLI-0000nd-Cw; Fri, 22 Feb 2008 19:09:52 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1MI9qal003076; Fri, 22 Feb 2008 19:09:52 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Fri, 22 Feb 2008 19:09:52 +0100 From: Kai Wang To: Ruslan Ermilov Message-ID: <20080222180952.GB2622@plan0.kaiwan.csbnet.se> Mail-Followup-To: Ruslan Ermilov , obrien@freebsd.org, "Dag-Erling C. Smorgrav" , Joseph Koshy , current@freebsd.org References: <20080221131209.GA2022@plan0.kaiwan.csbnet.se> <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20080222102409.GD57428@team.vega.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joseph Koshy , "Dag-Erling C. Smorgrav" , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 18:10:11 -0000 On Fri, Feb 22, 2008 at 01:24:09PM +0300, Ruslan Ermilov wrote: > Currently, we always build binutils as part of cross-tools, including > GNU ar(1) and ranlib(1). These binaries are then used during the build. > The BSD ar(1) doesn't need to be a cross-tool -- it doesn't depend on > TARGET_ARCH/TARGET and is platform-neutral. (I hope I'm right about it, > otherwise it all doesn't make sense and cross-builds are broken.) That's true, platform-neutral ELF parsing is a feature of libelf. Kai From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 18:27:33 2008 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 999F916A402 for ; Fri, 22 Feb 2008 18:27:33 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 0B59413C4E9 for ; Fri, 22 Feb 2008 18:27:32 +0000 (UTC) (envelope-from kaiwang27@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so633412fka.11 for ; Fri, 22 Feb 2008 10:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=uF2K/LtCBdqOAK/PNynjiSDtGsS/tItJkkokjJgmk84=; b=eu3KbCCEXeQeB7Gu/eW6iO4C47G5XL7wQTZYiMIw6H4ZifU9rM7TdgRrvNN9HDqdfkfbVHtDmIa6bMuJdPltVxr4OJEAf8vlHm3pM+CP+0iB4L7hqGBGCt3+RyVnNO8HSjPfS5MXvU/+Lm9GM4MLdf/NSCB6RfbssfqoLMa92PA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=BQaTZMCDYO+vRIP34YnAsVPQkgjqxKttcH2gjziZ2k5Me7BWK8ej6sbKm0qLn+lpFbUhuxDhCBEDxpV9gnMGVZ4OWXX0PQMTF+JDwXr42HuNbFJ7nGEgd5BVenX7yc66cadH+Ddjm26rcDamRyFVDgqKUs4el/1tLcQzKofUzeA= Received: by 10.82.171.16 with SMTP id t16mr563581bue.11.1203704851239; Fri, 22 Feb 2008 10:27:31 -0800 (PST) Received: from plan0.kaiwan.csbnet.se ( [193.11.244.12]) by mx.google.com with ESMTPS id y34sm2749750iky.6.2008.02.22.10.27.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 10:27:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=plan0.kaiwan.csbnet.se) by plan0.kaiwan.csbnet.se with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JScc1-0000om-MJ; Fri, 22 Feb 2008 19:27:09 +0100 Received: (from kaffir@localhost) by plan0.kaiwan.csbnet.se (8.14.2/8.14.2/Submit) id m1MIR9qm003147; Fri, 22 Feb 2008 19:27:09 +0100 (CET) (envelope-from kaiwang27@gmail.com) X-Authentication-Warning: plan0.kaiwan.csbnet.se: kaffir set sender to kaiwang27@gmail.com using -f Date: Fri, 22 Feb 2008 19:27:09 +0100 From: Kai Wang To: Marcel Moolenaar Message-ID: <20080222182709.GC2622@plan0.kaiwan.csbnet.se> Mail-Followup-To: Marcel Moolenaar , Ruslan Ermilov , current@freebsd.org, "Dag-Erling C. Smorgrav" , Joseph Koshy References: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joseph Koshy , current@freebsd.org, "Dag-Erling C. Smorgrav" Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 18:27:33 -0000 On Fri, Feb 22, 2008 at 09:52:32AM -0800, Marcel Moolenaar wrote: >> Unfortunalely, since we provide the WITH_GNUAR option, we don't know if >> /usr/bin/ar and /usr/bin/ranlib are GNU or BSD versions, so we should >> always bootstrap BSD ar(1). > > Can we determine this at runtime by running ar -v. If ar -V > the output is more than 20 lines, it's GNU ar :-) That's true :-) > Seriously: we could run ar --version (provided we add > the support for that to BSD ar) and check the first > word. It's either GNU or BSD (provided the output of > BSD ar starts with BSD). Also true, in order to be more compatible with Binutils ar, we added long options support two weeks ago as suggested by Steve Kargl. Only two long option is supported: --version and --help, and --version output start with BSD. > This should eliminate any and all kind of guessing and > should help in getting FreeBSD buildable on non-FreeBSD > systems as well. > > Just a thought... well... I know little about build system, but this sounds to me like a "hack"... Also ru@ pointed out using /usr/bin/ar to build world is a bug, I think he's right and probably always bootstrap 'BSD' ar would be safer? > -- > Marcel Moolenaar > xcllnt@mac.com > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 18:55:45 2008 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 9A6CE16A401; Fri, 22 Feb 2008 18:55:45 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 85FA813C4E5; Fri, 22 Feb 2008 18:55:45 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp007-s [10.150.69.70]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id m1MItjek026845; Fri, 22 Feb 2008 10:55:45 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp007/MantshX 4.0) with ESMTP id m1MItg9a002483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2008 10:55:43 -0800 (PST) Message-Id: <50E680E4-4478-4932-925D-14291943732A@mac.com> From: Marcel Moolenaar To: Kai Wang In-Reply-To: <20080222182709.GC2622@plan0.kaiwan.csbnet.se> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 10:55:41 -0800 References: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222182709.GC2622@plan0.kaiwan.csbnet.se> X-Mailer: Apple Mail (2.919.2) Cc: Joseph Koshy , current@freebsd.org, "Dag-Erling C. Smorgrav" Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 18:55:45 -0000 On Feb 22, 2008, at 10:27 AM, Kai Wang wrote: >> This should eliminate any and all kind of guessing and >> should help in getting FreeBSD buildable on non-FreeBSD >> systems as well. >> >> Just a thought... > > well... I know little about build system, but this sounds to me > like a "hack"... Also ru@ pointed out using /usr/bin/ar to build > world is a bug, I think he's right and probably always bootstrap > 'BSD' ar would be safer? I disagree, because following along those lines, we should rebuild everything we possibly use for a build, including /bin/sh. We only need to deal with bootstrapping and for that we have the corresponding target. This means that if we don't have BSD ar on the system (or we have it, but it's missing features we use), we build it. Otherwise we just use it. Mind you: this is just expressing my view point. I don't care in particular how we end up implementing it... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 19:10:56 2008 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 80CC816A40B for ; Fri, 22 Feb 2008 19:10:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C87D13C4DD; Fri, 22 Feb 2008 19:10:53 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BF1E3B.80108@FreeBSD.org> Date: Fri, 22 Feb 2008 20:10:51 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Achilleas Mantzios References: <74067.1203596816@critter.freebsd.dk> <200802221147.45159.achill@matrix.gatewaynet.com> In-Reply-To: <200802221147.45159.achill@matrix.gatewaynet.com> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: Crazy md5, sha256, bzip2 behaviour, frequent crashes RAM problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 19:10:56 -0000 Achilleas Mantzios wrote: > Óôéò Thursday 21 February 2008 14:26:56 ï/ç Poul-Henning Kamp Ýãñáøå: >> In message <200802211406.40612.achill@matrix.gatewaynet.com>, Achilleas Mantzio >> s writes: >>> Hi, >>> i've struggling to build sysutils/coreutils and a crazy thing happens: >>> each time i do >>> fetch ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2 >>> and while ls -l gives the exact same size (5384378), md5,sha256 give different checksums each time! >> Bad hardware. >> > > Indeed. Changing memory dims and the port built/installed ok. > What worries me, is if i can trust the system as is, (while i have some 600 ports installed) > or rebuild everything. > artsd from kde behaves in a strange way (noatun skiping every 2nd second of mp3), > and i wander that if a rebuild of artsd solves the problem, then maybe i might worry > of the correctness of the whole system. It is very likely that many other things you created on this system (e.g. compiled binaries, modified files, etc) are also corrupted. A complete rebuild or reinstall would be a good idea. Kris From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:12:02 2008 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 1D56E16A407 for ; Fri, 22 Feb 2008 20:12:02 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id D0ACB13C45E for ; Fri, 22 Feb 2008 20:12:01 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id 8E04C28C5E2; Fri, 22 Feb 2008 21:12:00 +0100 (CET) Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id m1MKAmZd015733; Fri, 22 Feb 2008 21:10:48 +0100 (CET) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id m1MKAmU3015732; Fri, 22 Feb 2008 21:10:48 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Fri, 22 Feb 2008 21:10:48 +0100 To: John Marino Message-ID: <20080222201048.GA15563@saturn.kn-bremen.de> References: <43555.82.234.78.29.1203154742.squirrel@secure.synsport.net> <20080216175811.GA33393@saturn.kn-bremen.de> <47B7352B.1040302@marino.st> <20080216210731.GA40417@saturn.kn-bremen.de> <55528.82.234.78.29.1203252678.squirrel@secure.synsport.net> <20080217231126.GA68779@saturn.kn-bremen.de> <51702.82.234.78.29.1203318499.squirrel@secure.synsport.net> <20080221213945.GA97273@saturn.kn-bremen.de> <24097.195.169.141.54.1203676242.squirrel@secure.synsport.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24097.195.169.141.54.1203676242.squirrel@secure.synsport.net> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Fri, 22 Feb 2008 20:42:48 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 7.0 RC2 kernel panic with Kqemu/AMD64 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, 22 Feb 2008 20:12:02 -0000 On Fri, Feb 22, 2008 at 04:30:42AM -0600, John Marino wrote: > Hi Juergen, > If there is nobody capable of tracking down and fixing the problem, I > suggest that the kqemu-mod port be marked as i386 only, to prevent people > with systems like mine from installing it in the first place. It appears > that it is completely unusable for AMD64. Well, it does work when running on an uniprocessor kernel/machine... > I'm happy to continue to assist > and offer up my machine to help identify the problem(s) though, if the > qemu/freebsd community doesn't want to give up yet. Well, others are still more than welcome to attempt to debug/fix this of course. Juergen From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 20:54:08 2008 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 1FFF216A402 for ; Fri, 22 Feb 2008 20:54:08 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63909.mail.re1.yahoo.com (web63909.mail.re1.yahoo.com [69.147.97.124]) by mx1.freebsd.org (Postfix) with SMTP id B3F6413C458 for ; Fri, 22 Feb 2008 20:54:07 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 19015 invoked by uid 60001); 22 Feb 2008 20:54:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Z5CvaOieatuwzB+31Cd2Z25YcmW1TEdGR5BabwD4iECFK9xRIIzcUBz2AAtQUhl9aoaQ3ME0U/E0rl4h+G3YszHBbm9FI/WpzJTPQynXCywOC8ZDZE3eVN1wSYqoLQT6aAcy0t495ONTNAudQbOCw6B60ROI63buKhKrxjQUeoA=; X-YMail-OSG: 7R7qiUQVM1m4S8f1j1S5Rd.Behegw4_35didx_KfnQKuqkrxRSV3PpjmbCoTE4rxOV42h4T.AqgjjzfLioGF.SUtt0w.61G5HcKskk4GUkDIsuHqolUjoWyrFBDK5YCKbN5.RIc0BeYHjfq3eSu77DF_Gw-- Received: from [98.203.28.38] by web63909.mail.re1.yahoo.com via HTTP; Fri, 22 Feb 2008 12:54:06 PST Date: Fri, 22 Feb 2008 12:54:06 -0800 (PST) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <845250.18624.qm@web63909.mail.re1.yahoo.com> Cc: Subject: cpu usage in 7.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: Fri, 22 Feb 2008 20:54:08 -0000 I have a dual core system running 7.0 and I can't get top to show more than 100% usage no matter how I hammer it. My MAC shows over 100% often, but its not clear if top is averaging the 2 cpus or just not going over 100, or just showing 1 of the cpus. Is there any way to show the per-cpu usage to get an idea of the overall efficiency of sharing? Are there any tools that can be used to monitor this? What exactly is top showing? Thanks, Barney ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:13:19 2008 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 658CD16A405 for ; Fri, 22 Feb 2008 22:13:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 25D3513C447 for ; Fri, 22 Feb 2008 22:13:18 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C78AE2088; Fri, 22 Feb 2008 23:13:15 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4BFA02049; Fri, 22 Feb 2008 23:13:15 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 31A17844A2; Fri, 22 Feb 2008 23:13:15 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Alexandre \"Sunny\" Kovalenko" References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> <1203692492.63435.16.camel@RabbitsDen> Date: Fri, 22 Feb 2008 23:13:15 +0100 In-Reply-To: <1203692492.63435.16.camel@RabbitsDen> (Alexandre Kovalenko's message of "Fri\, 22 Feb 2008 10\:01\:32 -0500") Message-ID: <86ablsabd0.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svein-listmail@d80.iso100.no, freebsd-current , Mikael Ikivesi Subject: Re: 2 core dumps 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, 22 Feb 2008 22:13:19 -0000 "Alexandre \"Sunny\" Kovalenko" writes: > If I rephrase my point as > > "The fact that OS initiated shutdown because it thinks that your laptop > has reached certain temperature threshold does not necessarily mean that > your hardware is damaged." > > would you be more amenable to agreeing with it? No. On the other hand, the fact that your OS didn't initiate shutdown does not mean your hardware did not overheat. You told us yourself that parts of your laptop have been deformed and discolored by heat. Just face it: It's passed on. This laptop is no more. It has ceased to be. It's expired and gone to meet its maker. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to the desk it'd be pushing up the daisies. Its electronic processes are now history. It's off the twig. It's kicked the bucket, it's shuffled off its mortal coil, run down the curtain and joined the bleeding choir invisible. This is an ex-laptop. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:18:08 2008 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 83A3D16A407 for ; Fri, 22 Feb 2008 22:18:08 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail3.isdefe.es (mail3.isdefe.es [62.93.171.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA6513C4D1 for ; Fri, 22 Feb 2008 22:18:08 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from [IPv6:::1] (unknown [194.15.213.238]) by mail3.isdefe.es (Postfix) with ESMTP id B1580564BE; Fri, 22 Feb 2008 23:18:06 +0100 (CET) Message-ID: <47BF4A20.6070304@pop.isdefe.es> Date: Fri, 22 Feb 2008 23:18:08 +0100 From: Raul User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christoph Schug References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <20080221143748.GE10726@lega.schug.net> <47BE9910.7030501@pop.isdefe.es> In-Reply-To: <47BE9910.7030501@pop.isdefe.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Pyun YongHyeon , FreeBSD Current , Robert Backhaus Subject: Re: Packet corruption in re0 (and em0 too) 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, 22 Feb 2008 22:18:08 -0000 Quoting myself after some more testing ... Raul escribió: [....] > the same behavior happens. I left the box by night compiling CURRENT and > this morning I've run my 'stress tests' (once again with re0) ... the > box break to gdb as far I remember (too sleepy, sorry). Well, at least > no garbage over the link BD. Really sleepy, it was not gdb, just a LOR. If is anybody interested on it, I'll can reproduce it after a bit more tests with RELENG_7_0. > The fastest method I found to reproduce the problem is receive a > compresed tar (with good compression ratio) over the network (using nc, > 100 Mbps fdx), pipe through tar that decompress and write it on disk (a > lot of MB/s and tps looking at 'systat -vm'). The source tar file is > about 5Gb and link always fails before EOF :|. That's still true at least for RELENG_7_0 and re0. Nothing new I guess. I can't reproduce it with em0. Sorry for the noise. I'm going to try the proposed if_re.c and if_rlreg.h as Christoph is doing ... Regards, Raul From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:31:34 2008 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 AC9FA16A400 for ; Fri, 22 Feb 2008 22:31:34 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4644013C45E for ; Fri, 22 Feb 2008 22:31:34 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m1MMIDhA042164; Fri, 22 Feb 2008 23:18:14 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m1MMI7lJ080621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 23:18:08 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m1MMI7Qn087803; Fri, 22 Feb 2008 23:18:07 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m1MMI7sS087802; Fri, 22 Feb 2008 23:18:07 +0100 (CET) (envelope-from ticso) Date: Fri, 22 Feb 2008 23:18:07 +0100 From: Bernd Walter To: Barney Cordoba Message-ID: <20080222221806.GG80751@cicely12.cicely.de> References: <845250.18624.qm@web63909.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <845250.18624.qm@web63909.mail.re1.yahoo.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: current@freebsd.org Subject: Re: cpu usage in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 22:31:34 -0000 On Fri, Feb 22, 2008 at 12:54:06PM -0800, Barney Cordoba wrote: > I have a dual core system running 7.0 and I can't get > top to show more than 100% usage no matter how I > hammer it. My MAC shows over 100% often, but its not > clear if top is averaging the 2 cpus or just not going > over 100, or just showing 1 of the cpus. One CPU of a dual CPU system is only 50%. > Is there any way to show the per-cpu usage to get an > idea of the overall efficiency of sharing? Are there > any tools that can be used to monitor this? What > exactly is top showing? Each CPU has its own idle thread. You can see those system threads for example with top -S. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 22:53:50 2008 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 7D1BA16A400 for ; Fri, 22 Feb 2008 22:53:50 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1D33813C457 for ; Fri, 22 Feb 2008 22:53:49 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7da0.q.ppp-pool.de [89.53.125.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 2D4F3128844 for ; Fri, 22 Feb 2008 23:53:42 +0100 (CET) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 08D523F64C; Fri, 22 Feb 2008 23:52:01 +0100 (CET) Message-ID: <47BF525C.6010300@vwsoft.com> Date: Fri, 22 Feb 2008 23:53:16 +0100 From: Volker User-Agent: Thunderbird 2.0.0.9 (X11/20080125) MIME-Version: 1.0 To: Achilleas Mantzios References: <74067.1203596816@critter.freebsd.dk> <200802221147.45159.achill@matrix.gatewaynet.com> In-Reply-To: <200802221147.45159.achill@matrix.gatewaynet.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit MailScanner-NULL-Check: 1204325532.99793@K9X49Yyu6Xjt9j3crr9LLQ X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: Re: Crazy md5, sha256, bzip2 behaviour, frequent crashes RAM problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 22:53:50 -0000 On 12/23/-58 20:59, Achilleas Mantzios wrote: > Óôéò Thursday 21 February 2008 14:26:56 ï/ç Poul-Henning Kamp Ýãñáøå: >> In message <200802211406.40612.achill@matrix.gatewaynet.com>, Achilleas Mantzio >> s writes: >>> Hi, >>> i've struggling to build sysutils/coreutils and a crazy thing happens: >>> each time i do >>> fetch ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2 >>> and while ls -l gives the exact same size (5384378), md5,sha256 give different checksums each time! >> Bad hardware. >> > > Indeed. Changing memory dims and the port built/installed ok. > What worries me, is if i can trust the system as is, (while i have some 600 ports installed) > or rebuild everything. > artsd from kde behaves in a strange way (noatun skiping every 2nd second of mp3), > and i wander that if a rebuild of artsd solves the problem, then maybe i might worry > of the correctness of the whole system. Recompiling your ports would be best but you may check installed ports first by using `/usr/ports/Tools/scripts/consistency-check' (an often overseen script). Please expect a lot of error messages as this script does the handling of symlinked files wrong (I wanted to write a patch for that problem long time ago...). You may also try a consitency check by using a shell script written by me, which is badly slow, but works similar to consistency-check: http://bsd.vwsoft.com/files/pkgcheckhealth In any doubt it is recommended to recompile ports. HTH Volker From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 23:13:08 2008 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 AF21816A403 for ; Fri, 22 Feb 2008 23:13:08 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F78313C448; Fri, 22 Feb 2008 23:13:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BF5702.3020204@FreeBSD.org> Date: Sat, 23 Feb 2008 00:13:06 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Barney Cordoba References: <845250.18624.qm@web63909.mail.re1.yahoo.com> In-Reply-To: <845250.18624.qm@web63909.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: cpu usage in 7.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: Fri, 22 Feb 2008 23:13:08 -0000 Barney Cordoba wrote: > I have a dual core system running 7.0 and I can't get > top to show more than 100% usage no matter how I > hammer it. My MAC shows over 100% often, but its not > clear if top is averaging the 2 cpus or just not going > over 100, or just showing 1 of the cpus. 100% in FreeBSD means "all of your CPUs are completely active". It is hard to exceed this amount :-) > Is there any way to show the per-cpu usage to get an > idea of the overall efficiency of sharing? Are there > any tools that can be used to monitor this? What > exactly is top showing? Not in 7.0. 8.0 supports top -P and vmstat -P Kris From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 23:15:41 2008 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 0C52516A402; Fri, 22 Feb 2008 23:15:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id C3D3913C4D9; Fri, 22 Feb 2008 23:15:35 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 1840B209E; Sat, 23 Feb 2008 00:15:32 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id EF8A8209D; Sat, 23 Feb 2008 00:15:31 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id CA11984466; Sat, 23 Feb 2008 00:15:31 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Marcel Moolenaar References: <20080221140247.GC2022@plan0.kaiwan.csbnet.se> <20080221143351.GP57756@deviant.kiev.zoral.com.ua> <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <20080222093234.GB17107@dragon.NUXI.org> <20080222102409.GD57428@team.vega.ru> <20080222182709.GC2622@plan0.kaiwan.csbnet.se> <50E680E4-4478-4932-925D-14291943732A@mac.com> Date: Sat, 23 Feb 2008 00:15:31 +0100 In-Reply-To: <50E680E4-4478-4932-925D-14291943732A@mac.com> (Marcel Moolenaar's message of "Fri\, 22 Feb 2008 10\:55\:41 -0800") Message-ID: <86skzk8tws.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , Kai Wang , current@freebsd.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 22 Feb 2008 23:15:41 -0000 Marcel Moolenaar writes: > I disagree, because following along those lines, we should rebuild > everything we possibly use for a build, including /bin/sh. Yes, that's exactly what we do. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 00:09:58 2008 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 162C716A400 for ; Sat, 23 Feb 2008 00:09:58 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail3.isdefe.es (mail3.isdefe.es [62.93.171.234]) by mx1.freebsd.org (Postfix) with ESMTP id D24A213C459 for ; Sat, 23 Feb 2008 00:09:57 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from [IPv6:::1] (unknown [194.15.213.238]) by mail3.isdefe.es (Postfix) with ESMTP id 8DD1E564B4; Sat, 23 Feb 2008 01:09:56 +0100 (CET) Message-ID: <47BF6455.2020603@pop.isdefe.es> Date: Sat, 23 Feb 2008 01:09:57 +0100 From: Raul User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> <20080222054103.GD30497@cdnetworks.co.kr> In-Reply-To: <20080222054103.GD30497@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: Packet corruption in re0 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, 23 Feb 2008 00:09:58 -0000 Pyun YongHyeon escribió: > Download if_re.c and if_rlreg.h in the following URL and rebuild the driver. > http://people.freebsd.org/~yongari/re/7.0R/if_re.c > http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h I've tested it against my 'netcat | tar' and it improves as it takes four iterations (instead of one) to fall down (nearly unusable). I've not run it so many times in a row on CURRENT. Must I try it again?. That's what pciconf says about my re0: re0@pci0:2:15:0: class=0x020000 card=0xe0001458 chip=0x816710ec rev=0x10 hdr=0x00 Regards, Raul From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 02:31:52 2008 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 D10AC16A401 for ; Sat, 23 Feb 2008 02:31:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id 684F313C448 for ; Sat, 23 Feb 2008 02:31:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so970271wri.3 for ; Fri, 22 Feb 2008 18:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=pg7vKsfP4PPgBk82xpaBixN9upEDbwUwiArxcLJ8rN0=; b=YsEeEYINQwokClNMnepbrdiHvQCnhlC64v43eks0QJkxXg9nvy64a4BQiRWQy5u7Y1sqUJj5FD7PoSJezsHzv9J5ZxwCXKh4IDVMlW/xRcBNUnUvQnu4Xf2GnHFXj4d/wnTz964WDFDHZjPjinGJuX8lhqX8m7XECuLiHeDZzIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Wa61HHLEg2OFzdheuEJRNFlS5swypPToNZVAEuJ7qXzNobW8ncntsUhjIFKEAay73Xj62olIgwxTa0vEuAutHEiR+xjpI7GlI/1kdVy84qeap5sqFW04XTRd2nizXdU0x4j4VikxdSvF2zlxPFtdcTNagK39ll23UFDXurz5IwA= Received: by 10.142.229.4 with SMTP id b4mr654676wfh.125.1203733910421; Fri, 22 Feb 2008 18:31:50 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 22sm3673010wfg.15.2008.02.22.18.31.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 18:31:49 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1N2VimA035460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2008 11:31:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1N2VgkL035459; Sat, 23 Feb 2008 11:31:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 23 Feb 2008 11:31:42 +0900 From: Pyun YongHyeon To: Raul Message-ID: <20080223023142.GA35336@cdnetworks.co.kr> References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> <20080222054103.GD30497@cdnetworks.co.kr> <47BF6455.2020603@pop.isdefe.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BF6455.2020603@pop.isdefe.es> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: Packet corruption in re0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 02:31:52 -0000 On Sat, Feb 23, 2008 at 01:09:57AM +0100, Raul wrote: > Pyun YongHyeon escribi?: > > >Download if_re.c and if_rlreg.h in the following URL and rebuild the > >driver. > >http://people.freebsd.org/~yongari/re/7.0R/if_re.c > >http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h > > I've tested it against my 'netcat | tar' and it improves as it takes > four iterations (instead of one) to fall down (nearly unusable). I've > not run it so many times in a row on CURRENT. Must I try it again?. > That's what pciconf says about my re0: > > re0@pci0:2:15:0: class=0x020000 card=0xe0001458 chip=0x816710ec > rev=0x10 hdr=0x00 > How about disabling checksum offload on re0 side? > Regards, > Raul > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 03:08:28 2008 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 7AF0016A408; Sat, 23 Feb 2008 03:08:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3240D13C45B; Sat, 23 Feb 2008 03:08:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N38RPd069270; Fri, 22 Feb 2008 22:08:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N38Q8q019712; Fri, 22 Feb 2008 22:08:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A01B973039; Fri, 22 Feb 2008 22:08:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223030826.A01B973039@freebsd-current.sentex.ca> Date: Fri, 22 Feb 2008 22:08:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 03:08:28 -0000 TB --- 2008-02-23 02:04:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 02:04:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-23 02:04:49 - cleaning the object tree TB --- 2008-02-23 02:05:19 - cvsupping the source tree TB --- 2008-02-23 02:05:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-23 02:05:27 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 02:05:27 - cd /src TB --- 2008-02-23 02:05:27 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 02:05:29 UTC 2008 >>> 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 Sat Feb 23 03:04:58 UTC 2008 TB --- 2008-02-23 03:04:58 - generating LINT kernel config TB --- 2008-02-23 03:04:58 - cd /src/sys/sparc64/conf TB --- 2008-02-23 03:04:58 - /usr/bin/make -B LINT TB --- 2008-02-23 03:04:58 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 03:04:58 - cd /src TB --- 2008-02-23 03:04:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 03:04:58 UTC 2008 >>> 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 -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 -Werror /src/sys/dev/cm/smc90cx6.c cc -c -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 -Werror /src/sys/dev/cnw/if_cnw.c cc -c -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 -Werror /src/sys/dev/cxgb/cxgb_main.c cc -c -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 -Werror /src/sys/dev/cxgb/cxgb_offload.c cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_offload.c: In function 'do_bad_cpl': /src/sys/dev/cxgb/cxgb_offload.c:974: warning: implicit declaration of function 'kdb_backtrace' /src/sys/dev/cxgb/cxgb_offload.c:974: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 03:08:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 03:08:26 - ERROR: failed to build lint kernel TB --- 2008-02-23 03:08:26 - tinderbox aborted TB --- 2767.02 user 353.27 system 3817.13 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 03:25:43 2008 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 0C39A16A402; Sat, 23 Feb 2008 03:25:43 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id D287913C469; Sat, 23 Feb 2008 03:25:42 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id 0D8DB10B0; Sat, 23 Feb 2008 03:11:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id LUDUf6lHlH8V; Sat, 23 Feb 2008 03:10:35 +0000 (UTC) Received: from nexus.bsdlan.org (a213-22-25-165.cpe.netcabo.pt [213.22.25.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id 2156010AB; Sat, 23 Feb 2008 03:10:34 +0000 (UTC) Message-ID: <47BF8EB7.9090007@barafranca.com> Date: Sat, 23 Feb 2008 03:10:47 +0000 From: Hugo Silva User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> In-Reply-To: <47BF5702.3020204@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kris Kennaway Subject: Re: cpu usage in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 03:25:43 -0000 Kris Kennaway wrote: > Barney Cordoba wrote: >> I have a dual core system running 7.0 and I can't get >> top to show more than 100% usage no matter how I >> hammer it. My MAC shows over 100% often, but its not >> clear if top is averaging the 2 cpus or just not going >> over 100, or just showing 1 of the cpus. > > 100% in FreeBSD means "all of your CPUs are completely active". It is > hard to exceed this amount :-) You should see my production mysql going over 458% on service startup, on a quad core server :-) > >> Is there any way to show the per-cpu usage to get an >> idea of the overall efficiency of sharing? Are there >> any tools that can be used to monitor this? What >> exactly is top showing? > > Not in 7.0. 8.0 supports top -P and vmstat -P > > Kris 11 root 1 171 ki31 0K 16K CPU3 3 81.1H 100.00% idle: cpu3 12 root 1 171 ki31 0K 16K CPU2 2 81.0H 100.00% idle: cpu2 13 root 1 171 ki31 0K 16K CPU1 1 80.9H 100.00% idle: cpu1 14 root 1 171 ki31 0K 16K RUN 0 80.3H 100.00% idle: cpu0 top -S (7.0-RC2) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 03:37:08 2008 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 C4BA716A401; Sat, 23 Feb 2008 03:37:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9167413C4EA; Sat, 23 Feb 2008 03:37:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N3b75F020808; Fri, 22 Feb 2008 22:37:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N3b7J4037740; Fri, 22 Feb 2008 22:37:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 858EF73039; Fri, 22 Feb 2008 22:37:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223033707.858EF73039@freebsd-current.sentex.ca> Date: Fri, 22 Feb 2008 22:37:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 03:37:08 -0000 TB --- 2008-02-23 02:38:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 02:38:43 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-23 02:38:43 - cleaning the object tree TB --- 2008-02-23 02:39:08 - cvsupping the source tree TB --- 2008-02-23 02:39:08 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-23 02:39:15 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 02:39:15 - cd /src TB --- 2008-02-23 02:39:15 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 02:39:17 UTC 2008 >>> 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 Sat Feb 23 03:34:23 UTC 2008 TB --- 2008-02-23 03:34:23 - generating LINT kernel config TB --- 2008-02-23 03:34:23 - cd /src/sys/sun4v/conf TB --- 2008-02-23 03:34:23 - /usr/bin/make -B LINT TB --- 2008-02-23 03:34:23 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 03:34:23 - cd /src TB --- 2008-02-23 03:34:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 03:34:23 UTC 2008 >>> 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 -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 -Werror /src/sys/dev/cm/smc90cx6.c cc -c -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 -Werror /src/sys/dev/cnw/if_cnw.c cc -c -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 -Werror /src/sys/dev/cxgb/cxgb_main.c cc -c -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 -Werror /src/sys/dev/cxgb/cxgb_offload.c cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_offload.c: In function 'do_bad_cpl': /src/sys/dev/cxgb/cxgb_offload.c:974: warning: implicit declaration of function 'kdb_backtrace' /src/sys/dev/cxgb/cxgb_offload.c:974: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 03:37:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 03:37:07 - ERROR: failed to build lint kernel TB --- 2008-02-23 03:37:07 - tinderbox aborted TB --- 2755.09 user 347.24 system 3503.84 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 07:40:51 2008 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 0D6EA16A401; Sat, 23 Feb 2008 07:40:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C66E013C4CE; Sat, 23 Feb 2008 07:40:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N7enWn027999; Sat, 23 Feb 2008 02:40:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N7enPo061028; Sat, 23 Feb 2008 02:40:49 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 79D3073039; Sat, 23 Feb 2008 02:40:49 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223074049.79D3073039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 02:40:49 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 07:40:51 -0000 TB --- 2008-02-23 06:23:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 06:23:49 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-23 06:23:49 - cleaning the object tree TB --- 2008-02-23 06:24:18 - cvsupping the source tree TB --- 2008-02-23 06:24:18 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-23 06:24:25 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 06:24:25 - cd /src TB --- 2008-02-23 06:24:25 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 06:24:27 UTC 2008 >>> 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 Sat Feb 23 07:36:17 UTC 2008 TB --- 2008-02-23 07:36:17 - generating LINT kernel config TB --- 2008-02-23 07:36:17 - cd /src/sys/ia64/conf TB --- 2008-02-23 07:36:17 - /usr/bin/make -B LINT TB --- 2008-02-23 07:36:17 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 07:36:17 - cd /src TB --- 2008-02-23 07:36:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 07:36:17 UTC 2008 >>> 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 -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/cm/smc90cx6.c cc -c -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/cnw/if_cnw.c cc -c -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/cxgb/cxgb_main.c cc -c -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/cxgb/cxgb_offload.c cc1: warnings being treated as errors /src/sys/dev/cxgb/cxgb_offload.c: In function 'do_bad_cpl': /src/sys/dev/cxgb/cxgb_offload.c:974: warning: implicit declaration of function 'kdb_backtrace' /src/sys/dev/cxgb/cxgb_offload.c:974: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 07:40:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 07:40:49 - ERROR: failed to build lint kernel TB --- 2008-02-23 07:40:49 - tinderbox aborted TB --- 3409.16 user 373.09 system 4619.97 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 08:31:23 2008 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 C39A716A401; Sat, 23 Feb 2008 08:31:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 88D7713C4CE; Sat, 23 Feb 2008 08:31:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N8VMf7029548; Sat, 23 Feb 2008 03:31:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N8VMu0033539; Sat, 23 Feb 2008 03:31:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CE21173039; Sat, 23 Feb 2008 03:31:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223083122.CE21173039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 03:31:22 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 08:31:23 -0000 TB --- 2008-02-23 07:17:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 07:17:23 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-23 07:17:23 - cleaning the object tree TB --- 2008-02-23 07:17:53 - cvsupping the source tree TB --- 2008-02-23 07:17:53 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-23 07:18:00 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 07:18:00 - cd /src TB --- 2008-02-23 07:18:00 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 07:18:01 UTC 2008 >>> 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 Sat Feb 23 08:23:16 UTC 2008 TB --- 2008-02-23 08:23:16 - generating LINT kernel config TB --- 2008-02-23 08:23:16 - cd /src/sys/powerpc/conf TB --- 2008-02-23 08:23:16 - /usr/bin/make -B LINT TB --- 2008-02-23 08:23:17 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 08:23:17 - cd /src TB --- 2008-02-23 08:23:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 08:23:17 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc/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 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc/src/sys/LINT -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 08:31:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 08:31:22 - ERROR: failed to build lint kernel TB --- 2008-02-23 08:31:22 - tinderbox aborted TB --- 3182.31 user 371.84 system 4439.34 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 08:57:20 2008 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 ECE6F16A401; Sat, 23 Feb 2008 08:57:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8988013C474; Sat, 23 Feb 2008 08:57:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N8vJwI030267; Sat, 23 Feb 2008 03:57:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N8vJ9j007389; Sat, 23 Feb 2008 03:57:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 85A2873039; Sat, 23 Feb 2008 03:57:19 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223085719.85A2873039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 03:57:19 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 08:57:21 -0000 TB --- 2008-02-23 07:40:49 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 07:40:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-23 07:40:49 - cleaning the object tree TB --- 2008-02-23 07:41:09 - cvsupping the source tree TB --- 2008-02-23 07:41:09 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-23 07:41:14 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 07:41:14 - cd /src TB --- 2008-02-23 07:41:14 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 07:41:16 UTC 2008 >>> 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 Sat Feb 23 08:48:38 UTC 2008 TB --- 2008-02-23 08:48:38 - generating LINT kernel config TB --- 2008-02-23 08:48:38 - cd /src/sys/sparc64/conf TB --- 2008-02-23 08:48:38 - /usr/bin/make -B LINT TB --- 2008-02-23 08:48:39 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 08:48:39 - cd /src TB --- 2008-02-23 08:48:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 08:48:39 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/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/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 08:57:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 08:57:19 - ERROR: failed to build lint kernel TB --- 2008-02-23 08:57:19 - tinderbox aborted TB --- 3018.85 user 372.84 system 4589.99 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 09:05:24 2008 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 AB39316A402 for ; Sat, 23 Feb 2008 09:05:24 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC6CB13C442; Sat, 23 Feb 2008 09:05:23 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BFB70F.5080402@FreeBSD.org> Date: Sat, 23 Feb 2008 07:02:55 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Hugo Silva References: <845250.18624.qm@web63909.mail.re1.yahoo.com> <47BF5702.3020204@FreeBSD.org> <47BF8EB7.9090007@barafranca.com> In-Reply-To: <47BF8EB7.9090007@barafranca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: cpu usage in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 09:05:24 -0000 Hugo Silva wrote: > Kris Kennaway wrote: >> Barney Cordoba wrote: >>> I have a dual core system running 7.0 and I can't get >>> top to show more than 100% usage no matter how I >>> hammer it. My MAC shows over 100% often, but its not >>> clear if top is averaging the 2 cpus or just not going >>> over 100, or just showing 1 of the cpus. >> >> 100% in FreeBSD means "all of your CPUs are completely active". It is >> hard to exceed this amount :-) > > You should see my production mysql going over 458% on service startup, > on a quad core server :-) That is a multithreaded process using multiple CPUs, not the total CPU statistics (first line of top(1)). Kris From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 09:12:49 2008 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 B2ECB16A402 for ; Sat, 23 Feb 2008 09:12:49 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from centos.daemoninthecloset.org (centos.daemoninthecloset.org [207.210.113.195]) by mx1.freebsd.org (Postfix) with ESMTP id 77DB813C447 for ; Sat, 23 Feb 2008 09:12:49 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from zimbra.daemoninthecloset.org (zimbra.daemoninthecloset.org [65.110.225.155]) by centos.daemoninthecloset.org (Postfix) with ESMTP id B73DC5400F for ; Sat, 23 Feb 2008 03:50:08 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.daemoninthecloset.org (Postfix) with ESMTP id AB2CE41AC for ; Sat, 23 Feb 2008 02:50:08 -0600 (CST) X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=-1.300, BAYES_50=0.001] Received: from zimbra.daemoninthecloset.org ([127.0.0.1]) by localhost (zimbra.daemoninthecloset.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq3Eq1EGx6V4 for ; Sat, 23 Feb 2008 02:50:07 -0600 (CST) Received: from zimbra.daemoninthecloset.org (zimbra.daemoninthecloset.org [192.168.1.225]) by zimbra.daemoninthecloset.org (Postfix) with ESMTP id D79FD4168 for ; Sat, 23 Feb 2008 02:50:07 -0600 (CST) Date: Sat, 23 Feb 2008 02:50:07 -0600 (CST) From: Bryan Venteicher To: freebsd-current@freebsd.org Message-ID: <330977318.1351203756607522.JavaMail.root@zimbra> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.1.1] Subject: panic: lock (smbsm) lockmgr does not match earlier (sleep mutex) lock 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, 23 Feb 2008 09:12:49 -0000 Hi, I receive the following panic "lock (smbsm) lockmgr does not match earlier (sleep mutex) lock" when loading the smbfs module on a recent current. Kernel dumps weren't configured on the particular machine. Here's the abbreviated relevant portions of the stack: ... nsmb_dev_load smb_sm_init smb_co_init ... enroll panic In smb_co_init(), the same description/name is used to initialize both cp->co_interlock and cp->co_lock. From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 09:37:20 2008 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 00F7716A404 for ; Sat, 23 Feb 2008 09:37:20 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 09FC913C442; Sat, 23 Feb 2008 09:37:17 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BFE94D.1070800@FreeBSD.org> Date: Sat, 23 Feb 2008 10:37:17 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bryan Venteicher References: <330977318.1351203756607522.JavaMail.root@zimbra> In-Reply-To: <330977318.1351203756607522.JavaMail.root@zimbra> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: lock (smbsm) lockmgr does not match earlier (sleep mutex) lock 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, 23 Feb 2008 09:37:20 -0000 Bryan Venteicher wrote: > Hi, > > I receive the following panic "lock (smbsm) lockmgr does not match earlier (sleep mutex) lock" when loading the smbfs module on a recent current. > > Kernel dumps weren't configured on the particular machine. Here's the abbreviated relevant portions of the stack: > ... > nsmb_dev_load > smb_sm_init > smb_co_init > ... > enroll > panic > > In smb_co_init(), the same description/name is used to initialize both cp->co_interlock and cp->co_lock. Fix is probably to just rename one so witness doesn't get confused :) Kris From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 09:39:33 2008 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 1E85016A401; Sat, 23 Feb 2008 09:39:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D7EE513C465; Sat, 23 Feb 2008 09:39:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N9dWuj031672; Sat, 23 Feb 2008 04:39:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1N9dWeU092302; Sat, 23 Feb 2008 04:39:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 07D6473039; Sat, 23 Feb 2008 04:39:32 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223093932.07D6473039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 04:39:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 09:39:33 -0000 TB --- 2008-02-23 08:31:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 08:31:23 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-23 08:31:23 - cleaning the object tree TB --- 2008-02-23 08:31:51 - cvsupping the source tree TB --- 2008-02-23 08:31:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-23 08:31:57 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 08:31:57 - cd /src TB --- 2008-02-23 08:31:57 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 08:31:58 UTC 2008 >>> 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 Sat Feb 23 09:30:05 UTC 2008 TB --- 2008-02-23 09:30:05 - generating LINT kernel config TB --- 2008-02-23 09:30:05 - cd /src/sys/sun4v/conf TB --- 2008-02-23 09:30:05 - /usr/bin/make -B LINT TB --- 2008-02-23 09:30:05 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 09:30:05 - cd /src TB --- 2008-02-23 09:30:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 09:30:06 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -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 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** 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 --- 2008-02-23 09:39:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 09:39:31 - ERROR: failed to build lint kernel TB --- 2008-02-23 09:39:31 - tinderbox aborted TB --- 2992.56 user 363.16 system 4089.00 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 12:18:49 2008 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 A879116A402 for ; Sat, 23 Feb 2008 12:18:49 +0000 (UTC) (envelope-from svein-listmail@d80.iso100.no) Received: from d80.iso100.no (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 52E9A13C442 for ; Sat, 23 Feb 2008 12:18:49 +0000 (UTC) (envelope-from svein-listmail@d80.iso100.no) Received: from localhost (unknown [127.0.0.1]) by d80.iso100.no (Familien Skogens mail) with ESMTP id 56B104504F; Sat, 23 Feb 2008 13:18:47 +0100 (CET) X-Virus-Scanned: amavisd-new at d80.iso100.no Received: from d80.iso100.no ([127.0.0.1]) by localhost (d80.iso100.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XHW5kXDQZdl; Sat, 23 Feb 2008 13:18:41 +0100 (CET) Received: from [192.168.4.3] (unknown [192.168.4.3]) (Authenticated sender: svein) by d80.iso100.no (Familien Skogens mail) with ESMTP id C2F7A4503F; Sat, 23 Feb 2008 13:18:41 +0100 (CET) Message-ID: <47C00F20.2090700@d80.iso100.no> Date: Sat, 23 Feb 2008 13:18:40 +0100 From: Svein Skogen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <20080219104532.0dc2b565@chaos.nox> <47BDB92C.9050808@d80.iso100.no> <20080222113646.2dbb9ec1@chaos.nox> <86zlttqmc9.fsf@ds4.des.no> <1203686245.63435.12.camel@RabbitsDen> <86oda9oxxe.fsf@ds4.des.no> <1203692492.63435.16.camel@RabbitsDen> <86ablsabd0.fsf@ds4.des.no> In-Reply-To: <86ablsabd0.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current , "Alexandre \"Sunny\" Kovalenko" , Mikael Ikivesi Subject: Re: 2 core dumps 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, 23 Feb 2008 12:18:49 -0000 Dag-Erling Smørgrav wrote: > "Alexandre \"Sunny\" Kovalenko" writes: >> If I rephrase my point as >> >> "The fact that OS initiated shutdown because it thinks that your laptop >> has reached certain temperature threshold does not necessarily mean that >> your hardware is damaged." >> >> would you be more amenable to agreeing with it? > > No. > > On the other hand, the fact that your OS didn't initiate shutdown does > not mean your hardware did not overheat. > > You told us yourself that parts of your laptop have been deformed and > discolored by heat. *SNIP!* I (almost) concur to this view. However, this MAY be more a prediction of what's coming, than a description of what is now. Discolored parts, plastic parts (presumably parts close to the airflow in the laptop) are usually a sign of A) a total breakdown, or B) a breakdown in progress. Those deformed parts necessarily changes the airflow, and as such reduces the laptops chances of cooling itself. At the same time, the discolored parts tells of electronics going way beyond their intended temperature, and this gives us another clue: Oxydation of metals. Oxydated metals simply does not offer the same conductivity as the original alloy did. Thus, they generate more heat (increased resistance, ohms law). The combination of reduced cooling capability, AND increased heat generated, means that the frequency of your problems will simply increase. Period. Since the laptop is a little slow in understanding that it's now doomed, I suggest you utilize the remaining minutes of operation to back up your data, and web-shop for a new laptop. This one is spent. Regards, Svein Skogen p.s. I've done my share of trying to deny the truth of hardware being defective. It didn't work, the hardware was just as dead as before I denied it being dead. From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 12:56:57 2008 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 D77F416A403 for ; Sat, 23 Feb 2008 12:56:57 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from mail3.isdefe.es (mail3.isdefe.es [62.93.171.234]) by mx1.freebsd.org (Postfix) with ESMTP id 8852313C455 for ; Sat, 23 Feb 2008 12:56:57 +0000 (UTC) (envelope-from raul@pop.isdefe.es) Received: from [IPv6:::1] (unknown [194.15.213.238]) by mail3.isdefe.es (Postfix) with ESMTP id 4D1FA564AE; Sat, 23 Feb 2008 13:56:56 +0100 (CET) Message-ID: <47C01818.2090704@pop.isdefe.es> Date: Sat, 23 Feb 2008 13:56:56 +0100 From: Raul User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080221035014.GB26427@cdnetworks.co.kr> <20080221050635.GC26427@cdnetworks.co.kr> <47BDBB1A.9040701@andric.com> <47BE2FEF.7010709@andric.com> <20080222041715.GA30497@cdnetworks.co.kr> <20080222054103.GD30497@cdnetworks.co.kr> <47BF6455.2020603@pop.isdefe.es> <20080223023142.GA35336@cdnetworks.co.kr> In-Reply-To: <20080223023142.GA35336@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current Subject: Re: Packet corruption in re0 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, 23 Feb 2008 12:56:57 -0000 Pyun YongHyeon escribió: [....] > > >Download if_re.c and if_rlreg.h in the following URL and rebuild the > > >driver. > > >http://people.freebsd.org/~yongari/re/7.0R/if_re.c > > >http://people.freebsd.org/~yongari/re/7.0R/if_rlreg.h > > > > I've tested it against my 'netcat | tar' and it improves as it takes > > four iterations (instead of one) to fall down (nearly unusable). I've > > not run it so many times in a row on CURRENT. Must I try it again?. > > That's what pciconf says about my re0: > > > > re0@pci0:2:15:0: class=0x020000 card=0xe0001458 chip=0x816710ec > > rev=0x10 hdr=0x00 > > > > How about disabling checksum offload on re0 side? After 6 iterations everything looked good so I started to do other things while the netcat was running (build ports). Shortly after (seconds), the problems appear again. Now, I'm not sure how reliable the testing procedure is and there are other issues with the chipset (AMD 690G), usb support problems, the sata subsystem is not well recognized ... I've seen also problems on this box while using em0 so too complex environment to isolate the possible re0 problem. While I'll be glad to test whatever you ask me for, too loose ends on this box nowadays. Regards, Raul From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 13:47:30 2008 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 0FF0416A402; Sat, 23 Feb 2008 13:47:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id C0F3D13C45D; Sat, 23 Feb 2008 13:47:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NDlSdj095943; Sat, 23 Feb 2008 08:47:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NDlSol090961; Sat, 23 Feb 2008 08:47:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 455F273039; Sat, 23 Feb 2008 08:47:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223134728.455F273039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 08:47:28 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 13:47:30 -0000 TB --- 2008-02-23 12:23:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 12:23:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-23 12:23:44 - cleaning the object tree TB --- 2008-02-23 12:24:03 - cvsupping the source tree TB --- 2008-02-23 12:24:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-23 12:24:10 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 12:24:10 - cd /src TB --- 2008-02-23 12:24:10 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 12:24:13 UTC 2008 >>> 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 Sat Feb 23 13:35:47 UTC 2008 TB --- 2008-02-23 13:35:47 - generating LINT kernel config TB --- 2008-02-23 13:35:47 - cd /src/sys/ia64/conf TB --- 2008-02-23 13:35:47 - /usr/bin/make -B LINT TB --- 2008-02-23 13:35:47 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 13:35:47 - cd /src TB --- 2008-02-23 13:35:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 13:35:47 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64/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/ia64/src/sys/LINT -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 13:47:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 13:47:28 - ERROR: failed to build lint kernel TB --- 2008-02-23 13:47:28 - tinderbox aborted TB --- 3754.33 user 393.51 system 5023.80 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 14:28:03 2008 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 4CF2C16A403; Sat, 23 Feb 2008 14:28:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1743913C45D; Sat, 23 Feb 2008 14:28:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NES2rl098141; Sat, 23 Feb 2008 09:28:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NES2gg058995; Sat, 23 Feb 2008 09:28:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 48EE373039; Sat, 23 Feb 2008 09:28:02 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223142802.48EE373039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 09:28:02 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner4 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 14:28:03 -0000 TB --- 2008-02-23 13:16:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 13:16:56 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-23 13:16:56 - cleaning the object tree TB --- 2008-02-23 13:17:23 - cvsupping the source tree TB --- 2008-02-23 13:17:23 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-23 13:17:30 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 13:17:30 - cd /src TB --- 2008-02-23 13:17:30 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 13:17:33 UTC 2008 >>> 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 Sat Feb 23 14:19:59 UTC 2008 TB --- 2008-02-23 14:19:59 - generating LINT kernel config TB --- 2008-02-23 14:19:59 - cd /src/sys/powerpc/conf TB --- 2008-02-23 14:19:59 - /usr/bin/make -B LINT TB --- 2008-02-23 14:19:59 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 14:19:59 - cd /src TB --- 2008-02-23 14:19:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 14:19:59 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc/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 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc/src/sys/LINT -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 14:28:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 14:28:02 - ERROR: failed to build lint kernel TB --- 2008-02-23 14:28:02 - tinderbox aborted TB --- 3174.86 user 374.47 system 4265.75 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 14:56:44 2008 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 DBD3016A404; Sat, 23 Feb 2008 14:56:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A9C0B13C458; Sat, 23 Feb 2008 14:56:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NEuhdY099286; Sat, 23 Feb 2008 09:56:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NEuhs9051608; Sat, 23 Feb 2008 09:56:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 96B5B73039; Sat, 23 Feb 2008 09:56:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223145643.96B5B73039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 09:56:43 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 14:56:45 -0000 TB --- 2008-02-23 13:47:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 13:47:28 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-23 13:47:28 - cleaning the object tree TB --- 2008-02-23 13:47:52 - cvsupping the source tree TB --- 2008-02-23 13:47:52 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-23 13:47:57 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 13:47:57 - cd /src TB --- 2008-02-23 13:47:57 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 13:47:58 UTC 2008 >>> 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 Sat Feb 23 14:47:57 UTC 2008 TB --- 2008-02-23 14:47:57 - generating LINT kernel config TB --- 2008-02-23 14:47:57 - cd /src/sys/sparc64/conf TB --- 2008-02-23 14:47:57 - /usr/bin/make -B LINT TB --- 2008-02-23 14:47:57 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 14:47:57 - cd /src TB --- 2008-02-23 14:47:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 14:47:57 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/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/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 14:56:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 14:56:43 - ERROR: failed to build lint kernel TB --- 2008-02-23 14:56:43 - tinderbox aborted TB --- 3015.83 user 366.98 system 4155.18 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 15:00:15 2008 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 6722D16A406 for ; Sat, 23 Feb 2008 15:00:15 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from cenn-smtp.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by mx1.freebsd.org (Postfix) with ESMTP id 31A9813C4EB for ; Sat, 23 Feb 2008 15:00:14 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by cenn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id 5B91C810E; Sat, 23 Feb 2008 08:37:13 -0600 (CST) Received: from build64.tcbug.org (unknown [208.42.70.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcbug.org (Postfix) with ESMTP id B2DDA6D9E29; Sat, 23 Feb 2008 08:37:12 -0600 (CST) From: Josh Paetzel To: freebsd-current@freebsd.org Date: Sat, 23 Feb 2008 08:36:56 +0000 User-Agent: KMail/1.9.7 References: <47BA10C1.5030701@trull.org> <1203541485.99240.39.camel@bauer.cse.buffalo.edu> <47BCBAA1.1070000@bosco.princeton.edu> In-Reply-To: <47BCBAA1.1070000@bosco.princeton.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2714369.ZscZGVfCf0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802230837.02619.josh@tcbug.org> Cc: Ken Smith , Brian Biskeborn Subject: Re: hptrr driver panics on 7.0-RC2 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, 23 Feb 2008 15:00:15 -0000 --nextPart2714369.ZscZGVfCf0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 20 February 2008 11:41:21 pm Brian Biskeborn wrote: > "RC3" works fine with my 2314MS. Thanks. > > Brian > What are the chances of getting a similar fix for 6.3-R The hptrr driver i= s=20 unusable for me, I'd be willing to help test but the machine I have the=20 appropriate hardware in is stuck on 6.x for now. See kern/120615 =2D-=20 Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB --nextPart2714369.ZscZGVfCf0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHv9suJvkB8SevrssRAkhuAJ9NrTB5VpyjujKyn+vpBcWUsJ1NRwCgi5y0 1PX/obaZCLsNQfdKyTakpds= =QTPm -----END PGP SIGNATURE----- --nextPart2714369.ZscZGVfCf0-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 15:30:46 2008 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 4D7E116A404; Sat, 23 Feb 2008 15:30:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1E25513C461; Sat, 23 Feb 2008 15:30:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NFUjdJ049713; Sat, 23 Feb 2008 10:30:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NFUji0083504; Sat, 23 Feb 2008 10:30:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0E46473039; Sat, 23 Feb 2008 10:30:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223153045.0E46473039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 10:30:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 15:30:46 -0000 TB --- 2008-02-23 14:28:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 14:28:02 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-23 14:28:02 - cleaning the object tree TB --- 2008-02-23 14:28:27 - cvsupping the source tree TB --- 2008-02-23 14:28:27 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-23 14:28:35 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 14:28:35 - cd /src TB --- 2008-02-23 14:28:35 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 14:28:36 UTC 2008 >>> 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 Sat Feb 23 15:23:41 UTC 2008 TB --- 2008-02-23 15:23:41 - generating LINT kernel config TB --- 2008-02-23 15:23:41 - cd /src/sys/sun4v/conf TB --- 2008-02-23 15:23:41 - /usr/bin/make -B LINT TB --- 2008-02-23 15:23:41 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 15:23:41 - cd /src TB --- 2008-02-23 15:23:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 15:23:41 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -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 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** 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 --- 2008-02-23 15:30:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 15:30:44 - ERROR: failed to build lint kernel TB --- 2008-02-23 15:30:44 - tinderbox aborted TB --- 2985.34 user 364.46 system 3762.57 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 18:22:01 2008 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 1ABD716A400 for ; Sat, 23 Feb 2008 18:22:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF5C913C45B for ; Sat, 23 Feb 2008 18:22:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JSz0W-0008p0-Lv for freebsd-current@freebsd.org; Sat, 23 Feb 2008 20:21:59 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1NILTqh015570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2008 20:21:30 +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.2/8.14.2) with ESMTP id m1NILq31049447; Sat, 23 Feb 2008 20:21:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1NILqxI049446; Sat, 23 Feb 2008 20:21:52 +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: Sat, 23 Feb 2008 20:21:52 +0200 From: Kostik Belousov To: pluknet Message-ID: <20080223182152.GE57756@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/5/Pa32SZQEo/GK+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 6dc4245230f22f3abb357b69a6da667e X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2291 [Feb 22 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {TO: seems autogenerated} X-SpamTest-Info: {TO: local part of email appears in body} X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 19 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: FreeBSD Current Subject: Re: panic: mutex Giant owned at nfs_syscalls.c:556 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, 23 Feb 2008 18:22:01 -0000 --/5/Pa32SZQEo/GK+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 02:28:59PM +0300, pluknet wrote: > I got this assertion while attempting to remove file on nfs mounted > ffs filesystem. > NFS client on 7.0-PRERELEASE and NFS server on 8-CURRENT. >=20 > FreeBSD 7.0-PRERELEASE #1: Wed Feb 6 18:09:18 MSK 2008 > FreeBSD 8.0-CURRENT #9: Fri Feb 15 14:31:07 MSK 2008 >=20 > Unread portion of the kernel message buffer: > panic: mutex Giant owned at > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 > KDB: enter: panic > exclusive sleep mutex nfsd_mtx r =3D 0 (0xc41d1660) locked @ > /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:501 > exclusive sleep mutex Giant r =3D 0 (0xc07e6410) locked @ > /usr/src/sys/kern/vfs_lookup.c:663 > ... > #9 0xc053959d in panic (fmt=3D0xc076181d "mutex %s owned at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:555 > #10 0xc052adf7 in _mtx_assert (m=3D0xc07e6410, what=3D0, > file=3D0xc41cb7b2 > "/usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c", > line=3D556) at /usr/src/sys/kern/kern_mutex.c:652 > #11 0xc41c9e82 in nfssvc (td=3D0xc2e68000, uap=3D0xd600dcfc) > at /usr/src/sys/modules/nfsserver/../../nfsserver/nfs_syscalls.c:556 > #12 0xc0727903 in syscall (frame=3D0xd600dd38) > at /usr/src/sys/i386/i386/trap.c:1034 > #13 0xc0711630 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:203 > ---Type to continue, or q to quit--- > #14 0x00000033 in ?? () >=20 > Looks somewhat strange because nfs_syscalls.c:556 is not in nfssvc(), > it's in nfssvc_nfsd(). > Kernel and world synchronized on 8-CUR though. Assert itself only catches the missed Giant unlock somewhere during the execution of an nfs requtest. Unfortunately, it seems that the error is in nfsserver that missed Giant unlock (most likely, on some error path). Helpful would be the tcpdump raw trace file of the communication between nfs server and client immediately before the panic. --/5/Pa32SZQEo/GK+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfAZEAACgkQC3+MBN1Mb4hsawCgzhbqZMKxJ4m3we2Vgxsmqwk9 0LYAoNnQxq0pYW9Y3xQHXgTKdCrrMu4a =h++d -----END PGP SIGNATURE----- --/5/Pa32SZQEo/GK+-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 18:36:04 2008 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 1342316A40B; Sat, 23 Feb 2008 18:36:04 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id CAB7213C468; Sat, 23 Feb 2008 18:36:03 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1NIZv7E083509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2008 10:35:57 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47C0678D.20905@errno.com> Date: Sat, 23 Feb 2008 10:35:57 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20080222042700.GB30497@cdnetworks.co.kr> <20080222094742.GF30497@cdnetworks.co.kr> In-Reply-To: <20080222094742.GF30497@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: Ian FREISLICH , Robert Backhaus , FreeBSD Current Subject: Re: Packet corruption in re0 [checksum offloading] 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, 23 Feb 2008 18:36:04 -0000 Pyun YongHyeon wrote: > On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > On Thu, Feb 21, 2008 at 01:18:18PM +0200, Ian FREISLICH wrote: > > > > Pyun YongHyeon wrote: > > > > > On Thu, Feb 21, 2008 at 02:47:43PM +1000, Robert Backhaus wrote: > > > > > > On Thu, Feb 21, 2008 at 1:50 PM, Pyun YongHyeon wr > > ote: > > > > > > > On Thu, Feb 21, 2008 at 11:03:02AM +1000, Robert Backhaus wrote: > > > > > > > > I am experiencing roughly 15% packet corruption on the re inter > > face > > > > on > > > > > > > > my freebsd 7/amd64 box. > > > > > > > > > > > > > > > > FreeBSD gw.flexi.robbak.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEA > > SE #8 > > > > : > > > > > > > > Tue Feb 5 09:49:55 EST 2008 > > > > > > > > root@gw.flexi.robbak.com:/usr/obj/usr/src/sys/GW amd64 > > > > > > > > > > > > > > > > Just to make troubleshooting difficult, this problem only shows > > up > > > > > > > > after the system has been up for roughly 36 hours, depending on > > the > > > > > > > > amount of traffic. > > > > > > > > > > > > > > > > > > > > > > I didn't take a look attached tcpdump files but I guess the > > > > > > > instability issue was fixed in HEAD. It's not yet MFCed but > > > > > > > I'll handle it in a week. > > > > > > > > > > > > > > Would you try re(4) in HEAD? > > > > > > > > > > > > > > > > > > > OK, I'll do that. What is the best way to do that? csupping to "." se > > ems a > > > > > > bit drastic, and I don't do much with cvs proper. I take it that I sh > > ould > > > > use > > > > > > anon-cvs to grab the directory, but I don't quite know how. > > > > > > > > > > > > > > > > Copy sys/dev/re/if_re.c, sys/pci/if_rlreg.h in HEAD to your box. > > > > > Due to lack of m_defrag(9) in 7-PRERELEASE/RC, you also have to add > > > > > that function to if_re.c(Copy m_defrag() in sys/kern/uipc_mbuf.c on > > > > > HEAD/RELENG_7 to if_re.c). That would make it build on your box. > > > > > > > > This doesn't solve the problem that I'm seeing on re(4) interfaces. > > > > It basically shows up as quagga establishing OSPF neighours as > > > > "Exchange/DR" when VLAN hardware tagging is enabled. I'm running > > > > OSPF over 802.1Q vlans. Neighbours are correctly negotiated once > > > > VLAN hardware tagging is disabled on the interface. > > > > > > > > I'll do more debugging. > > > > > > > > > > Hmm. That sounds like different issue to me. I guess I din't change > > > any semantics in VLAN H/W tagging. Do you still the same VLAN H/W > > > tagging related issues on RELENG_7? > > > > > > To narrow down the issue it would be even better to know which parts > > > of H/W assistance was broken. For example, > > > - Disable checksum offload for VLAN interface first and check > > > whether quagga works. > > > > You can only disable offload on the parent interface. > > > > Hmm... I thought it should work. > I have no idea why ioctl handler of vlan(4) rejects checksum > offload configutation. I guess vlan(4) should be teached to handle > this. If parent interface have IFCAP_VLAN_HWCSUM capability and > IFCAP_VLAN_HWTAGGING, ifconfig(4) should be able to control checksum > offload for vlan(4) interface. CCed to yar to get his opinions on > controlling checksum offload on vlan(4). > > > > - Disable checksum offload for parent interface and check again. > > > If you can post tcpdump output for broken conntection it may help a > > > lot to diagnose the issue. > > > > The only flag affecting this behaviour is vlanhwtag. Various > > permutations of the interface flags make no difference to this > > behaviour as long as hardware tagging is enabled. > > > > Disabling VLAN HW tagging also turns off checksum offload on vlan(4) > interface. > > This reminds me that there are several places in the system where h/w checksum offload needs to be specially handled but instead is disabled as a WAR. In particular I'm thinking of the bridge where txcsum is muted on devices while they are plumbed. But this can be a big loss and the better approach (IMO) is to fill in the missing capability in s/w. Not sure what components there are besides bridge and vlan; maybe lagg? netgraph? Note there are other capabilities besides checksum offload, TSO can be done in s/w with good effect. Sam From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 19:42:45 2008 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 7231816A408; Sat, 23 Feb 2008 19:42:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 52DF413C467; Sat, 23 Feb 2008 19:42:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NJgisT013778; Sat, 23 Feb 2008 14:42:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NJgiD3015961; Sat, 23 Feb 2008 14:42:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E79C273039; Sat, 23 Feb 2008 14:42:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223194243.E79C273039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 14:42:43 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 19:42:45 -0000 TB --- 2008-02-23 18:19:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 18:19:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-02-23 18:19:12 - cleaning the object tree TB --- 2008-02-23 18:19:31 - cvsupping the source tree TB --- 2008-02-23 18:19:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-02-23 18:19:37 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 18:19:37 - cd /src TB --- 2008-02-23 18:19:37 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 18:19:38 UTC 2008 >>> 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 Sat Feb 23 19:31:16 UTC 2008 TB --- 2008-02-23 19:31:16 - generating LINT kernel config TB --- 2008-02-23 19:31:16 - cd /src/sys/ia64/conf TB --- 2008-02-23 19:31:16 - /usr/bin/make -B LINT TB --- 2008-02-23 19:31:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 19:31:16 - cd /src TB --- 2008-02-23 19:31:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 19:31:16 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64/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/ia64/src/sys/LINT -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 19:42:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 19:42:43 - ERROR: failed to build lint kernel TB --- 2008-02-23 19:42:43 - tinderbox aborted TB --- 3755.69 user 393.35 system 5011.51 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 20:18:14 2008 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 4239116A503; Sat, 23 Feb 2008 20:18:14 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id DD86913C457; Sat, 23 Feb 2008 20:18:12 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=53662 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JT0p0-000N37-64; Sat, 23 Feb 2008 20:18:10 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m1NKI8wa067083; Sat, 23 Feb 2008 23:18:08 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m1NKI8fe067082; Sat, 23 Feb 2008 23:18:08 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Sat, 23 Feb 2008 23:18:08 +0300 From: Ruslan Ermilov To: Dag-Erling Sm??rgrav Message-ID: <20080223201808.GB65540@team.vega.ru> References: <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <86wsoxp2ob.fsf@ds4.des.no> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Joseph Koshy , Kai Wang , David O'Brien , current@FreeBSD.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 23 Feb 2008 20:18:14 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 22, 2008 at 01:59:32PM +0100, Dag-Erling Sm??rgrav wrote: > Ruslan Ermilov writes: > > Dag-Erling Sm??rgrav writes: > > > __FreeBSD_version wasn't bumped specifically for it, but 700044 > > > should be fine. > > And for 8xxxxx? > > 700044 is from before the branch, so anything > 700044 is fine. > OK, I'm going to commit the attached patch in 12 hours, unless I hear some objections. It differs in that we now bootstrap BSD ar on systems >700044, and that we call GNU ar/ranlib with the "g" prefix instead of "gnu-". Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: sys/sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.337 diff -u -p -r1.337 param.h --- sys/sys/param.h 21 Feb 2008 16:12:46 -0000 1.337 +++ sys/sys/param.h 22 Feb 2008 07:43:33 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800021 /* Master, propagated to newvers */ +#define __FreeBSD_version 800022 /* Master, propagated to newvers */ #ifndef LOCORE #include Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.598 diff -u -p -r1.598 Makefile.inc1 --- Makefile.inc1 5 Feb 2008 15:41:58 -0000 1.598 +++ Makefile.inc1 23 Feb 2008 20:16:41 -0000 @@ -872,6 +872,11 @@ _groff= gnu/usr.bin/groff/tmac .endif .endif +.if !defined(WITH_GNUAR) && \ + ${BOOTSTRAPPING} >= 700044 +_ar= usr.bin/ar +.endif + .if ${BOOTSTRAPPING} < 700018 _gensnmptree= usr.sbin/bsnmpd/gensnmptree .endif @@ -891,6 +896,7 @@ bootstrap-tools: ${_strfile} \ ${_gperf} \ ${_groff} \ + ${_ar} \ usr.bin/lorder \ usr.bin/makewhatis \ usr.bin/rpcgen \ @@ -967,6 +973,10 @@ _kgzip= usr.sbin/kgzip .endif .endif +.if make(cross-tools) && ${BOOTSTRAPPING} < 700044 +.MAKEFLAGS+= -DWITH_GNUAR +.endif + cross-tools: .for _tool in \ gnu/usr.bin/binutils \ Index: gnu/usr.bin/binutils/ar/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ar/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- gnu/usr.bin/binutils/ar/Makefile 21 Feb 2008 16:59:02 -0000 1.16 +++ gnu/usr.bin/binutils/ar/Makefile 23 Feb 2008 19:48:58 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ar -#MAN= gnu-ar.1 -.else -PROG= ar +.if !defined(WITH_GNUAR) +PROGNAME= gar +MAN= gar.1 +gar.1: ar.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= gar.1 .endif + +PROG= ar SRCS= ar.c not-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: gnu/usr.bin/binutils/ranlib/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/binutils/ranlib/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- gnu/usr.bin/binutils/ranlib/Makefile 21 Feb 2008 16:59:02 -0000 1.17 +++ gnu/usr.bin/binutils/ranlib/Makefile 23 Feb 2008 19:49:14 -0000 @@ -4,12 +4,15 @@ .PATH: ${SRCDIR}/binutils ${SRCDIR}/binutils/doc -.if defined(WITH_BSDAR) -PROG= gnu-ranlib -#MAN= gnu-ranlib.1 -.else -PROG= ranlib +.if !defined(WITH_GNUAR) +PROGNAME= granlib +MAN= granlib.1 +granlib.1: ranlib.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= granlib.1 .endif + +PROG= ranlib SRCS= ar.c is-ranlib.c CFLAGS+= -D_GNU_SOURCE CFLAGS+= -I${.CURDIR}/${RELTOP}/libbinutils Index: usr.bin/ar/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/ar/Makefile,v retrieving revision 1.19 diff -u -p -r1.19 Makefile --- usr.bin/ar/Makefile 22 Feb 2008 06:53:52 -0000 1.19 +++ usr.bin/ar/Makefile 22 Feb 2008 10:31:44 -0000 @@ -1,10 +1,21 @@ # $FreeBSD: src/usr.bin/ar/Makefile,v 1.19 2008/02/22 06:53:52 obrien Exp $ -.if defined(WITH_BSDAR) PROG= ar + +.if !defined(WITH_GNUAR) +NO_SHARED?= yes +LINKS= ${BINDIR}/ar ${BINDIR}/ranlib +MLINKS= ar.1 ranlib.1 .else -PROG= bsdar +PROGNAME= bsdar +MAN= bsdar.1 +bsdar.1: ar.1 + cat ${.ALLSRC} > ${.TARGET} +CLEANFILES+= bsdar.1 +LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib +MLINKS= bsdar.1 bsdranlib.1 .endif + SRCS= ar.c read.c util.c write.c WARNS?= 5 @@ -12,17 +23,4 @@ WARNS?= 5 DPADD= ${LIBARCHIVE} ${LIBBZ2} ${LIBZ} ${LIBELF} LDADD= -larchive -lbz2 -lz -lelf -.if defined(WITH_BSDAR) -NO_SHARED?= yes -LINKS= ${BINDIR}/ar ${BINDIR}/ranlib -MLINKS= ar ranlib -.else -LINKS= ${BINDIR}/bsdar ${BINDIR}/bsdranlib -MLINKS= bsdar.1 bsdranlib.1 - -CLEANFILES+= bsdar.1 -bsdar.1: ar.1 - ln -sf ${.ALLSRC} ${.TARGET} -.endif - .include --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 20:23:36 2008 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 3A3B716A400; Sat, 23 Feb 2008 20:23:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1C313C4CE; Sat, 23 Feb 2008 20:23:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NKNZDt016721; Sat, 23 Feb 2008 15:23:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NKNZuF054528; Sat, 23 Feb 2008 15:23:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0201973039; Sat, 23 Feb 2008 15:23:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223202335.0201973039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 15:23:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 20:23:36 -0000 TB --- 2008-02-23 19:12:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 19:12:23 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-02-23 19:12:23 - cleaning the object tree TB --- 2008-02-23 19:12:43 - cvsupping the source tree TB --- 2008-02-23 19:12:43 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-02-23 19:12:49 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 19:12:49 - cd /src TB --- 2008-02-23 19:12:49 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 19:12:50 UTC 2008 >>> 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 Sat Feb 23 20:15:19 UTC 2008 TB --- 2008-02-23 20:15:19 - generating LINT kernel config TB --- 2008-02-23 20:15:19 - cd /src/sys/powerpc/conf TB --- 2008-02-23 20:15:19 - /usr/bin/make -B LINT TB --- 2008-02-23 20:15:19 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 20:15:19 - cd /src TB --- 2008-02-23 20:15:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 20:15:19 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc/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 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc/src/sys/LINT -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 20:23:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 20:23:34 - ERROR: failed to build lint kernel TB --- 2008-02-23 20:23:34 - tinderbox aborted TB --- 3178.73 user 372.67 system 4271.82 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 20:52:02 2008 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 29F6016A401; Sat, 23 Feb 2008 20:52:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0D02A13C447; Sat, 23 Feb 2008 20:52:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NKq1vx018537; Sat, 23 Feb 2008 15:52:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NKq1uq047270; Sat, 23 Feb 2008 15:52:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0D45373039; Sat, 23 Feb 2008 15:52:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223205201.0D45373039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 15:52:01 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner4 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 20:52:02 -0000 TB --- 2008-02-23 19:42:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 19:42:43 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-02-23 19:42:44 - cleaning the object tree TB --- 2008-02-23 19:43:04 - cvsupping the source tree TB --- 2008-02-23 19:43:04 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-02-23 19:43:10 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 19:43:10 - cd /src TB --- 2008-02-23 19:43:10 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 19:43:12 UTC 2008 >>> 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 Sat Feb 23 20:43:06 UTC 2008 TB --- 2008-02-23 20:43:06 - generating LINT kernel config TB --- 2008-02-23 20:43:06 - cd /src/sys/sparc64/conf TB --- 2008-02-23 20:43:06 - /usr/bin/make -B LINT TB --- 2008-02-23 20:43:06 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 20:43:06 - cd /src TB --- 2008-02-23 20:43:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 20:43:07 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/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/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-23 20:52:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 20:52:00 - ERROR: failed to build lint kernel TB --- 2008-02-23 20:52:00 - tinderbox aborted TB --- 3014.69 user 369.12 system 4156.98 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 21:26:11 2008 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 D500F16A400; Sat, 23 Feb 2008 21:26:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B8E0213C45D; Sat, 23 Feb 2008 21:26:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NLQAQX067202; Sat, 23 Feb 2008 16:26:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1NLQAfk013213; Sat, 23 Feb 2008 16:26:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 997FA73039; Sat, 23 Feb 2008 16:26:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080223212610.997FA73039@freebsd-current.sentex.ca> Date: Sat, 23 Feb 2008 16:26:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on clamscanner3 X-Virus-Status: Clean 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: Sat, 23 Feb 2008 21:26:12 -0000 TB --- 2008-02-23 20:23:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-23 20:23:35 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-02-23 20:23:35 - cleaning the object tree TB --- 2008-02-23 20:23:58 - cvsupping the source tree TB --- 2008-02-23 20:23:58 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-02-23 20:24:04 - building world (CFLAGS=-O -pipe) TB --- 2008-02-23 20:24:04 - cd /src TB --- 2008-02-23 20:24:04 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 23 20:24:06 UTC 2008 >>> 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 Sat Feb 23 21:19:04 UTC 2008 TB --- 2008-02-23 21:19:04 - generating LINT kernel config TB --- 2008-02-23 21:19:04 - cd /src/sys/sun4v/conf TB --- 2008-02-23 21:19:04 - /usr/bin/make -B LINT TB --- 2008-02-23 21:19:04 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-23 21:19:04 - cd /src TB --- 2008-02-23 21:19:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 23 21:19:05 UTC 2008 >>> 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 [...] ld -Bshareable -d -warn-common -o toecore.ko toecore.kld objcopy --strip-debug toecore.ko ===> cxgb/tom (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -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 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c cc1: warnings being treated as errors /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c: In function 'do_bad_cpl': /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: implicit declaration of function 'kdb_backtrace' /src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_tom.c:287: warning: nested extern declaration of 'kdb_backtrace' *** Error code 1 Stop in /src/sys/modules/cxgb/tom. *** Error code 1 Stop in /src/sys/modules/cxgb. *** 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 --- 2008-02-23 21:26:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-23 21:26:10 - ERROR: failed to build lint kernel TB --- 2008-02-23 21:26:10 - tinderbox aborted TB --- 2987.90 user 360.45 system 3755.41 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 22:36:00 2008 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 2FD9D16A406; Sat, 23 Feb 2008 22:36:00 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id E9C6513C467; Sat, 23 Feb 2008 22:35:59 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 22B9C208E; Sat, 23 Feb 2008 23:35:56 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 0E1F72088; Sat, 23 Feb 2008 23:35:56 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id DB2558448C; Sat, 23 Feb 2008 23:35:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ruslan Ermilov References: <20080221152549.GB21518@team.vega.ru> <20080221173150.GA93693@dragon.NUXI.org> <20080222070728.GA56282@team.vega.ru> <20080222091642.GB57428@team.vega.ru> <864pc1s1wa.fsf@ds4.des.no> <20080222105239.GC94607@team.vega.ru> <86abltqjiz.fsf@ds4.des.no> <20080222124617.GA16580@team.vega.ru> <86wsoxp2ob.fsf@ds4.des.no> <20080223201808.GB65540@team.vega.ru> Date: Sat, 23 Feb 2008 23:35:55 +0100 In-Reply-To: <20080223201808.GB65540@team.vega.ru> (Ruslan Ermilov's message of "Sat\, 23 Feb 2008 23\:18\:08 +0300") Message-ID: <861w73s3lg.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Joseph Koshy , Kai Wang , David O'Brien , current@FreeBSD.org Subject: Re: [HEADS UP] ar(1) front-end committed. (notes for cross compile) 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, 23 Feb 2008 22:36:00 -0000 Ruslan Ermilov writes: > OK, I'm going to commit the attached patch in 12 hours, > unless I hear some objections. It differs in that we > now bootstrap BSD ar on systems >700044, and that we call > GNU ar/ranlib with the "g" prefix instead of "gnu-". Sounds good to me. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 23:32:14 2008 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 8CE2816A419 for ; Sat, 23 Feb 2008 23:32:14 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63914.mail.re1.yahoo.com (web63914.mail.re1.yahoo.com [69.147.97.129]) by mx1.freebsd.org (Postfix) with SMTP id 43B5B13C458 for ; Sat, 23 Feb 2008 23:32:13 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 34599 invoked by uid 60001); 23 Feb 2008 23:32:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=u5vIslepFTBSVk7DCnBWyny6TKuHnY7ygBMErjYXqC3FiDcdLQn6F9bwbRtkhYReywgu53nikL4UmN4VRlrtQXqjPBoCcYVZ0dkbyjoRActuOPFAPJV8BMcEQDJNvhnvm2Fr+lUs5xz4EILwQ0Ymjp+TLpu/KZxGteDLFDSJYpE=; X-YMail-OSG: 0Ze9yz8VM1l53Ap2s9VimmYe3Bs5gxC4RbUVvBg1e33TyquKl2hf8_KQ2dQA4n3Bhl5FpzeUQGnwCkte3mXrK1WcF.8bCRH_H3NW5DFx81GoCodyxs5qOo5LbOa89IDvEwYnPTmCchg09VIO298V7u2O Received: from [98.203.28.38] by web63914.mail.re1.yahoo.com via HTTP; Sat, 23 Feb 2008 15:32:13 PST Date: Sat, 23 Feb 2008 15:32:13 -0800 (PST) From: Barney Cordoba To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <274346.34322.qm@web63914.mail.re1.yahoo.com> Cc: Subject: splimp() 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, 23 Feb 2008 23:32:14 -0000 I'm porting some older software to 7.0 and I see that many of the 7.0 drivers use both locks and splimps() to protect code, particularly the firewire driver. What cases would an splimp() be required? Barney ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ