From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 00:17:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31AE316A41F for ; Sun, 9 Oct 2005 00:17:40 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id E318243D45 for ; Sun, 9 Oct 2005 00:17:37 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from stealth.local (pcp09741457pcs.goosck01.sc.comcast.net [69.241.83.8]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j990Ha3t058371; Sat, 8 Oct 2005 17:17:37 -0700 (PDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Sat, 8 Oct 2005 20:17:28 -0400 User-Agent: KMail/1.8.1 References: <200510061139.37825.lists@jnielsen.net> <200510071557.50553.lists@jnielsen.net> <20051008172037.O56323@ury.york.ac.uk> In-Reply-To: <20051008172037.O56323@ury.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510082017.28622.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: Re: Broadcom BCM5751 not attaching on IBM ThinkCentre A51 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 00:17:40 -0000 On Saturday 08 October 2005 02:14 pm, Gavin Atkinson wrote: > On Fri, 7 Oct 2005, John Nielsen wrote: > > On Friday 07 October 2005 12:58, Gavin Atkinson wrote: > >> Can you post the output of pciconf -l please? > > > > Attached, along with dmesg output and kernel config file (basically a > > stripped-down GENERIC). > > Can you try applying the attached patch, and the patch in > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79139 and if the latter > patch makes no difference, show the output of the extra line? > > You could also try http://people.freebsd.org/~yongari/bge.patch.0908 - > but I don't believe it will help in this case. (it's actually to fix > endian issues on other platforms, but it does change the way the driver > talks to the chip subtly) I will try all three on Monday. Does it make a difference if it's on 5.4, 6.0 or 7.0? I don't think if_bge differs much between the three versions, but I haven't reviewed the pci code as much. Thank you for your response! JN From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 01:03:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F1F716A41F for ; Sun, 9 Oct 2005 01:03:16 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-3.paradise.net.nz (bm-3a.paradise.net.nz [203.96.152.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 095C243D48 for ; Sun, 9 Oct 2005 01:03:15 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-2.paradise.net.nz ([203.96.152.177]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IO200KO3IXCVG@linda-3.paradise.net.nz> for freebsd-current@freebsd.org; Sun, 09 Oct 2005 14:03:14 +1300 (NZDT) Received: from [192.168.1.11] (218-101-14-2.paradise.net.nz [218.101.14.2]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id C76662C2FB9; Sun, 09 Oct 2005 14:03:11 +1300 (NZDT) Date: Sun, 09 Oct 2005 14:03:04 +1300 From: Mark Kirkwood In-reply-to: <20050921174155.GB80991@xor.obsecurity.org> To: Kris Kennaway Message-id: <43486C48.3090404@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) References: <20050921174155.GB80991@xor.obsecurity.org> Cc: Joseph Peralta , freebsd-current@freebsd.org Subject: Re: errors during buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 01:03:16 -0000 Kris Kennaway wrote: > On Wed, Sep 21, 2005 at 01:33:15PM -0400, Joseph Peralta wrote: > >>I am attempting to run 'make buildworld' using the FreeBSD 6.0-BETA5 source, >>prior to this I completely removed and re-created /usr/src and /usr/obj and >>downloaded the new source with cvsup. During the build I get the following >>error, does anyone have any ideas what would be causing it or how to fix it? >> /usr/src/lib/libz/inflate.c:1086: internal compiler error: Segmentation > > > This is a FAQ, it usually means hardware failure. > > Kris I have just run into this as well - updating 6.0-BETA5 last night on a (few weeks old) 6.0-BETA5 system (Tyan S2510 + 2 PIII 1GHz + 2G). The obvious thing to do is check for a hardware problem, so: - Tested cpus with cpuburn (2xburnP6 for 1 hour). - Tested memory with memtest-86 (about 6 hours). The system passes these tests easily, so I am finding it hard to see hardware problems (Indeed the system is well ventilated and cooled - 6 fans, and the exhaust air is never anything but cool, even while running cpuburn). Another interesting point is that I have used this system to update 6.0-CURRENT to 6.0-BETA1 and subsequently BETA2, BETA3, BETA4 (and BETA5 once) without seeing this issue. I removed /usr/obj/usr/src/* and tried buildworld again, and it went through that time (am running the updated system now)... So it's a bit confusing, could we be seeing a real gcc bug? regards Mark From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 02:07:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284E916A41F for ; Sun, 9 Oct 2005 02:07:29 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EAD543D48 for ; Sun, 9 Oct 2005 02:07:28 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9927QD0004186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 9 Oct 2005 12:07:26 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9927QHh000666; Sun, 9 Oct 2005 12:07:26 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9927Pcc000665; Sun, 9 Oct 2005 12:07:25 +1000 (EST) (envelope-from pjeremy) Date: Sun, 9 Oct 2005 12:07:25 +1000 From: Peter Jeremy To: Mark Kirkwood Message-ID: <20051009020725.GC223@cirb503493.alcatel.com.au> References: <20050921174155.GB80991@xor.obsecurity.org> <43486C48.3090404@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43486C48.3090404@paradise.net.nz> User-Agent: Mutt/1.4.2.1i Cc: Joseph Peralta , freebsd-current@freebsd.org Subject: Re: errors during buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 02:07:29 -0000 On Sun, 2005-Oct-09 14:03:04 +1300, Mark Kirkwood wrote: >- Tested cpus with cpuburn (2xburnP6 for 1 hour). >- Tested memory with memtest-86 (about 6 hours). memtest-86 and cpuburn can demonstrate that there is a fault but not that there isn't. Pattern-sensitive memory errors, in particular, are very unlikely to be detected. Also, the above tests are focussed on specific subsystems and would not pick up a problem was was triggered by interactions between different subsystems (eg there is no disk or PCI I/O in the above tests). >The system passes these tests easily, so I am finding it hard to see >hardware problems (Indeed the system is well ventilated and cooled Cooling isn't the only hardware problem. Marginal PSUs or marginal electros on the motherboard are also quite common - especially if the hardware is getting old. Electrolytic capacitors have a finite life and this is shortened by heat and high ripple currents - both of which are common in computers. >I removed /usr/obj/usr/src/* and tried buildworld again, and it went >through that time (am running the updated system now)... That suggests a hardware problem to me. >So it's a bit confusing, could we be seeing a real gcc bug? gcc is deterministic so a real gcc bug is more likely to manifest as a consistent failure at the same point. A problem that moves around and isn't always there is more indicative of a hardware issue. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 03:51:32 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 902B816A425; Sun, 9 Oct 2005 03:51:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4865243D53; Sun, 9 Oct 2005 03:51:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [70.30.70.180]) by elvis.mu.org (Postfix) with ESMTP id 3081A1A3C20; Sat, 8 Oct 2005 20:51:31 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 012E953D86; Sat, 8 Oct 2005 23:51:29 -0400 (EDT) Date: Sat, 8 Oct 2005 23:51:29 -0400 From: Kris Kennaway To: phk@FreeBSD.org Message-ID: <20051009035129.GB75694@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: current@FreeBSD.org Subject: panic: devfs_populate_loop 343 stdin 0xfffff80001597000 0xdeadc0dedeadc0de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 03:51:32 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This happened while doing umount -A -t devfs, with /dev mounted and in use, and another devfs mounted that should not have been used by anything. #0 doadump () at ../../../kern/kern_shutdown.c:233 #1 0x00000000c006a808 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xfca34bd0 "") at ../../../ddb/db_command.c:488 #2 0x00000000c006a514 in db_command (last_cmdp=0xc0419268, cmd_table=0x0, aux_cmd_tablep=0xc03d1010, aux_cmd_tablep_end=0xc03d1028) at ../../../ddb/db_command.c:403 #3 0x00000000c006a638 in db_command_loop () at ../../../ddb/db_command.c:454 #4 0x00000000c006d238 in db_trap (type=-56406560, code=0) at ../../../ddb/db_main.c:221 #5 0x00000000c01901c8 in kdb_trap (type=107, code=0, tf=0xfca35060) at ../../../kern/subr_kdb.c:473 #6 0x00000000c02fea0c in trap (tf=0xfca35060) at ../../../sparc64/sparc64/trap.c:307 #7 0x00000000c0048fe0 in tl1_trap () #8 0x00000000c018fd9c in kdb_enter (msg=0xc03aa1c8 "panic") at ../../../kern/subr_kdb.c:267 #9 0x00000000c018fd9c in kdb_enter (msg=0xc03aa1c8 "panic") at ../../../kern/subr_kdb.c:267 #10 0x00000000c0170cec in panic (fmt=0xc03a0e00 "%s %d %s %p %p") at ../../../kern/kern_shutdown.c:539 #11 0x00000000c011d4d0 in devfs_populate_loop (dm=0xfffff800e5e04a00, cleanup=-1001106176) at ../../../fs/devfs/devfs_devs.c:341 #12 0x00000000c011d8c8 in devfs_cleanup (dm=0xfffff800e5e04a00) at ../../../fs/devfs/devfs_devs.c:456 #13 0x00000000c011e98c in devfs_unmount (mp=0xfffff8004b89d800, mntflags=134217728, td=0xfffff8000dea6e40) at ../../../fs/devfs/devfs_vfsops.c:124 #14 0x00000000c01d6e64 in dounmount (mp=0xfffff8004b89d800, flags=134217728, td=0xfffff8000dea6e40) at ../../../kern/vfs_mount.c:963 #15 0x00000000c01d6b9c in unmount (td=0xfffff8000dea6e40, uap=0xfca358c0) at ../../../kern/vfs_mount.c:895 #16 0x00000000c02ff124 in syscall (tf=0xfca35880) at ../../../sparc64/sparc64/trap.c:592 #17 0x00000000c0048dc0 in tl0_intr () #18 0x0000000000000000 in ?? () (kgdb) Core is available (sparc64). Kris --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDSJPBWry0BWjoQKURAqibAJwMSxz7m2CDf+phOIIBtfYrQSlqtwCcDLCL QLHvCUeDRPMUtVpjK1spyo8= =zjKN -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 03:57:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28CF916A420 for ; Sun, 9 Oct 2005 03:57:44 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-3.paradise.net.nz (bm-3a.paradise.net.nz [203.96.152.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B779843D46 for ; Sun, 9 Oct 2005 03:57:43 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-1.paradise.net.nz ([203.96.152.177]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IO200L1VR07NK@linda-3.paradise.net.nz> for freebsd-current@freebsd.org; Sun, 09 Oct 2005 16:57:43 +1300 (NZDT) Received: from [192.168.1.11] (218-101-14-2.paradise.net.nz [218.101.14.2]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id A7B3034A644; Sun, 09 Oct 2005 16:57:42 +1300 (NZDT) Date: Sun, 09 Oct 2005 16:57:34 +1300 From: Mark Kirkwood In-reply-to: <20051009020725.GC223@cirb503493.alcatel.com.au> To: Peter Jeremy Message-id: <4348952E.8000007@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) References: <20050921174155.GB80991@xor.obsecurity.org> <43486C48.3090404@paradise.net.nz> <20051009020725.GC223@cirb503493.alcatel.com.au> Cc: Joseph Peralta , freebsd-current@freebsd.org Subject: Re: errors during buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 03:57:44 -0000 Peter Jeremy wrote: > > Cooling isn't the only hardware problem. Marginal PSUs or marginal > electros on the motherboard are also quite common - especially if > the hardware is getting old. Electrolytic capacitors have a finite > life and this is shortened by heat and high ripple currents - both > of which are common in computers. > Yeah - its certainly possible that there is a hardware problem - as it is an older board, but I thought it interesting (or even slightly suspicious) that several of us are just seeing this in the BETA5 update scenario. cheers Mark From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 07:00:15 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0191516A41F; Sun, 9 Oct 2005 07:00:14 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF6743D45; Sun, 9 Oct 2005 07:00:14 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 5E5C08C9880; Sun, 9 Oct 2005 15:00:13 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 56D048C9866; Sun, 9 Oct 2005 15:00:13 +0800 (CST) Date: Sun, 9 Oct 2005 15:00:13 +0800 (CST) From: Tai-hwa Liang To: Norikatsu Shigemura In-Reply-To: <200510081630.j98GU1Sf021682@sakura.ninth-nine.com> Message-ID: <0510091447540.81426@www.mmlab.cse.yzu.edu.tw> References: <200510081630.j98GU1Sf021682@sakura.ninth-nine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 07:00:15 -0000 On Sun, 9 Oct 2005, Norikatsu Shigemura wrote: > dhclient with if_wi&WEP will freeze on 7-current. > > I am using following if_wi and WEP. [...] > Oct 8 22:01:08 pelsia kernel: Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_cmd 0x0000; event status 0x8008 > Oct 8 22:01:08 pelsia kernel: wi0: wi_cmd: busy bit won't clear. > Oct 8 22:01:08 pelsia kernel: wi0: init failed > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc00/0 > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc81/0 > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc85/0 > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc2a/0 > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc28/0 > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc80/0 > Oct 8 22:01:08 pelsia kernel: wi0: failed to allocate 2372 bytes on NIC > Oct 8 22:01:08 pelsia kernel: wi0: tx buffer allocation failed (error 12) > Oct 8 22:01:08 pelsia kernel: wi0: interface not running [...] Sometimes I run into this whilst running "ifconfig wi0 up" w/o if_wi.ko loaded; that is, the "busy bit won't clear, init failed" happens to my R40(builtin wi miniPCI) regardless of whether or not the WEP is enabled. It looks to me that the firmware doesn't ack. properly at that moment (unfortunately I have no idea about how to fix this); however, the second retry("kldunload if_wi" then "ifconfig wi0 up" again) works for me. -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 08:03:28 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D2D616A41F for ; Sun, 9 Oct 2005 08:03:28 +0000 (GMT) (envelope-from eric.dillenseger@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE0343D46 for ; Sun, 9 Oct 2005 08:03:28 +0000 (GMT) (envelope-from eric.dillenseger@gmail.com) Received: by qproxy.gmail.com with SMTP id o12so90331qba for ; Sun, 09 Oct 2005 01:03:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=lGQ41oOaTc+3W7oUAB44uBd0a9aKmHh7xzBJC3YJc5Tefwq3UyFrPxoLWRYvwSCraJMqlMURQFBteZLNJz7QERPTvaxGHKQFPoWn1QRb1EPWiwxJzEL8aVuds74cT0enaW3iZOojVPh+VX+sy31Lzl2aJit7zcDQOEDat1p3fdM= Received: by 10.64.195.18 with SMTP id s18mr30990qbf; Sun, 09 Oct 2005 00:56:30 -0700 (PDT) Received: from localhost ( [194.158.118.44]) by mx.gmail.com with ESMTP id e17sm718649qba.2005.10.09.00.56.29; Sun, 09 Oct 2005 00:56:30 -0700 (PDT) Date: Sun, 9 Oct 2005 09:56:27 +0200 From: Eric Dillenseger To: current@freebsd.org Message-ID: <20051009075627.GA8280@castor.workgroup> Mail-Followup-To: current@freebsd.org References: <20051008183810.GA6073@castor.workgroup> <47d0403c0510081602l29f5c7abofa2d70b6635077f7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47d0403c0510081602l29f5c7abofa2d70b6635077f7@mail.gmail.com> User-Agent: Mutt/1.5.8i Cc: Subject: Re: ndis and Belkin F5D7010 (aka BRoadcom BCM94306) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 08:03:28 -0000 On Sat, Oct 08, 2005 at 11:02:08PM +0000, Ben Kaduk wrote: > On 10/8/05, Eric Dillenseger wrote: > > > You probably want to look at ndisgen(8). > > Ben Kaduk Well, that was quick and easy, thanks and sorry for the noise. -- "Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout." -- HTCPCP Spec, RFC 2324 From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 15:40:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A96F116A4DD for ; Sun, 9 Oct 2005 15:40:19 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from mail.blastwave.org (mail.blastwave.org [147.87.98.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838B243D46 for ; Sun, 9 Oct 2005 15:40:18 +0000 (GMT) (envelope-from ihsan@dogan.ch) Received: from localhost (localhost [127.0.0.1]) by mail.blastwave.org (Postfix) with ESMTP id E626AF92E; Sun, 9 Oct 2005 17:40:15 +0200 (MEST) Received: from mail.blastwave.org ([127.0.0.1]) by localhost (enterprise [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01092-01-3; Sun, 9 Oct 2005 17:40:11 +0200 (MEST) Received: from defiant.dogan.ch (defiant.dogan.ch [213.144.141.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.blastwave.org (Postfix) with ESMTP id C2A6DF92D; Sun, 9 Oct 2005 17:40:11 +0200 (MEST) Received: by defiant.dogan.ch (Postfix, from userid 1000) id 3FC4217AC8; Sun, 9 Oct 2005 17:40:10 +0200 (CEST) Date: Sun, 9 Oct 2005 17:40:10 +0200 From: Ihsan Dogan To: Sam Leffler Message-ID: <20051009154010.GA24934@dogan.ch> Mail-Followup-To: Sam Leffler , current@freebsd.org References: <20050912144257.GA25791@dogan.ch> <4325A755.9060202@errno.com> <20050912222537.GA10004@dogan.ch> <43270137.3070703@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43270137.3070703@errno.com> X-Operating-System: NetBSD/i386 1.6.2 X-Binford: 6100 (more power) X-Editor: Vim-603 http://www.vim.org User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new at blastwave.org Cc: current@freebsd.org Subject: Re: dhclient exits after a while X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 15:40:21 -0000 On Tuesday, 13 Sep 2005 09:41 -0700, Sam Leffler wrote: > >>>Another bug? > >>> > >> > >>Hard to say, try giving some useful info like what your setup is. > > > > > >My dhclient.conf: > >send host-name "makar"; > > > >I'm using it on a ath interface, but I haven't tried if the same > >happens also with the em interface. I can verify that too. > > Sounds like the network went down and dhclient terminated. With so > little info there's not much one can say. I'm sorry not getting back to you earlier. It really seems to be a networking issue, because it doesn't happen on the copper (em) interface. But I'm wondering why dhclient stops, because I don't have any link up or down messages and I'm not that far away from the access point, so the signal quality is good. I start the dhclient with a small script, which is executed through sudo (nothing special). I noticed, that there is only one dhclient process, if it's started through this script. If I start dhclient from the shell (directly with sudo), there are two dhclient processes. Ihsan -- ihsan@dogan.ch http://ihsan.dogan.ch/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 15:58:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FF4116A41F; Sun, 9 Oct 2005 15:58:26 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABD4F43D64; Sun, 9 Oct 2005 15:58:23 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 43200DEA00651883; Sun, 9 Oct 2005 17:58:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Oct 2005 17:58:22 +0200 Content-class: urn:content-classes:message Message-ID: <4F9C9299A10AE74E89EA580D14AA10A605F562@royal64.emp.zapto.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gvinum startup problems Thread-Index: AcXKxrN2tOfyCoK2T3O0hshk7v5D5QAVMYggAHNosSA= From: "Daniel Eriksson" To: Cc: Lukas Ertl Subject: RE: gvinum startup problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 15:58:26 -0000 After the gvinum MFCs earlier today there has been some regression in the RELENG_6 branch. Starting gvinum manually works, but no device node is created (no /dev/gvinum dir at all). This means the array cannot be used. As before, auto-loading gvinum results in a broken array. Right after probing the ATA disks, the following message is printed on the console: GEOM_VINUM: subdisk 480GB.p0.s3 state change: down -> stale GEOM_VINUM: subdisk 480GB.p0.s0 state change: down -> stale This of course results in a broken array: # gvinum list 4 drives: D vd1 State: up /dev/ad3 A: 0/117800 MB (0%) D vd0 State: up /dev/ad2 A: 0/117800 MB (0%) D vd3 State: up /dev/ad1 A: 0/117800 MB (0%) D vd2 State: up /dev/ad0 A: 0/117800 MB (0%) 1 volume: V 480GB State: down Plexes: 1 Size: 460 GB 1 plex: P 480GB.p0 S State: down Subdisks: 4 Size: 460 GB 4 subdisks: S 480GB.p0.s3 State: stale D: vd3 Size: 115 GB S 480GB.p0.s2 State: up D: vd2 Size: 115 GB S 480GB.p0.s1 State: up D: vd1 Size: 115 GB S 480GB.p0.s0 State: stale D: vd0 Size: 115 GB Manually doing "gvinum setstate up 480GB.p0.s0" and gvinum setstate up 480GB.p0.s3" brings the array back online, and it can be used as normal (fsck and mount). If gvinum really is this broken, shouldn't it be removed from RELENG_6? Or is this just something local on my setup? Oh, and there is still no manpage for gvinum. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 16:54:17 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A3816A41F for ; Sun, 9 Oct 2005 16:54:17 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from imap1u.univie.ac.at (imap1.unet.univie.ac.at [131.130.1.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A3443D48 for ; Sun, 9 Oct 2005 16:54:14 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from korben.prv.univie.ac.at (korben.prv.univie.ac.at [131.130.7.98]) by imap1u.univie.ac.at (8.12.10/8.12.10) with ESMTP id j99Gs3eK012804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Oct 2005 18:54:05 +0200 (CEST) Date: Sun, 9 Oct 2005 18:54:02 +0200 (CEST) From: Lukas Ertl To: Daniel Eriksson In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A605F55E@royal64.emp.zapto.org> Message-ID: <20051009185203.I605@korben.prv.univie.ac.at> References: <4F9C9299A10AE74E89EA580D14AA10A605F55E@royal64.emp.zapto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: RE: gvinum startup problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 16:54:17 -0000 On Fri, 7 Oct 2005, Daniel Eriksson wrote: > I just tried booting with kern.geom.debugflags=1 and > geom_vinum_load="YES" in /boot/loader.conf (latest RELENG_6), and the > result was not good: Well, according to the logfiles, you seem to have slices on ad0 and others, which can cause confusion. How are your disks partitioned and labeled? thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 17:02:15 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C20A616A420 for ; Sun, 9 Oct 2005 17:02:15 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from imap1u.univie.ac.at (imap1.unet.univie.ac.at [131.130.1.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8CA143D46 for ; Sun, 9 Oct 2005 17:02:14 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from korben.prv.univie.ac.at (korben.prv.univie.ac.at [131.130.7.98]) by imap1u.univie.ac.at (8.12.10/8.12.10) with ESMTP id j99H2AeK014586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Oct 2005 19:02:11 +0200 (CEST) Date: Sun, 9 Oct 2005 19:02:09 +0200 (CEST) From: Lukas Ertl To: Daniel Eriksson In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A605F562@royal64.emp.zapto.org> Message-ID: <20051009185600.V605@korben.prv.univie.ac.at> References: <4F9C9299A10AE74E89EA580D14AA10A605F562@royal64.emp.zapto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: RE: gvinum startup problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 17:02:16 -0000 On Sun, 9 Oct 2005, Daniel Eriksson wrote: > After the gvinum MFCs earlier today there has been some regression in > the RELENG_6 branch. Yes. Due to the fact that the GEOM framework handles class load events differently on a cold boot and after boot, and how it lets these classes taste other providers, I had to make a decision. The only correct way to start geom_vinum now is from /boot/loader.conf. > If gvinum really is this broken, shouldn't it be removed from RELENG_6? If it is really this broken, you should send patches. > Or is this just something local on my setup? That's what I suspect, please see my earlier mail about slices/partitions. You may have forgotten to add some offsets to any slices/bsdlabels you have configured as vinum drives. > Oh, and there is still no manpage for gvinum. I have a man page and other stuff from the Google Summer of Code project, which I will integrate after the release. thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 20:01:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDDB416A41F for ; Sun, 9 Oct 2005 20:01:43 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA83943D48 for ; Sun, 9 Oct 2005 20:01:42 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id DC88B2C43D; Sun, 9 Oct 2005 22:01:41 +0200 (CEST) Date: Sun, 9 Oct 2005 22:01:41 +0200 From: Thomas Quinot To: freebsd-current@freebsd.org Message-ID: <20051009200141.GA85570@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.8i Subject: 6.0-BETA5: Sees only first ATA RAID volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 20:01:44 -0000 Hi *, Doing some experiments on a Dell Precision 380 with ICH7 (Intel MatrixRAID) SATA RAID controller. There are three 160 Gb SATA disks in the machine. In the BIOS, I configured two RAID volumes: * one mirror (RAID1) with a capacity of 110 Gb, involving the first two disks (leaving 50 Gb of free space on each disk); * one striped (RAID0) using the remainder of the space of each of the first two disks. (the 3rd disk is completely outside of the RAID system). When booting up, I see the three physical disks as ad4, ad6, and ad8, buth only the first RAID volume as ar0 (with a disk size that looks like the expected 110 Gb) - I do not see any ar1 striped volume. Is this a bug? A known limitation? Anything specific I need to set up? Thanks! Thomas. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 21:40:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D6F16A420 for ; Sun, 9 Oct 2005 21:40:05 +0000 (GMT) (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 9158C43D46 for ; Sun, 9 Oct 2005 21:39:56 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EOirU-0002i4-NS for freebsd-current@freebsd.org; Sun, 09 Oct 2005 23:37:40 +0200 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 09 Oct 2005 23:37:40 +0200 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 09 Oct 2005 23:37:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Joshua Coombs" Date: Sun, 9 Oct 2005 17:36:10 -0400 Lines: 97 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: news Subject: Success, kinda... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 21:40:05 -0000 Copyright (c) 1992-2005 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 6.0-BETA5 #0: Mon Sep 19 00:12:45 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Cyrix 486DRx2 (486-class CPU) Origin = "CyrixInstead" DIR=0x2207 Stepping=2 Revision=2 real memory = 67108864 (64 MB) avail memory = 56139776 (53 MB) npx0: [FAST] npx0: on motherboard npx0: IRQ 13 interface cpu0 on motherboard eisa0: on motherboard mainboard0: <@@@0000 (System Board)> on eisa0 slot 0 eisa0: unknown card @@@0000 (0x00000000) at slot 1 eisa0: unknown card @@@0000 (0x00000000) at slot 2 eisa0: unknown card @@@0000 (0x00000000) at slot 3 eisa0: unknown card @@@0000 (0x00000000) at slot 4 eisa0: unknown card @@@0000 (0x00000000) at slot 5 eisa0: unknown card @@@0000 (0x00000000) at slot 6 eisa0: unknown card @@@0000 (0x00000000) at slot 7 eisa0: unknown card @@@0000 (0x00000000) at slot 8 eisa0: unknown card @@@0000 (0x00000000) at slot 9 isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xdc000-0xdffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16450 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16450 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 aha1 at port 0x330-0x333 irq 11 drq 5 on isa0 aha1: AHA-1542CF FW Rev. B.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs aha1: [GIANT-LOCKED] ed1: at port 0x240-0x25f irq 5 on isa0 ed1: Ethernet address: 00:80:c8:da:a6:f0 ed1: type NE2000 (16 bit) Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle da0 at aha1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8) da0: 4095MB (8388315 512 byte sectors: 64H 32S/T 4095C) da1 at aha1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8) da1: 8347MB (17096357 512 byte sectors: 64H 32S/T 8347C) da2 at aha1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8) da2: 8347MB (17096357 512 byte sectors: 64H 32S/T 8347C) cd0 at aha1 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Logical unit is in process of becoming ready So, my hotrodded 386 is now pushing 6.0b5. Unfortunatly I toasted it pretty bad trying to move from 4.11 to 5.4, so it's a fresh install that I'm scrambling to get re-setup. One thing I noticed in this debacle, when I booted under 5-stable, my SCSI card, AHA1 did not report as being stuck under the giant lock, yet it is under 6.0b5? I'm hoping thats the cause of my throughput regression. Under 4.11 I could sustain 1.4MB/sec writing to disc, 5-Stable held at 1.2MB/sec, I'm now down at 800KB/sec with 6.0b5. Are all the debug options disabled in beta 5, or are they going to stay until RC1? Joshua Coombs From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 21:47:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2173616A41F for ; Sun, 9 Oct 2005 21:47:58 +0000 (GMT) (envelope-from lonniev@predictableresponse.com) Received: from predictableresponse.com (s1.n31.vds2000.com [66.84.31.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB7E43D45 for ; Sun, 9 Oct 2005 21:47:57 +0000 (GMT) (envelope-from lonniev@predictableresponse.com) Received: from PREDICTABLE (216-58-174-109.speedtrail.net [216.58.174.109]) by predictableresponse.com (8.11.6/8.11.6) with ESMTP id j99LluZ14614 for ; Sun, 9 Oct 2005 17:47:56 -0400 From: "Lonnie VanZandt" Sender: "Lonnie VanZandt" To: Date: Sun, 9 Oct 2005 15:49:23 -0600 Organization: Predictable Response Consulting Message-ID: <200509220742.10364.lonnie.vanzandt@ngc.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007D_01C5CCE9.060ED9D0" X-Mailer: Microsoft Outlook, Build 10.0.6626 X-OriginalArrivalTime: 22 Sep 2005 13:43:53.0149 (UTC) FILETIME=[ABA46ED0:01C5BF7B] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Cdiff patch for kernel gdb and mi_switch panic in freebsd 5.4 STABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lonnie.vanzandt@ngc.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, 09 Oct 2005 21:47:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_007D_01C5CCE9.060ED9D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached is the patch for the revised subr_kdb.c from FreeBSD 5.4 STABLE. (the rcsid is __FBSDID("$FreeBSD: src/sys/kern/subr_kdb.c,v 1.5.2.2.2.1 2005/05/01 05:38:14 dwhite Exp $"); ) On Wednesday 21 September 2005 03:14 pm, Lonnie VanZandt wrote: > Yes, the situation is greatly improved with this edit (plus a wee bit > more). Once the target reboots, I'll send along its revised subr_kdb.c > file. Feel free to tell me where to officially submit a bug report and > a proposed patch. > > On Wednesday 21 September 2005 01:14 pm, Lonnie VanZandt wrote: > > No, critical_enter() is _not_ SMP-safe. So, on an SMP system, a CPU > > outside of the one currently in KDB can resume running and trap on > > any inserted breakpoint _before_ kdb_active is decremented back to > > 0. Et voila! mi_switch will panic. > > > > I'll move the decrement, rebuild the kernel, try the result, and > > report back later what I find. > > > > On Wednesday 21 September 2005 01:09 pm, Lonnie VanZandt wrote: > > > In this snippet, > > > > > > #ifdef SMP > > > if (did_stop_cpus) > > > restart_cpus(stopped_cpus); > > > #endif > > > > > > kdb_active--; > > > > > > critical_exit(); > > > > > > Wouldn't it be better (or even required) to move the decrement of > > > kdb_active _before_ restarting stopped CPUs? Maybe > > > critical_enter()/critical_exit() implies an SMP-safe region? > > > > > > On Wednesday 21 September 2005 01:03 pm, Lonnie VanZandt wrote: > > > > A gtags/global search for kdb_active reports that the variable > > > > is never explicitly set back to 0 and is only set in > > > > kern/subr_kdb.c in kdb_trap(). There, it is incremented on entry > > > > and decremented on exit. That seems appropriate. Maybe there is > > > > an SMP oversight and the second CPU is triggering a trap back > > > > into the debugger? (That would imply that the other CPU wasn't > > > > really stopped or that there is a race condition with setting > > > > kdb_active back to false and CPUs coming out of the stopped > > > > state.) > > > > > > > > Or perhaps something is not quite right with the ddb/kdb/gdb > > > > interactions for kdb_reenter()? > > > > > > > > On Wednesday 21 September 2005 12:32 pm, Lonnie VanZandt wrote: > > > > > In 5.4 Stable, when attempting to debug kernels remotely, I > > > > > all too frequently encounter panics within the target kernel > > > > > as it attempts to return to the stopped thread. > > > > > > > > > > The panic report shows that this code is getting triggered: > > > > > > > > > > /* > > > > > * Don't perform context switches from the debugger. > > > > > */ > > > > > if (kdb_active) { > > > > > mtx_unlock_spin(&sched_lock); > > > > > kdb_backtrace(); > > > > > kdb_reenter(); > > > > > panic("%s: did not reenter debugger", __func__); > > > > > } > > > > > > > > > > My initial guess is that somewhere kdb_active is not getting > > > > > set back to 0/False. > > > > > > > > > > Is there a post-5.4 fix for this? ------------------------------------------------------- ------=_NextPart_000_007D_01C5CCE9.060ED9D0 Content-Type: text/x-diff; name="cdiff.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cdiff.out" *** subr_kdb.c.orig Wed Sep 21 15:27:16 2005 --- /tmp/subr_kdb.c Wed Sep 21 15:23:23 2005 *************** *** 444,455 **** makectx(tf, &kdb_pcb); critical_enter(); ! kdb_active++; ! kdb_frame = tf; ! kdb_thr_select(curthread); ! #ifdef SMP if ((did_stop_cpus = kdb_stop_cpus) != 0) { --- 444,454 ---- makectx(tf, &kdb_pcb); + // disable interrupts to our own CPU critical_enter(); ! // halt any other CPUs who might trip over our ! // traps and try to rush into KDB before us #ifdef SMP if ((did_stop_cpus = kdb_stop_cpus) != 0) { *************** *** 462,479 **** } #endif /* Let MD code do its thing first... */ kdb_cpu_trap(type, code); handled = kdb_dbbe->dbbe_trap(type, code); #ifdef SMP if (did_stop_cpus) restart_cpus(stopped_cpus); #endif ! kdb_active--; ! critical_exit(); return (handled); --- 461,497 ---- } #endif + // we can't be interrupted now and we must be + // the only running CPU. So, if kdb_active remains 0 + // then we have won the race to enter KDB, otherwise + // some other CPU beat us through the gate... + if ( 0 != kdb_active ) + { + return 0; + } + + // claim the prize + kdb_active++; + + // set the kdb context + kdb_frame = tf; + kdb_thr_select( curthread ); + /* Let MD code do its thing first... */ kdb_cpu_trap(type, code); handled = kdb_dbbe->dbbe_trap(type, code); + // release the prize + kdb_active--; + + // let other CPUs have a chance to run #ifdef SMP if (did_stop_cpus) restart_cpus(stopped_cpus); #endif ! // let our own ISRs to run critical_exit(); return (handled); ------=_NextPart_000_007D_01C5CCE9.060ED9D0-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 23:13:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC06E16A41F for ; Sun, 9 Oct 2005 23:13:26 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34AFA43D45 for ; Sun, 9 Oct 2005 23:13:26 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by xproxy.gmail.com with SMTP id t6so97467wxc for ; Sun, 09 Oct 2005 16:13:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=mtoDHSB+lefxdxQ1/fRu9uh6H7ZyrhPwTipvaCieg8GmoYjMAUqVfipJemXfo+XCuYRM85347O17QjvJkWPbGglN0YY49JyO+9eKZJkq0lmwi1kr+xBZqzNLOYVcEPqmy6gi78/dd/H96sYPRRzHF0gGJumKqd5jhaZv3rP4X+4= Received: by 10.70.18.9 with SMTP id 9mr3266558wxr; Sun, 09 Oct 2005 16:13:25 -0700 (PDT) Received: by 10.70.9.2 with HTTP; Sun, 9 Oct 2005 16:13:25 -0700 (PDT) Message-ID: <47d0403c0510091613y5dcdf47t3992be6388fb22a5@mail.gmail.com> Date: Sun, 9 Oct 2005 18:13:25 -0500 From: Ben Kaduk To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ndis0 does not associate to open AP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 23:13:26 -0000 Hi all, My apologies if this is not the best list to which to send this. I've been trying to get my dell laptop's built-in wireless card to work with my university's wireless network for quite some time now, but nothing I try seems to work. This is on a recent -current: # uname -a FreeBSD prolepsis.urh.uiuc.edu 7.0-CURRENTFreeBSD 7.0-CURRENT #15: Sat Oct 8 01:02:04 UTC 2005 kaduk@prolepsis.urh.uiuc.edu:/usr/obj/usr/src/sys/PROLEPSIS i386 The university's setup, so far as I can tell, is as follows: They have all access points open for association, but do not allow access to the outside world -- when an http page is first requested, the request is intercepted and substituted with a university page that has a link to a kerberos-based authentication, or directions on how to use their vpn client. After authentication, the protocol used is IPSec over UDP. The main point is that the access points are open and running dhcp servers, as confirmed on my iBook (on which I'm writing this message). However, when I try to use the ndis driver on my dell to try to associate with this AP and run dhclient, I get far-from-desireable results. I am using recent (~2 week old) windows xp drivers for my broadcom (4324?) card and I have regenerated bcmwl5_sys.ko after my latest buildworld, using ndisgen(8). The wireless card is listed in pciconf -lv as: ndis0@pci2:3:0: class=3D0x028000 card=3D0x00011028 chip=3D0x432414e4 rev=3D= 0x02 hdr=3D0x00[possibly more off screen] vendor =3D 'Broadcom Corporation' device =3D 'BCM4309 802.11a/b/g Wireless LAN Controller' class =3D 'network' In windows XP, this card is able to successfully associate with the university AP. The bcmwl5_sys.ko module produced by ndisgen seems to load successfully: # kldload bcmwl5_sys warning: KLD '/boot/modules/bcmwl5_sys.ko' is newer than the linker.hintsfi= le ndis0: mem 0xfaff6000-0xfaff7fff irq 9 at device 3.0 on pci2 ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:90:4b:2d:46:ce # I can then scan and see (several) APs: #ifconfig ndis0 up scan SSID BSSID CHAN RATE S:N INT CAPS UIUCnet [bssid1] 1 54M 151:0 100 E [5x ???] WME VEN VEN UIUCnet [bssid2] 6 54M 120:0 100 E [5x ???] WME VEN VEN WME UIUCnet [bssid3] 36 54M 130:0 100 E ??? ??? WME VEN VEN I can then try to associate to one (the same one that my iBook picks by default): # ifconfig ndis0 ssid UIUCnet bssid [bssid1] # ifconfig ndis0 ndis0: flags=3D8843 mtu 1500 inet6 fe80::290:4bff:fe2d:46ce%ndis0 prefixlen 64 scopeid 0x4 ether 00:90:4b:2d:46:ce mdeia: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ndis0: failed to get bssid ssid "" channel 1 authmode OPEN privacy OFF txpowmax 100 protmode CTS # (The "failed to get bssid" bit is the console log) The result is the same whether or not I have a dhclient attached to ndis0. Am I doing something stupid, or missing something obvious? I can get more info if necessary. Thanks Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 23:29:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0AEE16A41F; Sun, 9 Oct 2005 23:29:00 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BF7343D49; Sun, 9 Oct 2005 23:28:57 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j99NSrjZ028025; Mon, 10 Oct 2005 03:28:53 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j99NSoL8028023; Mon, 10 Oct 2005 03:28:50 +0400 (MSD) (envelope-from yar) Date: Mon, 10 Oct 2005 03:28:49 +0400 From: Yar Tikhiy To: Andrew Thompson , Brooks Davis , Pawel Jakub Dawidek , FreeBSD Current , Brooks Davis Message-ID: <20051009232849.GA27349@comp.chem.msu.su> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051005210950.GB75848@heff.fud.org.nz> User-Agent: Mutt/1.5.9i Cc: Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 23:29:01 -0000 On Thu, Oct 06, 2005 at 10:09:50AM +1300, Andrew Thompson wrote: > On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: > > On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: > > > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: > > > +> Hi, > > > +> > > > +> I have found a repeatable panic with network device cloning, unfortunatly I am > > > +> unable to dump on this box. This is sparc64 with a 2 day old current. > > > > > > The order is wrong in vlan_modevent(). > > > > > > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() should not > > > be called after that. > > > > > > This patch should fix the problem: > > > > > > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch > > > > Yes. This does introduce a race in that a new interface could > > be created between the vlan_clone_destroy loop and the call to > > if_clone_detach. > > I dont think this is the problem. IF_CLONE_REMREF(ifc) is freeing > ifc->ifc_units in if_clone_detach(). It look like the ref counting isnt > working quite right. FWIW, I tried to look at the $subject problem since I had had it before, but just got a different panic: Memory modified after free 0xc140b000(4092) val=deadc0dc @ 0xc140b000 panic: Most recently used by clone The clone code seems to have decremented something (refcount?) twice after freeing the memory chunk. -- Yar From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 23:36:39 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD7D616A41F; Sun, 9 Oct 2005 23:36:39 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AB2D43D45; Sun, 9 Oct 2005 23:36:38 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 6BDFF1CCDD; Mon, 10 Oct 2005 12:36:37 +1300 (NZDT) Date: Mon, 10 Oct 2005 12:36:37 +1300 From: Andrew Thompson To: Yar Tikhiy Message-ID: <20051009233637.GA95679@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Yar Tikhiy , Brooks Davis , Pawel Jakub Dawidek , FreeBSD Current , Brooks Davis References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051009232849.GA27349@comp.chem.msu.su> User-Agent: Mutt/1.4.2.1i Cc: Brooks Davis , Pawel Jakub Dawidek , FreeBSD Current Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2005 23:36:39 -0000 On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: > On Thu, Oct 06, 2005 at 10:09:50AM +1300, Andrew Thompson wrote: > > On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: > > > On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: > > > > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: > > > > +> Hi, > > > > +> > > > > +> I have found a repeatable panic with network device cloning, unfortunatly I am > > > > +> unable to dump on this box. This is sparc64 with a 2 day old current. > > > > > > > > The order is wrong in vlan_modevent(). > > > > > > > > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() should not > > > > be called after that. > > > > > > > > This patch should fix the problem: > > > > > > > > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch > > > > > > Yes. This does introduce a race in that a new interface could > > > be created between the vlan_clone_destroy loop and the call to > > > if_clone_detach. > > > > I dont think this is the problem. IF_CLONE_REMREF(ifc) is freeing > > ifc->ifc_units in if_clone_detach(). It look like the ref counting isnt > > working quite right. > > FWIW, I tried to look at the $subject problem since I had had it > before, but just got a different panic: > > Memory modified after free 0xc140b000(4092) val=deadc0dc @ 0xc140b000 > panic: Most recently used by clone > > The clone code seems to have decremented something (refcount?) twice > after freeing the memory chunk. Yes, it still clears the interface bit in ifc_units in ifc_free_unit() after freeing the memory (for if_vlan and if_stf). I want to change the refcounting to count the number of cloned interfaces and have been playing with the code. The main problem is when a module is unloaded it doesnt use the if_clone* routines when destoying the interfaces in the simple_clone case. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 00:52:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B09916A41F for ; Mon, 10 Oct 2005 00:52:51 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-3.paradise.net.nz (bm-3a.paradise.net.nz [203.96.152.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA89F43D45 for ; Mon, 10 Oct 2005 00:52:50 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-2.paradise.net.nz ([203.96.152.177]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IO4002E5D424L@linda-3.paradise.net.nz> for freebsd-current@freebsd.org; Mon, 10 Oct 2005 13:52:50 +1300 (NZDT) Received: from [192.168.1.11] (218-101-14-70.paradise.net.nz [218.101.14.70]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id B61C8535576; Mon, 10 Oct 2005 13:52:49 +1300 (NZDT) Date: Mon, 10 Oct 2005 13:52:48 +1300 From: Mark Kirkwood In-reply-to: <20051009020725.GC223@cirb503493.alcatel.com.au> To: Peter Jeremy Message-id: <4349BB60.70508@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) References: <20050921174155.GB80991@xor.obsecurity.org> <43486C48.3090404@paradise.net.nz> <20051009020725.GC223@cirb503493.alcatel.com.au> Cc: Joseph Peralta , freebsd-current@freebsd.org Subject: Re: errors during buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 00:52:51 -0000 Peter Jeremy wrote: > On Sun, 2005-Oct-09 14:03:04 +1300, Mark Kirkwood wrote: > > Cooling isn't the only hardware problem. Marginal PSUs or marginal > electros on the motherboard are also quite common - especially if > the hardware is getting old. Electrolytic capacitors have a finite > life and this is shortened by heat and high ripple currents - both > of which are common in computers. > To try to nail this down, I reinstalled BETA3 (which had previously never had this problem) and performed a buildworld. I am seeing internal errors there too now, so looks like you are correct (time to break out that spare motherboard). Cheers Mark From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 00:57:59 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16C6716A41F; Mon, 10 Oct 2005 00:57:59 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7240F43D45; Mon, 10 Oct 2005 00:57:58 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 4349BB8600000050; Mon, 10 Oct 2005 02:54:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2005 01:52:47 +0200 Content-class: urn:content-classes:message Message-ID: <4F9C9299A10AE74E89EA580D14AA10A605F564@royal64.emp.zapto.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gvinum startup problems Thread-Index: AcXM8h+R9Tn8dRWlQ7K3pox89aPNewAOc5og From: "Daniel Eriksson" To: Cc: Lukas Ertl Subject: RE: gvinum startup problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 00:57:59 -0000 Lukas Ertl wrote: > Well, according to the logfiles, you seem to have slices on ad0 and=20 > others, which can cause confusion. How are your disks=20 > partitioned and labeled? The array is running directly on the "raw" devices. No partitions or slices, and no labels. # gvinum printconfig # Vinum configuration of xxx, saved at Mon Oct 10 01:47:35 2005 drive vd1 device /dev/ad3 drive vd0 device /dev/ad2 drive vd3 device /dev/ad1 drive vd2 device /dev/ad0 volume 480GB plex name 480GB.p0 org striped 558s vol 480GB sd name 480GB.p0.s3 drive vd3 len 241254090s driveoffset 265s plex 480GB.p0 plexoffset 1674s sd name 480GB.p0.s2 drive vd2 len 241254090s driveoffset 265s plex 480GB.p0 plexoffset 1116s sd name 480GB.p0.s1 drive vd1 len 241254090s driveoffset 265s plex 480GB.p0 plexoffset 558s sd name 480GB.p0.s0 drive vd0 len 241254090s driveoffset 265s plex 480GB.p0 plexoffset 0s /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 00:57:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B98716A421; Mon, 10 Oct 2005 00:57:59 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725A943D46; Mon, 10 Oct 2005 00:57:58 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 4349BB860000004F; Mon, 10 Oct 2005 02:54:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2005 01:36:39 +0200 Content-class: urn:content-classes:message Message-ID: <4F9C9299A10AE74E89EA580D14AA10A605F563@royal64.emp.zapto.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6.0-BETA5: Sees only first ATA RAID volume Thread-Index: AcXNDMA6T/6vKocNRQ+kAbHuRgVLBQAHOcMg From: "Daniel Eriksson" To: Cc: Thomas Quinot Subject: RE: 6.0-BETA5: Sees only first ATA RAID volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 00:57:59 -0000 Thomas Quinot wrote: > When booting up, I see the three physical disks as ad4, ad6, and ad8,=20 > buth only the first RAID volume as ar0 (with a disk size that=20 > looks like > the expected 110 Gb) - I do not see any ar1 striped volume. >=20 > Is this a bug? A known limitation? Anything specific I need to set up? I don't think ataraid is capable of handling arrays on anything less than the full disk. At least this is the case when defining the arrays using atacontrol. You probably need to partition/slice the disk and then use gmirror/gstripe to get this working if you really need different types of arrays. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 02:22:10 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9810716A41F; Mon, 10 Oct 2005 02:22:10 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6099E43D45; Mon, 10 Oct 2005 02:22:09 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 4EEBA1CCDD; Mon, 10 Oct 2005 15:22:08 +1300 (NZDT) Date: Mon, 10 Oct 2005 15:22:08 +1300 From: Andrew Thompson To: Yar Tikhiy Message-ID: <20051010022208.GA97249@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Yar Tikhiy , Brooks Davis , Pawel Jakub Dawidek , FreeBSD Current , Brooks Davis References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <20051009232849.GA27349@comp.chem.msu.su> User-Agent: Mutt/1.4.2.1i Cc: Brooks Davis , Pawel Jakub Dawidek , FreeBSD Current Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 02:22:10 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: > On Thu, Oct 06, 2005 at 10:09:50AM +1300, Andrew Thompson wrote: > > On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: > > > On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: > > > > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: > > > > +> Hi, > > > > +> > > > > +> I have found a repeatable panic with network device cloning, unfortunatly I am > > > > +> unable to dump on this box. This is sparc64 with a 2 day old current. > > > > > > > > The order is wrong in vlan_modevent(). > > > > > > > > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() should not > > > > be called after that. > > > > > > > > This patch should fix the problem: > > > > > > > > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch > > > > > > Yes. This does introduce a race in that a new interface could > > > be created between the vlan_clone_destroy loop and the call to > > > if_clone_detach. > > > > I dont think this is the problem. IF_CLONE_REMREF(ifc) is freeing > > ifc->ifc_units in if_clone_detach(). It look like the ref counting isnt > > working quite right. > > FWIW, I tried to look at the $subject problem since I had had it > before, but just got a different panic: > > Memory modified after free 0xc140b000(4092) val=deadc0dc @ 0xc140b000 > panic: Most recently used by clone > > The clone code seems to have decremented something (refcount?) twice > after freeing the memory chunk. I have been testing this patch and I think it fixes all the problems discussed. It changes refcounting to count the number of cloned interfaces so ifc_units is only freed when its safe. A new function has been added to decrement this when a simple cloner module is unloaded. The cloner is still detached first to prevent the race. In most cases the change is as simple as: while ((sc = LIST_FIRST(&gre_softc_list)) != NULL) { LIST_REMOVE(sc, sc_list); mtx_unlock(&gre_mtx); + ifc_simple_free(&gre_cloner, GRE2IFP(sc)); gre_destroy(sc); mtx_lock(&gre_mtx); } Andrew --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ifclone.diff" Index: contrib/pf/net/if_pflog.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pflog.c,v retrieving revision 1.15 diff -u -p -r1.15 if_pflog.c --- contrib/pf/net/if_pflog.c 9 Aug 2005 11:59:02 -0000 1.15 +++ contrib/pf/net/if_pflog.c 10 Oct 2005 01:56:26 -0000 @@ -360,6 +360,7 @@ static int pflog_modevent(module_t mod, int type, void *data) { int error = 0; + struct ifnet *ifp; switch (type) { case MOD_LOAD: @@ -369,8 +370,11 @@ pflog_modevent(module_t mod, int type, v case MOD_UNLOAD: if_clone_detach(&pflog_cloner); - while (!LIST_EMPTY(&pflog_list)) - pflog_clone_destroy(SCP2IFP(LIST_FIRST(&pflog_list))); + while (!LIST_EMPTY(&pflog_list)) { + ifp = SCP2IFP(LIST_FIRST(&pflog_list)); + ifc_simple_free(&pflog_cloner, ifp); + pflog_clone_destroy(ifp); + } break; default: Index: contrib/pf/net/if_pfsync.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pfsync.c,v retrieving revision 1.23 diff -u -p -r1.23 if_pfsync.c --- contrib/pf/net/if_pfsync.c 11 Sep 2005 11:55:39 -0000 1.23 +++ contrib/pf/net/if_pfsync.c 10 Oct 2005 01:56:32 -0000 @@ -1842,6 +1842,7 @@ static int pfsync_modevent(module_t mod, int type, void *data) { int error = 0; + struct ifnet *ifp; switch (type) { case MOD_LOAD: @@ -1851,9 +1852,11 @@ pfsync_modevent(module_t mod, int type, case MOD_UNLOAD: if_clone_detach(&pfsync_cloner); - while (!LIST_EMPTY(&pfsync_list)) - pfsync_clone_destroy( - SCP2IFP(LIST_FIRST(&pfsync_list))); + while (!LIST_EMPTY(&pfsync_list)) { + ifp = SCP2IFP(LIST_FIRST(&pfsync_list)); + ifc_simple_free(&pfsync_cloner, ifp); + pfsync_clone_destroy(ifp); + } break; default: Index: net/if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.23 diff -u -p -r1.23 if_bridge.c --- net/if_bridge.c 2 Oct 2005 19:15:56 -0000 1.23 +++ net/if_bridge.c 10 Oct 2005 01:56:43 -0000 @@ -356,8 +356,11 @@ bridge_modevent(module_t mod, int type, break; case MOD_UNLOAD: if_clone_detach(&bridge_cloner); - while (!LIST_EMPTY(&bridge_list)) + while (!LIST_EMPTY(&bridge_list)) { + ifc_simple_free(&bridge_cloner, + LIST_FIRST(&bridge_list)->sc_ifp); bridge_clone_destroy(LIST_FIRST(&bridge_list)->sc_ifp); + } uma_zdestroy(bridge_rtnode_zone); bridge_input_p = NULL; bridge_output_p = NULL; Index: net/if_clone.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_clone.c,v retrieving revision 1.6 diff -u -p -r1.6 if_clone.c --- net/if_clone.c 24 Feb 2005 13:14:41 -0000 1.6 +++ net/if_clone.c 10 Oct 2005 01:09:08 -0000 @@ -124,7 +124,6 @@ if_clone_create(char *name, size_t len) IF_CLONERS_LOCK(); LIST_FOREACH(ifc, &if_cloners, ifc_list) { if (ifc->ifc_match(ifc, name)) { - IF_CLONE_ADDREF(ifc); break; } } @@ -134,7 +133,6 @@ if_clone_create(char *name, size_t len) return (EINVAL); err = (*ifc->ifc_create)(ifc, name, len); - IF_CLONE_REMREF(ifc); return (err); } @@ -156,7 +154,6 @@ if_clone_destroy(const char *name) IF_CLONERS_LOCK(); LIST_FOREACH(ifc, &if_cloners, ifc_list) { if (strcmp(ifc->ifc_name, ifp->if_dname) == 0) { - IF_CLONE_ADDREF(ifc); break; } } @@ -172,7 +169,6 @@ if_clone_destroy(const char *name) err = (*ifc->ifc_destroy)(ifc, ifp); done: - IF_CLONE_REMREF(ifc); return (err); } @@ -352,7 +348,10 @@ ifc_alloc_unit(struct if_clone *ifc, int /* * Allocate the unit in the bitmap. */ + KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) == 0, + ("%s: bit is already set", __func__)); ifc->ifc_units[bytoff] |= (1 << bitoff); + IF_CLONE_ADDREF_LOCKED(ifc); done: IF_CLONE_UNLOCK(ifc); @@ -375,7 +374,7 @@ ifc_free_unit(struct if_clone *ifc, int KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) != 0, ("%s: bit is already cleared", __func__)); ifc->ifc_units[bytoff] &= ~(1 << bitoff); - IF_CLONE_UNLOCK(ifc); + IF_CLONE_REMREF_LOCKED(ifc); /* releases lock */ } void @@ -477,6 +476,22 @@ ifc_simple_destroy(struct if_clone *ifc, ifcs->ifcs_destroy(ifp); + ifc_simple_free(ifc, ifp); + + return (0); +} + +int +ifc_simple_free(struct if_clone *ifc, struct ifnet *ifp) +{ + int unit; + struct ifc_simple_data *ifcs = ifc->ifc_data; + + unit = ifp->if_dunit; + + if (unit < ifcs->ifcs_minifs) + return (EINVAL); + ifc_free_unit(ifc, unit); return (0); Index: net/if_clone.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_clone.h,v retrieving revision 1.2 diff -u -p -r1.2 if_clone.h --- net/if_clone.h 7 Jan 2005 01:45:34 -0000 1.2 +++ net/if_clone.h 9 Oct 2005 23:50:05 -0000 @@ -107,6 +107,7 @@ void ifc_simple_attach(struct if_clone * int ifc_simple_match(struct if_clone *, const char *); int ifc_simple_create(struct if_clone *, char *, size_t); int ifc_simple_destroy(struct if_clone *, struct ifnet *); +int ifc_simple_free(struct if_clone *, struct ifnet *); #endif /* _KERNEL */ Index: net/if_disc.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_disc.c,v retrieving revision 1.48 diff -u -p -r1.48 if_disc.c --- net/if_disc.c 26 Jun 2005 18:11:10 -0000 1.48 +++ net/if_disc.c 10 Oct 2005 01:57:12 -0000 @@ -152,6 +152,7 @@ disc_modevent(module_t mod, int type, vo while ((sc = LIST_FIRST(&disc_softc_list)) != NULL) { LIST_REMOVE(sc, sc_list); mtx_unlock(&disc_mtx); + ifc_simple_free(&disc_cloner, sc->sc_ifp); disc_destroy(sc); mtx_lock(&disc_mtx); } Index: net/if_faith.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_faith.c,v retrieving revision 1.37 diff -u -p -r1.37 if_faith.c --- net/if_faith.c 9 Aug 2005 10:19:58 -0000 1.37 +++ net/if_faith.c 10 Oct 2005 01:57:18 -0000 @@ -139,6 +139,7 @@ faithmodevent(mod, type, data) while ((sc = LIST_FIRST(&faith_softc_list)) != NULL) { LIST_REMOVE(sc, sc_list); mtx_unlock(&faith_mtx); + ifc_simple_free(&faith_cloner, sc->sc_ifp); faith_destroy(sc); mtx_lock(&faith_mtx); } Index: net/if_gif.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gif.c,v retrieving revision 1.54 diff -u -p -r1.54 if_gif.c --- net/if_gif.c 9 Aug 2005 10:19:58 -0000 1.54 +++ net/if_gif.c 10 Oct 2005 01:57:23 -0000 @@ -252,6 +252,7 @@ gifmodevent(mod, type, data) while ((sc = LIST_FIRST(&gif_softc_list)) != NULL) { LIST_REMOVE(sc, gif_list); mtx_unlock(&gif_mtx); + ifc_simple_free(&gif_cloner, GIF2IFP(sc)); gif_destroy(sc); mtx_lock(&gif_mtx); } Index: net/if_gre.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gre.c,v retrieving revision 1.34 diff -u -p -r1.34 if_gre.c --- net/if_gre.c 9 Aug 2005 10:19:58 -0000 1.34 +++ net/if_gre.c 10 Oct 2005 01:57:31 -0000 @@ -793,6 +793,7 @@ gremodevent(module_t mod, int type, void while ((sc = LIST_FIRST(&gre_softc_list)) != NULL) { LIST_REMOVE(sc, sc_list); mtx_unlock(&gre_mtx); + ifc_simple_free(&gre_cloner, GRE2IFP(sc)); gre_destroy(sc); mtx_lock(&gre_mtx); } Index: net/if_ppp.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ppp.c,v retrieving revision 1.108 diff -u -p -r1.108 if_ppp.c --- net/if_ppp.c 19 Sep 2005 22:27:07 -0000 1.108 +++ net/if_ppp.c 10 Oct 2005 01:57:38 -0000 @@ -298,6 +298,7 @@ ppp_modevent(module_t mod, int type, voi while ((sc = LIST_FIRST(&ppp_softc_list)) != NULL) { LIST_REMOVE(sc, sc_list); PPP_LIST_UNLOCK(); + ifc_simple_free(&ppp_cloner, PPP2IFP(sc)); ppp_destroy(sc); PPP_LIST_LOCK(); } Index: netinet/ip_carp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_carp.c,v retrieving revision 1.31 diff -u -p -r1.31 ip_carp.c --- netinet/ip_carp.c 9 Sep 2005 08:41:39 -0000 1.31 +++ netinet/ip_carp.c 10 Oct 2005 01:57:52 -0000 @@ -2133,6 +2133,7 @@ static int carp_modevent(module_t mod, int type, void *data) { int error = 0; + struct ifnet *ifp; switch (type) { case MOD_LOAD: @@ -2143,8 +2144,11 @@ carp_modevent(module_t mod, int type, vo case MOD_UNLOAD: if_clone_detach(&carp_cloner); - while (!LIST_EMPTY(&carpif_list)) - carp_clone_destroy(SC2IFP(LIST_FIRST(&carpif_list))); + while (!LIST_EMPTY(&carpif_list)) { + ifp = SC2IFP(LIST_FIRST(&carpif_list)); + ifc_simple_free(&carp_cloner, ifp); + carp_clone_destroy(ifp); + } mtx_destroy(&carp_mtx); break; --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 02:59:31 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 237FE16A41F; Mon, 10 Oct 2005 02:59:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B646643D45; Mon, 10 Oct 2005 02:59:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9A2vJJO013364; Sun, 9 Oct 2005 20:57:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 09 Oct 2005 20:58:20 -0600 (MDT) Message-Id: <20051009.205820.129710153.imp@bsdimp.com> To: avatar@mmlab.cse.yzu.edu.tw From: "M. Warner Losh" In-Reply-To: <0510091447540.81426@www.mmlab.cse.yzu.edu.tw> References: <200510081630.j98GU1Sf021682@sakura.ninth-nine.com> <0510091447540.81426@www.mmlab.cse.yzu.edu.tw> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 09 Oct 2005 20:57:19 -0600 (MDT) Cc: freebsd-current@FreeBSD.org, nork@FreeBSD.org Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 02:59:31 -0000 In message: <0510091447540.81426@www.mmlab.cse.yzu.edu.tw> Tai-hwa Liang writes: : On Sun, 9 Oct 2005, Norikatsu Shigemura wrote: : > dhclient with if_wi&WEP will freeze on 7-current. : > : > I am using following if_wi and WEP. : [...] : > Oct 8 22:01:08 pelsia kernel: Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_cmd 0x0000; event status 0x8008 : > Oct 8 22:01:08 pelsia kernel: wi0: wi_cmd: busy bit won't clear. : > Oct 8 22:01:08 pelsia kernel: wi0: init failed : > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc00/0 : > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc81/0 : > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc85/0 : > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc2a/0 : > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc28/0 : > Oct 8 22:01:08 pelsia kernel: wi0: timeout in wi_seek to fc80/0 : > Oct 8 22:01:08 pelsia kernel: wi0: failed to allocate 2372 bytes on NIC : > Oct 8 22:01:08 pelsia kernel: wi0: tx buffer allocation failed (error 12) : > Oct 8 22:01:08 pelsia kernel: wi0: interface not running : [...] : : Sometimes I run into this whilst running "ifconfig wi0 up" w/o if_wi.ko : loaded; that is, the "busy bit won't clear, init failed" happens to my : R40(builtin wi miniPCI) regardless of whether or not the WEP is enabled. : : It looks to me that the firmware doesn't ack. properly at that moment : (unfortunately I have no idea about how to fix this); however, the second : retry("kldunload if_wi" then "ifconfig wi0 up" again) works for me. ifconfig wi0 down; ifconfig wi0 up causes wi_stop and wi_init to be called, which does a pretty good job at resetting the card. It does everything except a COR reset to the card, which is rarely (but sometimes) needed to unwedge the card. Warner From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 06:04:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52AFA16A41F for ; Mon, 10 Oct 2005 06:04:06 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3C7E43D46 for ; Mon, 10 Oct 2005 06:04:05 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so111707nzd for ; Sun, 09 Oct 2005 23:04:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=H8NlYZOzB8irmtow1HFEJol2rcBRoQ1KYxfcsyynw4daTOZFetnSt5WFGaoU0GewjJ0qQh0+x9lL2Z16BGPoEKIz/SwkzLUYgnIdXtEeZp4G95vjJJu3EFzhKrC/N7wAM+Rbm7dtVM8rf/iJuVmq49lmqDPeGREgflEdgwlNPlI= Received: by 10.36.20.8 with SMTP id 8mr3544892nzt; Sun, 09 Oct 2005 23:04:05 -0700 (PDT) Received: from michelle.rndsoft.co.kr ( [211.32.202.217]) by mx.gmail.com with ESMTP id 17sm8375nzo.2005.10.09.23.04.01; Sun, 09 Oct 2005 23:04:05 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j9A639A6002240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 15:03:09 +0900 (KST) (envelope-from yongari@gmail.com) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j9A630bN002239; Mon, 10 Oct 2005 15:03:00 +0900 (KST) (envelope-from yongari@gmail.com) Date: Mon, 10 Oct 2005 15:03:00 +0900 From: Pyun YongHyeon To: Gavin Atkinson Message-ID: <20051010060300.GA740@rndsoft.co.kr> References: <200510061139.37825.lists@jnielsen.net> <1128704293.29031.5.camel@buffy.york.ac.uk> <200510071557.50553.lists@jnielsen.net> <20051008172037.O56323@ury.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051008172037.O56323@ury.york.ac.uk> User-Agent: Mutt/1.4.2.1i Cc: John Nielsen , current@freebsd.org Subject: Re: Broadcom BCM5751 not attaching on IBM ThinkCentre A51 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, 10 Oct 2005 06:04:06 -0000 On Sat, Oct 08, 2005 at 07:14:21PM +0100, Gavin Atkinson wrote: > On Fri, 7 Oct 2005, John Nielsen wrote: > >On Friday 07 October 2005 12:58, Gavin Atkinson wrote: > >>Can you post the output of pciconf -l please? > > > >Attached, along with dmesg output and kernel config file (basically a > >stripped-down GENERIC). > > Can you try applying the attached patch, and the patch in > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79139 and if the latter > patch makes no difference, show the output of the extra line? > > You could also try http://people.freebsd.org/~yongari/bge.patch.0908 - but > I don't believe it will help in this case. (it's actually to fix endian > issues on other platforms, but it does change the way the driver talks to > the chip subtly) > I don't think the above patch would help here too. The patch will fix endian issues and add a lock to protect jumbo frame handling. Stock bge(4) had no locking for jumbo frame handling such that the use of jumbo frame always paniced entire system. It also try to fix unloading issues observed on sparc64. I'm still waiting for report on ia64. BTW, the lastest patch for HEAD is available at: http://people.freebsd.org/~yongari/bge.patch.1010 -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 06:25:04 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A16B16A41F; Mon, 10 Oct 2005 06:25:04 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB33B43D45; Mon, 10 Oct 2005 06:25:03 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9A6NugJ094450; Mon, 10 Oct 2005 08:23:56 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: <20051009200141.GA85570@melusine.cuivre.fr.eu.org> References: <20051009200141.GA85570@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <09BF04FC-B401-4EFF-9FE1-CA20D58D651B@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 10 Oct 2005 08:24:59 +0200 To: Thomas Quinot X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-BETA5: Sees only first ATA RAID volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 06:25:04 -0000 On 09/10/2005, at 22:01, Thomas Quinot wrote: > Hi *, > > Doing some experiments on a Dell Precision 380 with ICH7 (Intel > MatrixRAID) SATA RAID controller. There are three 160 Gb SATA disks > in the machine. > > In the BIOS, I configured two RAID volumes: > * one mirror (RAID1) with a capacity of 110 Gb, involving the > first two disks (leaving 50 Gb of free space on each disk); > * one striped (RAID0) using the remainder of the space of each > of the first two disks. > > (the 3rd disk is completely outside of the RAID system). > > When booting up, I see the three physical disks as ad4, ad6, and ad8, > buth only the first RAID volume as ar0 (with a disk size that looks =20= > like > the expected 110 Gb) - I do not see any ar1 striped volume. > > Is this a bug? A known limitation? Anything specific I need to set up? =46rom ata-raid.c::ata_raid_intel_read_meta() /* * update our knowledge about the array config based on =20 generation * we only grap the first volume description (yet) since the * BIOS'n I have access to puts crap into the following ones */ There's your explanation :) When/If I get my hands on HW that supports this I'll add the support =20 to the ataraid driver.. BTW it knows how to deal with multiple RAID's on the same disks, but =20 no BIOS's I've had access to so far has allowed this yet... S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 06:59:28 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAF7D16A41F for ; Mon, 10 Oct 2005 06:59:28 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from imap1u.univie.ac.at (imap1.unet.univie.ac.at [131.130.1.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D99F043D5C for ; Mon, 10 Oct 2005 06:59:27 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from korben.prv.univie.ac.at (korben.prv.univie.ac.at [131.130.7.98]) by imap1u.univie.ac.at (8.12.10/8.12.10) with ESMTP id j9A6xGeK057551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 08:59:18 +0200 (CEST) Date: Mon, 10 Oct 2005 08:59:16 +0200 (CEST) From: Lukas Ertl To: Daniel Eriksson In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A605F564@royal64.emp.zapto.org> Message-ID: <20051010085559.T602@korben.prv.univie.ac.at> References: <4F9C9299A10AE74E89EA580D14AA10A605F564@royal64.emp.zapto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: RE: gvinum startup problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 06:59:29 -0000 On Mon, 10 Oct 2005, Daniel Eriksson wrote: > The array is running directly on the "raw" devices. No partitions or > slices, and no labels. It looks to me as if there's some leftover MBR. Otherwise, I wouldn't know why there's an ad0s1 offered to taste. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 10:57:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B9D616A41F for ; Mon, 10 Oct 2005 10:57:26 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from esemetz.metz.supelec.fr (esemetz.metz.supelec.fr [193.48.224.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id C009C43D46 for ; Mon, 10 Oct 2005 10:57:25 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from smtp.metz.supelec.fr (smtp.metz.supelec.fr [193.48.224.205]) by esemetz.metz.supelec.fr (8.11.6/8.9.3) with ESMTP id j9AAvOI07148 for ; Mon, 10 Oct 2005 12:57:24 +0200 Received: from [193.48.225.2] (nou.rez-metz.supelec.fr [193.48.225.2]) by smtp.metz.supelec.fr (8.11.6/8.11.6) with ESMTP id j9AAplK23566 for ; Mon, 10 Oct 2005 12:51:48 +0200 Message-ID: <434A492B.9010206@altern.org> Date: Mon, 10 Oct 2005 12:57:47 +0200 From: Gregory Nou User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051009) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: umounting a usbkey causes reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 10:57:26 -0000 hi, when I made a umount -f on my usbkey, I experienced a reboot. I did this : # mount /dev/da0 /mnt unplugged the usbkey, add a file from another computer, replugged it # ls the new files did not appear # umount -f /dev/da0 instant reboot... greg@nou ~% uname -a FreeBSD hostname 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Oct 9 17:27:28 CEST 2005 root@hostname:/usr/obj/usr/src/sys/MYKERNEL i386 my dmesg concerning the usbkey : da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 11:34:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5623F16A41F for ; Mon, 10 Oct 2005 11:34:11 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83CB643D48 for ; Mon, 10 Oct 2005 11:34:10 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9ABY7V9002460; Mon, 10 Oct 2005 14:34:08 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9ABX31b003342; Mon, 10 Oct 2005 14:33:03 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9ABX2YI003341; Mon, 10 Oct 2005 14:33:02 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 10 Oct 2005 14:33:02 +0300 From: Giorgos Keramidas To: Gregory Nou Message-ID: <20051010113302.GA3284@flame.pc> References: <434A492B.9010206@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434A492B.9010206@altern.org> Cc: freebsd-current@freebsd.org Subject: Re: umounting a usbkey causes reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 11:34:11 -0000 On 2005-10-10 12:57, Gregory Nou wrote: > hi, > > when I made a umount -f on my usbkey, I experienced a reboot. > > I did this : > # mount /dev/da0 /mnt > unplugged the usbkey, add a file from another computer, replugged it You have to unmount the file system before unplugging the USB device. > # ls > the new files did not appear > # umount -f /dev/da0 > instant reboot... This is a known problem. Unmount the USB device before unplugging it and all should be fine. From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 13:29:09 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17F6916A41F; Mon, 10 Oct 2005 13:29:09 +0000 (GMT) (envelope-from doug@cnd.dundas.on.ca) Received: from fep6.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB74343D49; Mon, 10 Oct 2005 13:29:06 +0000 (GMT) (envelope-from doug@cnd.dundas.on.ca) Received: from srv.cnd.dundas.on.ca (d141-68-27.home.cgocable.net [24.141.68.27]) by fep6.cogeco.net (Postfix) with ESMTP id 7F928F7E; Mon, 10 Oct 2005 09:29:05 -0400 (EDT) Received: from monk.cnd.dundas.on.ca (monk.cnd.dundas.on.ca [10.87.0.20]) by srv.cnd.dundas.on.ca (8.13.1/8.13.1) with ESMTP id j9ADT5we075916; Mon, 10 Oct 2005 09:29:05 -0400 (EDT) (envelope-from doug@cnd.dundas.on.ca) Received: from monk.cnd.dundas.on.ca (localhost [127.0.0.1]) by monk.cnd.dundas.on.ca (8.13.4/8.13.4) with ESMTP id j9ADT5i2011959; Mon, 10 Oct 2005 09:29:05 -0400 (EDT) (envelope-from doug@monk.cnd.dundas.on.ca) Message-Id: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> To: freebsd-current@freebsd.org In-reply-to: Your message of "Sun, 09 Oct 2005 01:30:01 +0900." <200510081630.j98GU1Sf021682@sakura.ninth-nine.com> From: "Douglas Berry" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Oct 2005 09:29:05 -0400 Sender: doug@cnd.dundas.on.ca Cc: Norikatsu Shigemura Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 13:29:09 -0000 On Sun, 09 Oct 2005 01:30:01 +0900, Norikatsu Shigemura wrote: [...] > I am using following if_wi and WEP. > wi0: mem 0xe0500000-0xe0500fff irq 5 at device 3.0 on pci2 > wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) > wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.3) > wi0: Ethernet address: 00:d0:59:44:a7:4d > > [...]wi0: timeout in wi_seek to fc00/0 [...] I used to see this a lot on an IBM T23 until I found this firmware (thanks to Jiri Mikulas!) http://bsd.mikulas.com/wifi/Fw_1.7.4.tgz wi0: mem 0xec000000-0xec000fff irq 7 at device 2.0 on pci2 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.1), Station (1.7.4) cheers, doug From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 14:26:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7C2916A41F; Mon, 10 Oct 2005 14:26:26 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F1A43D45; Mon, 10 Oct 2005 14:26:23 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.99.16] (host152-63.pool870.interbusiness.it [87.0.63.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 97CAC5739; Mon, 10 Oct 2005 16:29:36 +0200 (CEST) Message-ID: <434A7A08.5050501@freesbie.org> Date: Mon, 10 Oct 2005 16:26:16 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: Douglas Berry References: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> In-Reply-To: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> X-Enigmail-Version: 0.92.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig651799EE4EEBA09E33C03644" Cc: freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 14:26:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig651799EE4EEBA09E33C03644 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Douglas Berry ha scritto: > On Sun, 09 Oct 2005 01:30:01 +0900, Norikatsu Shigemura wrote: > [...] > >> I am using following if_wi and WEP. >>wi0: mem 0xe0500000-0xe0500fff irq 5 at device 3.0 on pci2 >>wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) >>wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.3) >>wi0: Ethernet address: 00:d0:59:44:a7:4d >> >>[...]wi0: timeout in wi_seek to fc00/0 [...] > > > I used to see this a lot on an IBM T23 until I found > this firmware (thanks to Jiri Mikulas!) > > http://bsd.mikulas.com/wifi/Fw_1.7.4.tgz Is there a way to flash it from freebsd? -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enig651799EE4EEBA09E33C03644 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.1 (Darwin) iD8DBQFDSnoKymi72IiShysRAidGAKCHNP3rw2jvCP4JNkHjE7FgGGOAJACgrrBh U4ocujXKI1H2YAa/v6w5hNk= =b0RN -----END PGP SIGNATURE----- --------------enig651799EE4EEBA09E33C03644-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 14:59:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24A2316A41F for ; Mon, 10 Oct 2005 14:59:47 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id D91D543D49 for ; Mon, 10 Oct 2005 14:59:46 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from localhost (ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j9AExj3t097740; Mon, 10 Oct 2005 07:59:46 -0700 (PDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Mon, 10 Oct 2005 10:59:03 -0400 User-Agent: KMail/1.8.2 References: <200510061139.37825.lists@jnielsen.net> <200510071557.50553.lists@jnielsen.net> <20051008172037.O56323@ury.york.ac.uk> In-Reply-To: <20051008172037.O56323@ury.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510101059.03558.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: Re: Broadcom BCM5751 not attaching on IBM ThinkCentre A51 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 14:59:47 -0000 On Saturday 08 October 2005 14:14, Gavin Atkinson wrote: > On Fri, 7 Oct 2005, John Nielsen wrote: > > On Friday 07 October 2005 12:58, Gavin Atkinson wrote: > >> Can you post the output of pciconf -l please? > > > > Attached, along with dmesg output and kernel config file (basically a > > stripped-down GENERIC). > > Can you try applying the attached patch, and the patch in > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79139 and if the latter > patch makes no difference, show the output of the extra line? I built a new kernel on -CURRENT with these two patches. No change. The only real diff in the dmesg output was your extra line: bge0: register value ffffffff No different output regarding the PCI bus. The ndis driver still does not work as well. > You could also try http://people.freebsd.org/~yongari/bge.patch.0908 - > but I don't believe it will help in this case. (it's actually to fix > endian issues on other platforms, but it does change the way the driver > talks to the chip subtly) I'll try this next (I'll try anything once :) ). JN From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 16:20:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4B3416A41F; Mon, 10 Oct 2005 16:20:06 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (ruprt.hosting4u.cz [82.208.25.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2869143D46; Mon, 10 Oct 2005 16:20:05 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 6A95F4E705; Mon, 10 Oct 2005 18:20:08 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14626-09; Mon, 10 Oct 2005 18:20:08 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 0C9674E704; Mon, 10 Oct 2005 18:20:08 +0200 (CEST) From: =?us-ascii?Q?Daniel_Dvorak?= To: "'Douglas Berry'" , Date: Mon, 10 Oct 2005 18:20:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcXNoDD4fft+PO6jSpOWkPGfZyFIWAAFYelQ Message-Id: <20051010162008.0C9674E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: 'Norikatsu Shigemura' Subject: RE: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2005 16:20:07 -0000 Hello Douglas, and what about this site http://www.red-bean.com/~proski/firmware/, there are many more version firmware of Intersil Prism 2.x,2.5 chipsets. 2 Dario Freni: I do not know about way to flash firmware under FreeBSD, of course with winupdate0.7.0.exe it works under Windows. I rocommend to flash primary and secondary firmware 1.1.1/1.8.0 together, always together, even primary you have had it. Dan > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Douglas Berry > Sent: Monday, October 10, 2005 3:29 PM > To: freebsd-current@freebsd.org > Cc: Norikatsu Shigemura > Subject: Re: dhclient with if_wi&wep > > On Sun, 09 Oct 2005 01:30:01 +0900, Norikatsu Shigemura wrote: > [...] > > I am using following if_wi and WEP. > > wi0: mem 0xe0500000-0xe0500fff irq 5 at > device 3.0 > > on pci2 > > wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) > > wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.3) > > wi0: Ethernet address: 00:d0:59:44:a7:4d > > > > [...]wi0: timeout in wi_seek to fc00/0 [...] > > I used to see this a lot on an IBM T23 until I found this > firmware (thanks to Jiri Mikulas!) > > http://bsd.mikulas.com/wifi/Fw_1.7.4.tgz > > wi0: mem 0xec000000-0xec000fff irq 7 at > device 2.0 on pci2 > wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) > wi0: Intersil Firmware: Primary (1.1.1), Station (1.7.4) > > cheers, > doug > > _______________________________________________ > 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" _____ avast! Antivirus : Odchozi zprava cista. Virova databaze (VPS): 0540-8, 07.10.2005 Testovano: 10.10.2005 18:20:02 avast! - copyright (c) 1988-2005 ALWIL Software. From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 18:59:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 562A016A41F for ; Mon, 10 Oct 2005 18:59:48 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC61D43D45 for ; Mon, 10 Oct 2005 18:59:46 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5DBE6.dip.t-dialin.net [84.165.219.230]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j9AIh9gE070725 for ; Mon, 10 Oct 2005 20:43:10 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j9AIxWET089758 for ; Mon, 10 Oct 2005 20:59:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Oct 2005 20:59:31 +0200 From: Alexander Leidinger To: freebsd-current@freebsd.org Message-ID: <20051010205931.1cfc73f6@Magellan.Leidinger.net> In-Reply-To: <20051010162008.0C9674E704@pipa.profix.cz> References: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> <20051010162008.0C9674E704@pipa.profix.cz> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 18:59:48 -0000 On Mon, 10 Oct 2005 18:20:02 +0200 Daniel Dvorak wrote: > Hello Douglas, > > and what about this site http://www.red-bean.com/~proski/firmware/, there > are many more version firmware of Intersil Prism 2.x,2.5 chipsets. And since not every card accepts the most recent version (I have 2 of them), those other versions are needed... So if the flash utility tells you that the firmware isn't suitable to the card, try an older firmware version. Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 19:18:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA79616A41F; Mon, 10 Oct 2005 19:18:53 +0000 (GMT) (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 6D91B43D45; Mon, 10 Oct 2005 19:18:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9AJIqYA013505; Mon, 10 Oct 2005 15:18:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9AJIq9O058640; Mon, 10 Oct 2005 15:18:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 207197302F; Mon, 10 Oct 2005 15:18:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051010191852.207197302F@freebsd-current.sentex.ca> Date: Mon, 10 Oct 2005 15:18:52 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Mon, 10 Oct 2005 19:18:54 -0000 TB --- 2005-10-10 17:55:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-10 17:55:36 - starting HEAD tinderbox run for i386/i386 TB --- 2005-10-10 17:55:36 - cleaning the object tree TB --- 2005-10-10 17:56:00 - checking out the source tree TB --- 2005-10-10 17:56:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-10-10 17:56:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-10 18:02:28 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-10 18:02:28 - cd /src TB --- 2005-10-10 18:02:28 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-10 19:06:22 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-10 19:06:22 - cd /src TB --- 2005-10-10 19:06:22 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Oct 10 19:06:22 UTC 2005 >>> 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 [...] touch export_syms awk -f /src/sys/modules/if_gre/../../conf/kmod_syms.awk if_gre.kld export_syms | xargs -J% objcopy % if_gre.kld ld -Bshareable -d -warn-common -o if_gre.ko.debug if_gre.kld objcopy --strip-debug if_gre.ko.debug if_gre.ko ===> if_ndis (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/obj/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_detach': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:920: error: structure has no member named `ndis_mtx' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-10 19:18:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-10 19:18:51 - ERROR: failed to build generic kernel TB --- 2005-10-10 19:18:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 19:45:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EAD516A41F for ; Mon, 10 Oct 2005 19:45:44 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4FEE43D45 for ; Mon, 10 Oct 2005 19:45:43 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 79733 invoked by uid 89); 10 Oct 2005 19:45:21 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 10 Oct 2005 19:45:21 -0000 Date: Mon, 10 Oct 2005 21:45:47 +0200 From: Oliver Lehmann To: current@freebsd.org Message-Id: <20051010214547.4d12bedf.lehmann@ans-netz.de> X-Mailer: Sylpheed version 2.0.2 (GTK+ 2.6.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: rbootd issue with 6.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: Mon, 10 Oct 2005 19:45:44 -0000 Hi, could please someone take a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/85049 rbootd on 6.X is useless right now (at least in my config) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 20:29:42 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00AB816A41F; Mon, 10 Oct 2005 20:29:42 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FC0D43D45; Mon, 10 Oct 2005 20:29:41 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9AKT3Wj013537; Mon, 10 Oct 2005 13:29:03 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9AKT0C2013534; Mon, 10 Oct 2005 13:29:00 -0700 Date: Mon, 10 Oct 2005 13:29:00 -0700 From: Brooks Davis To: Andrew Thompson , Yar Tikhiy , Brooks Davis , Pawel Jakub Dawidek , FreeBSD Current Message-ID: <20051010202900.GA24213@odin.ac.hmc.edu> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20051010022208.GA97249@heff.fud.org.nz> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 20:29:42 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: > > On Thu, Oct 06, 2005 at 10:09:50AM +1300, Andrew Thompson wrote: > > > On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: > > > > On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: > > > > > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: > > > > > +> Hi, > > > > > +>=20 > > > > > +> I have found a repeatable panic with network device cloning, u= nfortunatly I am > > > > > +> unable to dump on this box. This is sparc64 with a 2 day old c= urrent. > > > > >=20 > > > > > The order is wrong in vlan_modevent(). > > > > >=20 > > > > > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() = should not > > > > > be called after that. > > > > >=20 > > > > > This patch should fix the problem: > > > > >=20 > > > > > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch > > > >=20 > > > > Yes. This does introduce a race in that a new interface could > > > > be created between the vlan_clone_destroy loop and the call to > > > > if_clone_detach. > > >=20 > > > I dont think this is the problem. IF_CLONE_REMREF(ifc) is freeing > > > ifc->ifc_units in if_clone_detach(). It look like the ref counting is= nt > > > working quite right. > >=20 > > FWIW, I tried to look at the $subject problem since I had had it > > before, but just got a different panic: > >=20 > > Memory modified after free 0xc140b000(4092) val=3Ddeadc0dc @ 0x= c140b000 > > panic: Most recently used by clone > >=20 > > The clone code seems to have decremented something (refcount?) twice > > after freeing the memory chunk. >=20 > I have been testing this patch and I think it fixes all the problems > discussed. >=20 > It changes refcounting to count the number of cloned interfaces so > ifc_units is only freed when its safe. A new function has been added to > decrement this when a simple cloner module is unloaded. The cloner is > still detached first to prevent the race. >=20 > In most cases the change is as simple as: > while ((sc =3D LIST_FIRST(&gre_softc_list)) !=3D NULL) { > LIST_REMOVE(sc, sc_list); > mtx_unlock(&gre_mtx); > + ifc_simple_free(&gre_cloner, GRE2IFP(sc)); > gre_destroy(sc); > mtx_lock(&gre_mtx); > } I don't see any reason why you can't just replace the specific destroy calls with calls to ifc_simple_destroy(). That would avoid expanding the API. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDSs8KXY6L6fI4GtQRAmjtAKDOxlkwTTaexr6+bn9eB8YOGNf73QCgpdFd 7mBpxyzCuPlmPVYbpVtT2e0= =rBSt -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 20:35:29 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A118116A41F; Mon, 10 Oct 2005 20:35:29 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D5543D49; Mon, 10 Oct 2005 20:35:28 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C90961CCDD; Tue, 11 Oct 2005 09:35:26 +1300 (NZDT) Date: Tue, 11 Oct 2005 09:35:26 +1300 From: Andrew Thompson To: Brooks Davis Message-ID: <20051010203526.GA1229@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Brooks Davis , Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051010202900.GA24213@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 20:35:29 -0000 On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: > On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > > On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: > > > On Thu, Oct 06, 2005 at 10:09:50AM +1300, Andrew Thompson wrote: > > > > > > FWIW, I tried to look at the $subject problem since I had had it > > > before, but just got a different panic: > > > > > > Memory modified after free 0xc140b000(4092) val=deadc0dc @ 0xc140b000 > > > panic: Most recently used by clone > > > > > > The clone code seems to have decremented something (refcount?) twice > > > after freeing the memory chunk. > > > > I have been testing this patch and I think it fixes all the problems > > discussed. > > > > It changes refcounting to count the number of cloned interfaces so > > ifc_units is only freed when its safe. A new function has been added to > > decrement this when a simple cloner module is unloaded. The cloner is > > still detached first to prevent the race. > > > > In most cases the change is as simple as: > > while ((sc = LIST_FIRST(&gre_softc_list)) != NULL) { > > LIST_REMOVE(sc, sc_list); > > mtx_unlock(&gre_mtx); > > + ifc_simple_free(&gre_cloner, GRE2IFP(sc)); > > gre_destroy(sc); > > mtx_lock(&gre_mtx); > > } > > I don't see any reason why you can't just replace the specific destroy > calls with calls to ifc_simple_destroy(). That would avoid expanding > the API. I did experiment with that. On some interfaces it would cause the global mutex to be recursed, but that can be fixed. I'll have another go. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 20:39:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C3C116A41F; Mon, 10 Oct 2005 20:39:00 +0000 (GMT) (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 0007643D45; Mon, 10 Oct 2005 20:38:59 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9AKcwR1018450; Mon, 10 Oct 2005 16:38:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9AKcwDL059734; Mon, 10 Oct 2005 16:38:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AEF517302F; Mon, 10 Oct 2005 16:38:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051010203858.AEF517302F@freebsd-current.sentex.ca> Date: Mon, 10 Oct 2005 16:38:58 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Mon, 10 Oct 2005 20:39:00 -0000 TB --- 2005-10-10 19:18:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-10 19:18:52 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-10-10 19:18:52 - cleaning the object tree TB --- 2005-10-10 19:19:21 - checking out the source tree TB --- 2005-10-10 19:19:21 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-10-10 19:19:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-10 19:25:45 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-10 19:25:45 - cd /src TB --- 2005-10-10 19:25:45 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-10 20:29:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-10 20:29:25 - cd /src TB --- 2005-10-10 20:29:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Oct 10 20:29:26 UTC 2005 >>> 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 [...] touch export_syms awk -f /src/sys/modules/if_gre/../../conf/kmod_syms.awk if_gre.kld export_syms | xargs -J% objcopy % if_gre.kld ld -Bshareable -d -warn-common -o if_gre.ko.debug if_gre.kld objcopy --strip-debug if_gre.ko.debug if_gre.ko ===> if_ndis (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/obj/pc98/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_detach': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:920: error: structure has no member named `ndis_mtx' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-10 20:38:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-10 20:38:58 - ERROR: failed to build generic kernel TB --- 2005-10-10 20:38:58 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 21:28:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 128A316A41F for ; Mon, 10 Oct 2005 21:28:25 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id D529943D45 for ; Mon, 10 Oct 2005 21:28:24 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EP5C4-000HSn-Cz for freebsd-current@freebsd.org; Mon, 10 Oct 2005 21:28:24 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EP5C3-0001Ll-37 for freebsd-current@freebsd.org; Mon, 10 Oct 2005 11:28:23 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17226.56566.685014.158716@roam.psg.com> Date: Mon, 10 Oct 2005 11:28:22 -1000 To: FreeBSD Current Subject: libutil.so.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: Mon, 10 Oct 2005 21:28:25 -0000 7.0-current completely rebuilt # Mail -s test randy < /dev/null Null message body; hope that's ok /libexec/ld-elf.so.1: Shared object "libutil.so.4" not found, required by "send-mail" and there seems to be no libutil.so.N in /usr/lib on any of my 7.0 systems. clue bat, please randy From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 21:45:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65C3716A41F for ; Mon, 10 Oct 2005 21:45:22 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 006DE43D45 for ; Mon, 10 Oct 2005 21:45:21 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9ALjLbb026925; Mon, 10 Oct 2005 14:45:21 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9ALjL1Z026924; Mon, 10 Oct 2005 14:45:21 -0700 Date: Mon, 10 Oct 2005 14:45:21 -0700 From: Brooks Davis To: Randy Bush Message-ID: <20051010214521.GC24213@odin.ac.hmc.edu> References: <17226.56566.685014.158716@roam.psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <17226.56566.685014.158716@roam.psg.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: FreeBSD Current Subject: Re: libutil.so.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: Mon, 10 Oct 2005 21:45:22 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2005 at 11:28:22AM -1000, Randy Bush wrote: > 7.0-current completely rebuilt >=20 > # Mail -s test randy < /dev/null > Null message body; hope that's ok > /libexec/ld-elf.so.1: Shared object "libutil.so.4" not found, required by= "send-mail" >=20 > and there seems to be no libutil.so.N in /usr/lib on any of my > 7.0 systems. On a 7-CURRENT system: # ls /lib/libutil.so.* /lib/libutil.so.4 /lib/libutil.so.5 You need the compat5x package or to rebuild more code. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDSuDwXY6L6fI4GtQRAmLJAKDEae2WbPyLCjOYgc7gK6lCtgnFSwCdFRrg bwiy4pwIhyBRsLEWRv3llJs= =IIEP -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:45:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 381E016A41F for ; Mon, 10 Oct 2005 22:45:31 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 033FE43D49 for ; Mon, 10 Oct 2005 22:45:30 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EP6Oe-000JY8-EV; Mon, 10 Oct 2005 22:45:28 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EP6Od-0001Qp-3K; Mon, 10 Oct 2005 12:45:27 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17226.61190.583079.947841@roam.psg.com> Date: Mon, 10 Oct 2005 12:45:26 -1000 To: Brooks Davis References: <17226.56566.685014.158716@roam.psg.com> <20051010214521.GC24213@odin.ac.hmc.edu> Cc: FreeBSD Current Subject: Re: libutil.so.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: Mon, 10 Oct 2005 22:45:31 -0000 > # ls /lib/libutil.so.* > /lib/libutil.so.4 /lib/libutil.so.5 > You need the compat5x package or to rebuild more code. i had done make world, kernel, and portupgrade -fav so i hacked libmap.conf randy From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 00:15:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F147516A41F for ; Tue, 11 Oct 2005 00:15:45 +0000 (GMT) (envelope-from lihong.chen@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A72943D46 for ; Tue, 11 Oct 2005 00:15:45 +0000 (GMT) (envelope-from lihong.chen@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so227487nzk for ; Mon, 10 Oct 2005 17:15:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=MGWGV1VtfL0c4uUOkvS+UMi7etaK8cLW1mlGp+5CdjYmjdiQrJJWTiKBVZmM2PT3Ubab16679phzCAhhyDPmXez9pL3vD1gdm96h9toAZwX48cJHMbCwpgy0QI5S9bmc3wi2uXWlJgRTlRyr05CImlbQ5HlS49W9g6k1oUznuOs= Received: by 10.36.221.76 with SMTP id t76mr3587044nzg; Mon, 10 Oct 2005 17:15:44 -0700 (PDT) Received: from ?10.8.0.112? ( [61.221.58.28]) by mx.gmail.com with ESMTP id 7sm2981395nzo.2005.10.10.17.15.43; Mon, 10 Oct 2005 17:15:44 -0700 (PDT) From: "Chen, Lihong" To: freebsd-current@freebsd.org Content-Type: text/plain Date: Tue, 11 Oct 2005 08:15:32 +0800 Message-Id: <1128989732.865.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Can not get battery information on RELENG_6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 00:15:46 -0000 Hi! All, I can not retrieve the battery information for my laptop - Acer TravelMate 4102WLMi. How can I fix it? I've got these error messages: ACPI-0438: *** Error: Looking up [Z00C] in namespace, AE_NOT_FOUND SearchNode 0xc22d08a0 StartNode 0xc22d08a0 ReturnNode 0 ACPI-0438: *** Error: Looking up [Z00C] in namespace, AE_NOT_FOUND SearchNode 0xc22d08a0 StartNode 0xc22d08a0 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT1._BST] (Node 0xc22d07a0), AE_NOT_FOUND /Lihong From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 00:38:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 323F316A41F for ; Tue, 11 Oct 2005 00:38:47 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C18D743D45 for ; Tue, 11 Oct 2005 00:38:46 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id j9B0ceOZ069541; Mon, 10 Oct 2005 17:38:43 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <434B098E.7070506@freebsd.org> Date: Mon, 10 Oct 2005 17:38:38 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Maste References: <20050926195807.GD95971@sandvine.com> <17208.30606.117170.36398@khavrinen.csail.mit.edu> <20050927001650.GA9994@sandvine.com> <20050927180021.GB9994@sandvine.com> <433A2882.4030003@freebsd.org> <433A2D6E.7020205@freebsd.org> <20050928152112.GC9994@sandvine.com> <20050928214309.GA31848@xor.obsecurity.org> <20050928223927.GA11161@sandvine.com> In-Reply-To: <20050928223927.GA11161@sandvine.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Wollman , freebsd-current@freebsd.org, Kris Kennaway Subject: Re: Bsdtar and archive torture tests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 00:38:47 -0000 Ed, Have you done anything with this? I'm very interested in getting some real regression tests imported and this seems like a great place to start. Ideally, the test would be run several times: * archive with gnutar/extract with bsdtar * archive with cpio/extract with bsdtar * archive with bsdtar/extract with cpio * archive with bsdtar/extract with gnutar * etc... Unfortunately, the exact tests here will vary slightly: * gnutar can archive sparse files that bsdtar should correctly extract, but neither bsdtar nor cpio can archive sparse files * bsdtar can archive (and restore) very large directories and very deep directory trees. My testing of this has been somewhat hampered by limits in the rest of the system: /bin/sh won't cd to a dir whose path is longer than about 8k, rm/find/ls/du are all limited to 32k path lengths, etc. I suspect the ideal test arrangement would provide switches to the comparison routine to omit/ignore certain files. Then you could build a single "original", make several copies using the above combinations, then compare while overlooking any unsupported attributes. Thoughts? Tim Ed Maste wrote: > On Wed, Sep 28, 2005 at 05:43:09PM -0400, Kris Kennaway wrote: > > >>Can we import the tar stress tests as a regression test? i.e. what is >>the license on them? > > > Right now the only mention of any copyright info is > # Copyright 2003, Elizabeth D. Zwicky > in one of the files. > > The author states > The test programs were written in a spirit of experimentation, > rather than with the intention of producing software for other > people to use. I strongly encourage people who are interested > in testing backup and archive programs to produce their own > tests that cover the cases they are most interested in. However, > if you insist on using my programs, or just want to snicker at > my programming, they are available from > http://www.greatcircle.com/~zwicky > > Despite that, I think they've already demonstrated their value. > > The stress test consists of two perl programs. One creates a test tree, > and the other compares file metadata between the original tree and a > restored tree. An automated method for running the test and comparing > the results is not included (but would be easy to write, of course). > > I'll contact the author to ask about the license. > > -- > Ed Maste, Sandvine Incorporated > _______________________________________________ > 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 Tue Oct 11 02:11:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D32016A41F for ; Tue, 11 Oct 2005 02:11:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B483943D45 for ; Tue, 11 Oct 2005 02:11:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9B2B1Pb029260; Mon, 10 Oct 2005 20:11:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 10 Oct 2005 20:12:05 -0600 (MDT) Message-Id: <20051010.201205.28786661.imp@bsdimp.com> To: Alexander@Leidinger.net From: "M. Warner Losh" In-Reply-To: <20051010205931.1cfc73f6@Magellan.Leidinger.net> References: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> <20051010162008.0C9674E704@pipa.profix.cz> <20051010205931.1cfc73f6@Magellan.Leidinger.net> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 10 Oct 2005 20:11:07 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 02:11:41 -0000 In message: <20051010205931.1cfc73f6@Magellan.Leidinger.net> Alexander Leidinger writes: : On Mon, 10 Oct 2005 18:20:02 +0200 : Daniel Dvorak wrote: : : > Hello Douglas, : > : > and what about this site http://www.red-bean.com/~proski/firmware/, there : > are many more version firmware of Intersil Prism 2.x,2.5 chipsets. : : And since not every card accepts the most recent version (I have 2 of : them), those other versions are needed... : : So if the flash utility tells you that the firmware isn't suitable to : the card, try an older firmware version. The 'suitable' bit is due to the underlying model, not the age of the card, per se. Each card type has its own firmware... Warner From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 03:45:12 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C17816A41F; Tue, 11 Oct 2005 03:45:12 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0396843D60; Tue, 11 Oct 2005 03:45:09 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with ESMTP id j9B3in3m047081; Tue, 11 Oct 2005 12:44:50 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Tue, 11 Oct 2005 12:44:49 +0900 From: Norikatsu Shigemura To: Message-Id: <20051011124449.88bf9a29.nork@FreeBSD.org> In-Reply-To: <20051010162008.0C9674E704@pipa.profix.cz> References: <200510101329.j9ADT5i2011959@monk.cnd.dundas.on.ca> <20051010162008.0C9674E704@pipa.profix.cz> X-Mailer: Sylpheed version 2.1.3 (GTK+ 2.6.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sakura.ninth-nine.com [219.127.74.121]); Tue, 11 Oct 2005 12:44:51 +0900 (JST) Cc: dandee@hellteam.net, bitnix@bitnix.ca, freebsd-current@FreeBSD.org, nork@FreeBSD.org Subject: Re: dhclient with if_wi&wep X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 03:45:12 -0000 On Mon, 10 Oct 2005 18:20:02 +0200 Daniel Dvorak wrote: > and what about this site http://www.red-bean.com/~proski/firmware/, there > are many more version firmware of Intersil Prism 2.x,2.5 chipsets. > 2 Dario Freni: > I do not know about way to flash firmware under FreeBSD, of course with > winupdate0.7.0.exe it works under Windows. > I rocommend to flash primary and secondary firmware 1.1.1/1.8.0 together, > always together, even primary you have had it. Humm... My if_wi, Station:1.4.3 has any problem. According to http://linux.junsun.net/intersil-prism/ There is a flash firmware update on Linux. I'll research it. Thank you! From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 03:49:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9947616A41F for ; Tue, 11 Oct 2005 03:49:08 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD13543D46 for ; Tue, 11 Oct 2005 03:49:07 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so254417nzk for ; Mon, 10 Oct 2005 20:49:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=oIB2CffTpcdzuV64IFi1GJuYKqb3CLgj4+aCGCVqc/2rVvQ8OLY9abuvdfuCcha7FBlvLkZvvawhH6A9Qrd8KhE4QYbaChbxswhdJapQ8GhoEL2xBNuKyqIOAEY/TkGBD/+aWBgB/g/+nFQMDtEAbD7UVvkJu9uV+AemrDNWLKY= Received: by 10.36.115.10 with SMTP id n10mr3637853nzc; Mon, 10 Oct 2005 20:49:07 -0700 (PDT) Received: from michelle.rndsoft.co.kr ( [211.32.202.217]) by mx.gmail.com with ESMTP id 15sm916638nzo.2005.10.10.20.49.03; Mon, 10 Oct 2005 20:49:07 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j9B3mM74005903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 12:48:22 +0900 (KST) (envelope-from yongari@gmail.com) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j9B3mHgI005902; Tue, 11 Oct 2005 12:48:17 +0900 (KST) (envelope-from yongari@gmail.com) Date: Tue, 11 Oct 2005 12:48:17 +0900 From: Pyun YongHyeon To: John Nielsen Message-ID: <20051011034817.GA5207@rndsoft.co.kr> References: <200510061139.37825.lists@jnielsen.net> <200510071557.50553.lists@jnielsen.net> <20051008172037.O56323@ury.york.ac.uk> <200510101059.03558.lists@jnielsen.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <200510101059.03558.lists@jnielsen.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Broadcom BCM5751 not attaching on IBM ThinkCentre A51 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: Tue, 11 Oct 2005 03:49:08 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 10, 2005 at 10:59:03AM -0400, John Nielsen wrote: > On Saturday 08 October 2005 14:14, Gavin Atkinson wrote: > > On Fri, 7 Oct 2005, John Nielsen wrote: > > > On Friday 07 October 2005 12:58, Gavin Atkinson wrote: > > >> Can you post the output of pciconf -l please? > > > > > > Attached, along with dmesg output and kernel config file (basically a > > > stripped-down GENERIC). > > > > Can you try applying the attached patch, and the patch in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79139 and if the latter > > patch makes no difference, show the output of the extra line? > > I built a new kernel on -CURRENT with these two patches. No change. The > only real diff in the dmesg output was your extra line: > > bge0: register value ffffffff > > No different output regarding the PCI bus. > > The ndis driver still does not work as well. > Due to lack of data sheet from Broadcom it seems that it's hard to identify what caused this. Since the error message comes from bge_chipinit(), I guess there is a possible bug(reading/writing registers while chip reset is in progress) in bge_reset()/bge_chipinit(). -- Regards, Pyun YongHyeon --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.pcistate.patch" --- sys/dev/bge/if_bge.c.orig Mon Oct 3 13:27:44 2005 +++ sys/dev/bge/if_bge.c Tue Oct 11 12:56:21 2005 @@ -2583,7 +2583,7 @@ struct bge_softc *sc; { device_t dev; - u_int32_t cachesize, command, pcistate, reset; + u_int32_t cachesize, command, pcistate, new_pcistate, reset; int i, val = 0; dev = sc->bge_dev; @@ -2673,10 +2673,16 @@ * results. */ for (i = 0; i < BGE_TIMEOUT; i++) { - if (pci_read_config(dev, BGE_PCI_PCISTATE, 4) == pcistate) + new_pcistate = pci_read_config(dev, BGE_PCI_PCISTATE, 4); + if ((new_pcistate & ~BGE_PCISTATE_RESERVED) == + (pcistate & ~BGE_PCISTATE_RESERVED)) break; DELAY(10); } + + if ((new_pcistate & ~BGE_PCISTATE_RESERVED) != + (pcistate & ~BGE_PCISTATE_RESERVED)) + printf("bge%d: pcistate failed to revert\n", sc->bge_unit); /* Fix up byte swapping */ CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_MODECTL_BYTESWAP_NONFRAME| --- sys/dev/bge/if_bgereg.h.orig Mon Jun 13 09:24:40 2005 +++ sys/dev/bge/if_bgereg.h Tue Oct 11 12:55:35 2005 @@ -306,6 +306,7 @@ #define BGE_PCISTATE_EXPROM_RETRY 0x00000040 #define BGE_PCISTATE_FLATVIEW_MODE 0x00000100 #define BGE_PCISTATE_PCI_TGT_RETRY_MAX 0x00000E00 +#define BGE_PCISTATE_RESERVED ((1 << 12) + (1 <<7)) /* * PCI Clock Control register -- note, this register is read only --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 06:41:33 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7259916A41F; Tue, 11 Oct 2005 06:41:33 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3CE643D49; Tue, 11 Oct 2005 06:41:31 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BF43E50BDE; Tue, 11 Oct 2005 08:41:29 +0200 (CEST) Received: from localhost (dla186.neoplus.adsl.tpnet.pl [83.24.30.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 718E4509F1; Tue, 11 Oct 2005 08:41:23 +0200 (CEST) Date: Tue, 11 Oct 2005 08:41:16 +0200 From: Pawel Jakub Dawidek To: Brooks Davis Message-ID: <20051011064014.GA76710@garage.freebsd.pl> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <20051005205515.GA30350@odin.ac.hmc.edu> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Brooks Davis , FreeBSD Current , Andrew Thompson Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 06:41:33 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: +> On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: +> > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: +> > +> Hi, +> > +>=20 +> > +> I have found a repeatable panic with network device cloning, unfort= unatly I am +> > +> unable to dump on this box. This is sparc64 with a 2 day old curren= t. +> >=20 +> > The order is wrong in vlan_modevent(). +> >=20 +> > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() shoul= d not +> > be called after that. +> >=20 +> > This patch should fix the problem: +> >=20 +> > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch +>=20 +> Yes. This does introduce a race in that a new interface could +> be created between the vlan_clone_destroy loop and the call to +> if_clone_detach. It's going to be hard to trigger, but it probably +> should be fixed. Since cloning isn't performance critical, I think +> adding a dead flag to the clone structure and failing all attempts once +> the flag is set. I think it is a low-risk patch and the race isn't really critical. What do you guys think about going with this fix for 6.0? I'm all for better fix (the one thompsa@ is working on) going to HEAD and 6.1, but better fix - higher risk. So what's your opinion? Or maybe we will be able to create low-risk complete fix? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDS16MForvXbEpPzQRAr+zAJ981doxmwrcbTehCgRemxn++v6U2wCbBYHs mewMhQgDm2FMoqCBK+jAvxU= =AED0 -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 06:48:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56D8116A41F for ; Tue, 11 Oct 2005 06:48:05 +0000 (GMT) (envelope-from freebsd@contexthosting.net) Received: from mail.contexthosting.net (inception.centerfuse.net [209.120.245.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 862A043D49 for ; Tue, 11 Oct 2005 06:48:04 +0000 (GMT) (envelope-from freebsd@contexthosting.net) Received: (qmail 96649 invoked by uid 89); 11 Oct 2005 06:48:03 -0000 Received: by simscan 1.0.7 ppid: 96645, pid: 96647, t: 0.0365s scanners:none Received: from unknown (HELO ?192.168.1.100?) (jim@contexthosting.net@68.80.252.242) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Oct 2005 06:48:03 -0000 Message-ID: <434B601F.40007@contexthosting.net> Date: Tue, 11 Oct 2005 02:47:59 -0400 From: Jim Keller User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 06:48:05 -0000 Hello, I'm trying to determine which version of FreeBSD to install on a new server I have coming in, since I know that the 5 branch is to become an errata branch sooner rather than later. The migration guide from 4.x to 5.x recommends a clean install of FreeBSD followed by data restoration, which makes sense considering the major changes in 5.x, especially to the filesystem. However, will this still hold true for going from 5.x to 6? I'd prefer to install 5.4 for now then run a buildworld later and bump it to 6, but will buildworld be a reasonable way of going from 5.4 to 6? Thanks -Jim Keller From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 06:51:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E47516A41F for ; Tue, 11 Oct 2005 06:51:50 +0000 (GMT) (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 8119143D53 for ; Tue, 11 Oct 2005 06:51:49 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9B6pbai048604; Tue, 11 Oct 2005 00:51:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434B6102.2050608@samsco.org> Date: Tue, 11 Oct 2005 00:51:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Keller References: <434B601F.40007@contexthosting.net> In-Reply-To: <434B601F.40007@contexthosting.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 06:51:50 -0000 Jim Keller wrote: > Hello, > I'm trying to determine which version of FreeBSD to install on a new > server I have coming in, since I know that the 5 branch is to become an > errata branch sooner rather than later. The migration guide from 4.x to > 5.x recommends a clean install of FreeBSD followed by data restoration, > which makes sense considering the major changes in 5.x, especially to > the filesystem. However, will this still hold true for going from 5.x to > 6? I'd prefer to install 5.4 for now then run a buildworld later and > bump it to 6, but will buildworld be a reasonable way of going from 5.4 > to 6? > > Thanks > > -Jim Keller Upgrading from 5.4 to 6.0 is very easy. I did it last weekend on my firewall+mailserver with just the normal upgrade procedures. The only gotcha that I can think of is the renamed serial ports. Scott From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 06:59:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC88C16A41F for ; Tue, 11 Oct 2005 06:59:13 +0000 (GMT) (envelope-from jura@networks.ru) Received: from networks.ru (orange.networks.ru [80.249.138.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id D81AD43D46 for ; Tue, 11 Oct 2005 06:59:12 +0000 (GMT) (envelope-from jura@networks.ru) Received: from [81.195.67.217] (HELO Jura) by networks.ru (CommuniGate Pro SMTP 4.3.8) with ESMTPS id 1999241 for freebsd-current@freebsd.org; Tue, 11 Oct 2005 10:59:10 +0400 Message-ID: <042601c5ce31$19a2b4a0$6504010a@Jura> From: "Yuriy N. Shkandybin" To: References: <434B601F.40007@contexthosting.net> <434B6102.2050608@samsco.org> Date: Tue, 11 Oct 2005 10:57:52 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: Re: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 06:59:13 -0000 Yes, but change synproxy state to keep state in pf config file, if you use it . Jura > Jim Keller wrote: >> Hello, >> I'm trying to determine which version of FreeBSD to install on a new >> server I have coming in, since I know that the 5 branch is to become an >> errata branch sooner rather than later. The migration guide from 4.x to >> 5.x recommends a clean install of FreeBSD followed by data restoration, >> which makes sense considering the major changes in 5.x, especially to >> the filesystem. However, will this still hold true for going from 5.x to >> 6? I'd prefer to install 5.4 for now then run a buildworld later and >> bump it to 6, but will buildworld be a reasonable way of going from 5.4 >> to 6? >> >> Thanks >> >> -Jim Keller > > Upgrading from 5.4 to 6.0 is very easy. I did it last weekend on my > firewall+mailserver with just the normal upgrade procedures. The only > gotcha that I can think of is the renamed serial ports. > > 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" > From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 07:09:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C8D716A41F for ; Tue, 11 Oct 2005 07:09:48 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1290543D46 for ; Tue, 11 Oct 2005 07:09:47 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id B30A23D984 for ; Tue, 11 Oct 2005 09:09:46 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9B796jT024503; Tue, 11 Oct 2005 09:09:10 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2005 09:08:56 +0200 User-Agent: KMail/1.8.2 References: <434B601F.40007@contexthosting.net> <434B6102.2050608@samsco.org> In-Reply-To: <434B6102.2050608@samsco.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510110908.58908.thierry@herbelot.com> Cc: Jim Keller Subject: Re: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 07:09:48 -0000 Le Tuesday 11 October 2005 08:51, Scott Long a écrit : > Upgrading from 5.4 to 6.0 is very easy. I did it last weekend on my > firewall+mailserver with just the normal upgrade procedures. The only > gotcha that I can think of is the renamed serial ports. > > Scott I had crashes with some KDE apps (akkregator or amarok, for example) after upgrading a 5.4 station via buildworld/buldkernel (+ portupgrade -fa), which disappeared after I installed a new 6.0 with a new set of packages. TfH PS : I installed the "new", clean 6.0 and associated packages within a jail running from the hybrid 5.4/6.0. I could install and setup the new OS and packages without interrupting work on the currently installed 5.4/6.0 hybrid. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 07:48:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F43316A41F for ; Tue, 11 Oct 2005 07:48:44 +0000 (GMT) (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 6EBA643D5E for ; Tue, 11 Oct 2005 07:48:42 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp241-172.lns2.adl2.internode.on.net [203.122.241.172]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9B7mWfI031601 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 Oct 2005 17:18:32 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org, thierry@herbelot.com Date: Tue, 11 Oct 2005 17:18:29 +0930 User-Agent: KMail/1.8.2 References: <434B601F.40007@contexthosting.net> <434B6102.2050608@samsco.org> <200510110908.58908.thierry@herbelot.com> In-Reply-To: <200510110908.58908.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4497595.uMAGhWDPJo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510111718.30882.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Jim Keller Subject: Re: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 07:48:44 -0000 --nextPart4497595.uMAGhWDPJo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 11 Oct 2005 16:38, Thierry Herbelot wrote: > I had crashes with some KDE apps (akkregator or amarok, for example) after > upgrading a 5.4 station via buildworld/buldkernel (+ portupgrade -fa), > which disappeared after I installed a new 6.0 with a new set of packages. Try putting.. libpthread.so.1 libpthread.so.1 in /etc/libmap.conf. It is likely that some programs are getting both versions linked at runtime= =20 which blows up on certain things.. =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 --nextPart4497595.uMAGhWDPJo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDS25O5ZPcIHs/zowRAodKAJ40iaGXvAduVoM6HIr8i0tL12T/8QCeM2xn 39q51MFHBQKPqrvXs1yVHGQ= =JIbr -----END PGP SIGNATURE----- --nextPart4497595.uMAGhWDPJo-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 08:17:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F0BC16A41F for ; Tue, 11 Oct 2005 08:17:42 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1274743D45 for ; Tue, 11 Oct 2005 08:17:42 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 350283DE17 for ; Tue, 11 Oct 2005 10:17:40 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9B8GtwB015911; Tue, 11 Oct 2005 10:16:59 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2005 10:16:46 +0200 User-Agent: KMail/1.8.2 References: <434B601F.40007@contexthosting.net> <200510110908.58908.thierry@herbelot.com> <200510111718.30882.doconnor@gsoft.com.au> In-Reply-To: <200510111718.30882.doconnor@gsoft.com.au> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510111016.48316.thierry@herbelot.com> Cc: Subject: Re: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 08:17:42 -0000 Le Tuesday 11 October 2005 09:48, Daniel O'Connor a écrit : > On Tue, 11 Oct 2005 16:38, Thierry Herbelot wrote: > > I had crashes with some KDE apps (akkregator or amarok, for example) > > after upgrading a 5.4 station via buildworld/buldkernel (+ portupgrade > > -fa), which disappeared after I installed a new 6.0 with a new set of > > packages. > > Try putting.. > libpthread.so.1 libpthread.so.1 > > in /etc/libmap.conf. > > It is likely that some programs are getting both versions linked at runtime > which blows up on certain things.. Hello, Thanks for the tip : I thought of this work-around, but I was not sure of the syntax and anyway I wanted to restart anew. The use of a jail to rebuild the system reduced the downtime to just a reboot, and I don't have to think about obsolete libraries in either the core system or the ports (and it only "costs" around 5Gigs of hard disk for a second, spare partition which is used when swapping OS's) TfH From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 08:32:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0039B16A41F for ; Tue, 11 Oct 2005 08:32:43 +0000 (GMT) (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 2A58843D49 for ; Tue, 11 Oct 2005 08:32:42 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp241-172.lns2.adl2.internode.on.net [203.122.241.172]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9B8WePb032092 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 Oct 2005 18:02:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: thierry@herbelot.com Date: Tue, 11 Oct 2005 18:02:15 +0930 User-Agent: KMail/1.8.2 References: <434B601F.40007@contexthosting.net> <200510111718.30882.doconnor@gsoft.com.au> <200510111016.48316.thierry@herbelot.com> In-Reply-To: <200510111016.48316.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1318582.PiXJP1dub3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510111802.32264.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: Upgrading from FreeBSD 5.4 to 6 - Make world or binary install? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 08:32:44 -0000 --nextPart1318582.PiXJP1dub3 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 11 Oct 2005 17:46, Thierry Herbelot wrote: > Thanks for the tip : I thought of this work-around, but I was not sure of > the syntax and anyway I wanted to restart anew. =46air enough, I needed it to actually rebuild stuff - I couldn't get Qt re= built=20 without it. Of course after all that effort the HD in my laptop died so I had to start= =20 fresh anyway :-/ > The use of a jail to rebuild the system reduced the downtime to just a > reboot, and I don't have to think about obsolete libraries in either the > core system or the ports (and it only "costs" around 5Gigs of hard disk f= or > a second, spare partition which is used when swapping OS's) Yeah, it's a neatidea :) =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 --nextPart1318582.PiXJP1dub3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDS3ig5ZPcIHs/zowRAi8YAJ42GIRzczdgumumUVVOld2w1VPe8gCdEPbH VYmP0leWiTQeZKDzS2bUJYQ= =qDFj -----END PGP SIGNATURE----- --nextPart1318582.PiXJP1dub3-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 09:43:29 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8A6016A41F; Tue, 11 Oct 2005 09:43:29 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D1543D46; Tue, 11 Oct 2005 09:43:29 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9B9h7vk044447; Tue, 11 Oct 2005 02:43:11 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510110943.j9B9h7vk044447@gw.catspoiler.org> Date: Tue, 11 Oct 2005 02:43:07 -0700 (PDT) From: Don Lewis To: kris@obsecurity.org In-Reply-To: <20051006053853.GA58630@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: mi+mx@aldan.algebra.com, re@FreeBSD.org, current@FreeBSD.org, openoffice@FreeBSD.org Subject: Re: 6.0 hangs (while building OOo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 09:43:30 -0000 On 6 Oct, Kris Kennaway wrote: > There is code in -current that saves stack traces when lockmgr locks > are acquired, when DEBUG_LOCKS is enabled - except it sometimes panics > while trying to save the trace because of a code bug. I remind jeffr > about this on a more-or-less daily basis, but he hasn't had time to > commit the fix he has yet. It still may be useful if this is easily > reproducible. I haven't yet tried to backport this to RELENG_6 and I've been having trouble reproducing it on my SMP machine. It looks like it has some sort of hardware problem that is causing it to lock up under load. >> This problem appears to be some sort of vnode lock leak. > > leaked lockmgr locks usually panic when the thread exits. There's a KASSERT to in userret() to catch this in the syscall return path, but that check is only enabled if the INVARIANTS kernel option is enabled, which is not currently true in RELENG_6, and Mikhail doesn't want to risk a panic on the machine in question, which is at a remote location. He did reproduce the problem again with DEBUG_LOCKS enabled and we got some more info. Here's the locked vnode in question: (kgdb) print *(struct vnode *)0xc2741ad4 $1 = {v_type = VDIR, v_tag = 0xc0729abe "ufs", v_op = 0xc076c5c0, v_data = 0xc2c03630, v_mount = 0xc1f72000, v_nmntvnodes = { tqe_next = 0xc2742c08, tqe_prev = 0xc2dfa880}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { le_next = 0xc2895604, le_prev = 0xc1f01f28}, v_hash = 218659, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xc2741b04}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xc0783b4c, lk_flags = 33816640, lk_sharecount = 0, lk_waitcount = 1, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc0729abe "ufs", lk_timo = 6, lk_lockholder = 0xc1fe2300, lk_newlock = 0x0, lk_filename = 0xc072b093 "/var/src/sys/kern/vfs_subr.c", lk_lockername = 0xc072aab4 "vop_stdlock", lk_lineno = 1951, lk_slockholder = 0xffffffff, lk_sfilename = 0xc071d296 "none", lk_slockername = 0xc0724a8d "never share locked", lk_slineno = 0}, v_interlock = {mtx_object = {lo_class = 0xc075b224, lo_name = 0xc072b100 "vnode interlock", lo_type = 0xc072b100 "vnode interlock", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc2741b2c, filename = 0xc07382b1 "/var/src/sys/ufs/ufs/ufs_lookup.c", line = 563, v_holdcnt = 5, v_usecount = 4, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0xc29b4948}, v_bufobj = { bo_mtx = 0xc2741b6c, bo_clean = {bv_hd = {tqh_first = 0xcc1cbd48, tqh_last = 0xcc1cbd80}, bv_root = 0xcc1cbd48, bv_cnt = 1}, bo_dirty = { bv_hd = {tqh_first = 0x0, tqh_last = 0xc2741bcc}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc0761b04, bo_bsize = 16384, bo_object = 0xc30cc39c, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xc2741ad4, __bo_vnode = 0xc2741ad4}, v_pollinfo = 0x0, v_label = 0x0} i) The culprit process knows that it is holding the lock: (kgdb) print ((struct vnode *)0xc2741ad4)->v_lock->lk_lockholder->td_locks $3 = 1 And this is its stack trace, once again in wait4(): (kgdb) where #0 sched_switch (td=0xc1fe2300, newtd=0xc1e5b300, flags=1) at /var/src/sys/kern/sched_4bsd.c:980 #1 0xc1fe2300 in ?? () #2 0xc0526218 in mi_switch (flags=1, newtd=0x0) at /var/src/sys/kern/kern_synch.c:356 #3 0xc0545127 in sleepq_switch (wchan=0x0) at /var/src/sys/kern/subr_sleepqueue.c:427 #4 0xc0545400 in sleepq_wait_sig (wchan=0x0) at /var/src/sys/kern/subr_sleepqueue.c:552 #5 0xc0525e67 in msleep (ident=0xc1fe520c, mtx=0xc1fe5274, priority=348, wmesg=0x0, timo=0) at /var/src/sys/kern/kern_synch.c:225 #6 0xc04feaec in kern_wait (td=0xc1fe2300, pid=-1, status=0xd4922c80, options=0, rusage=0x0) at /var/src/sys/kern/kern_exit.c:772 #7 0xc04fdeed in wait4 (td=0x0, uap=0xd4922d04) at /var/src/sys/kern/kern_exit.c:569 #8 0xc06ed702 in syscall (frame= {tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = 134900352, tf_esi = 9195, tf_ebp = -1077951176, tf_isp = -728617628, tf_ebx = 672547876, t f_edx = 0, tf_ecx = 137943616, tf_eax = 7, tf_trapno = 12, tf_err = 2, tf_eip = 671979599, tf_cs = 51, tf_eflags = 534, tf_esp = -1077951204, tf_ss = 59}) at /var/src/sys/i386/i386/trap.c:976 #9 0xc06d651f in Xint0x80_syscall () at /var/src/sys/i386/i386/exception.s:200 #10 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) The code referenced by the vnode filename and line members is this block in ufs_lookup(): if (flags & ISDOTDOT) { VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ error = VFS_VGET(pdp->v_mount, dp->i_ino, cnp->cn_lkflags, &tdp); --> vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); if (error) return (error); *vpp = tdp; } else ... I don't see any obvious lock leaks in the code. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 10:03:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7BE416A41F for ; Tue, 11 Oct 2005 10:03:01 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E1EA43D48 for ; Tue, 11 Oct 2005 10:03:01 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 492264F365; Tue, 11 Oct 2005 12:03:00 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 2B9AB405A; Tue, 11 Oct 2005 12:02:51 +0200 (CEST) Date: Tue, 11 Oct 2005 12:02:51 +0200 From: Jeremie Le Hen To: "Chen, Lihong" Message-ID: <20051011100250.GP45070@obiwan.tataz.chchile.org> References: <1128989732.865.5.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128989732.865.5.camel@localhost> User-Agent: Mutt/1.5.10i Cc: freebsd-current@freebsd.org Subject: Re: Can not get battery information on RELENG_6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 10:03:02 -0000 Hi, > Hi! All, > I can not retrieve the battery information for my laptop - Acer > TravelMate 4102WLMi. > How can I fix it? > > I've got these error messages: > ACPI-0438: *** Error: Looking up [Z00C] in namespace, AE_NOT_FOUND > SearchNode 0xc22d08a0 StartNode 0xc22d08a0 ReturnNode 0 > ACPI-0438: *** Error: Looking up [Z00C] in namespace, AE_NOT_FOUND > SearchNode 0xc22d08a0 StartNode 0xc22d08a0 ReturnNode 0 > ACPI-1304: *** Error: Method execution failed [\\_SB_.BAT1._BST] > (Node 0xc22d07a0), AE_NOT_FOUND Check this thread, this should resolve your problem : http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050282.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 10:16:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6089C16A41F for ; Tue, 11 Oct 2005 10:16:48 +0000 (GMT) (envelope-from uwe@laverenz.de) Received: from natnoddy.rzone.de (natnoddy.rzone.de [81.169.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9727D43D46 for ; Tue, 11 Oct 2005 10:16:47 +0000 (GMT) (envelope-from uwe@laverenz.de) Received: from athena.laverenz.de (p5480FF97.dip.t-dialin.net [84.128.255.151]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j9BAGinM013191 for ; Tue, 11 Oct 2005 12:16:45 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id 38A27E39CD6A for ; Tue, 11 Oct 2005 12:16:44 +0200 (CEST) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17679-02 for ; Tue, 11 Oct 2005 12:16:42 +0200 (CEST) Received: by athena.laverenz.de (Postfix, from userid 2000) id 7A68DE39CD65; Tue, 11 Oct 2005 12:16:42 +0200 (CEST) Date: Tue, 11 Oct 2005 12:16:42 +0200 From: Uwe Laverenz To: freebsd-current@freebsd.org Message-ID: <20051011101642.GA17532@laverenz.de> Mail-Followup-To: freebsd-current@freebsd.org References: <1128613406.84353.5.camel@beeyatch.mean.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128613406.84353.5.camel@beeyatch.mean.net> Organization: private site Sender: uwe@laverenz.de User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at laverenz.de Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 10:16:48 -0000 On Thu, Oct 06, 2005 at 05:43:25PM +0200, Mika wrote: > has anyone have the problem that firefox dies spontaneously ? I get this I have the same problem with Mozilla since I switched from RELENG_5 to RELENG_6. I've rebuilt all my ports completely but it keeps crashing from time to time. This can happen after hours or after a few minutes, mostly when klicking a link. I think it's related to FreeBSD 6 as I don't see this problem on 5.x machines with similar setup. I have linuxpluginwrapper installed on all machines. I would like to make a PR but I'm not sure how to collect some useful information from the mozilla-bin.core. I start gdb with: $ gdb /usr/X11R6/lib/mozilla/mozilla-bin mozilla-bin.core 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"...(no debugging symbols found)... Core was generated by `mozilla-bin'. Program terminated with signal 11, Segmentation fault. ... [Reading/Loading symbols information snipped] ... #0 0x285ba40b in pthread_testcancel () from /usr/lib/libpthread.so.2 [New Thread 0xa826400 (sleeping)] [New Thread 0x83c4400 (sleeping)] [New Thread 0x8f78e00 (sleeping)] [New Thread 0x8f78600 (sleeping)] [New Thread 0x8f53e00 (sleeping)] [New Thread 0x8f53600 (sleeping)] [New Thread 0x8f1ce00 (sleeping)] [New Thread 0x80cee00 (sleeping)] [New Thread 0x8132600 (runnable)] [New Thread 0x8132400 (LWP 100156)] [New Thread 0x8074000 (LWP 100152)] (gdb) where #0 0x285ba40b in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x285ab1e5 in sigaction () from /usr/lib/libpthread.so.2 #2 0x285a5269 in pthread_kill () from /usr/lib/libpthread.so.2 #3 0x285a4c38 in raise () from /usr/lib/libpthread.so.2 #4 0x29829667 in nsProfileLock::FatalSignalHandler () from /usr/X11R6/lib/mozilla/components/libprofile.so #5 0x285a9ec6 in sigaction () from /usr/lib/libpthread.so.2 #6 0x285a9d4b in sigaction () from /usr/lib/libpthread.so.2 #7 0x285aa90c in sigaction () from /usr/lib/libpthread.so.2 #8 0x285b3134 in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 #9 0x285b3028 in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 #10 0x286619a7 in _ctx_start () from /lib/libc.so.6 #11 0x00000000 in ?? () #12 0xbfbf9f80 in ?? () #13 0xbfbf9cc0 in ?? () #14 0x00000000 in ?? () #15 0x285b2fc4 in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 #16 0x2aa4e5da in ChunkMalloc::Free () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #17 0x2aa4eaaa in __builtin_delete () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #18 0x2aad3f96 in jpeg_free_small () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #19 0x2aad3fe4 in jpeg_free_large () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #20 0x2aad3d5e in jpeg_idct_islow () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #21 0x2aaccaf7 in jpeg_abort () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #22 0x2aacd197 in jpeg_finish_decompress () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #23 0x2aad45dc in PlatformJpeg::ReadJPEGImage () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #24 0x2aad4694 in PlatformJpeg::GetImageBitmap () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #25 0x2aa7b89c in ScriptThread::BuildBits () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #26 0x2aa78a16 in SShapeParser::GetStyles () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #27 0x2aa71e99 in SCharacterParser::BuildEdges () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #28 0x2aa72b1b in SObject::BuildEdges () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #29 0x2aa752a2 in SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #30 0x2aa74f86 in SObject::DrawClipBracket () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #31 0x2aa75301 in SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #32 0x2aa7532f in SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #33 0x2aa7532f in SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #34 0x2aa6513d in DisplayList::UpdateRect () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #35 0x2aa6548b in DisplayList::Update () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #36 0x2aaa3099 in CorePlayer::UpdateBuffer () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #37 0x2aaa29c2 in CorePlayer::DrawScreen () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #38 0x2aaa2f5d in CorePlayer::UpdateScreen () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #39 0x2aa9b8d2 in CorePlayer::DoPlay () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #40 0x2aac5dd5 in UnixCommonPlayer::OnTimer () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #41 0x2aafaad5 in PlatformPlayer::TimerProc () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #42 0x297705cd in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #43 0x29741ad8 in ?? () from /usr/X11R6/lib/mozilla/libgtkxtbin.so #44 0x09bc8200 in ?? () #45 0x0000000f in ?? () #46 0xbfbfe478 in ?? () #47 0x29741aaa in ?? () from /usr/X11R6/lib/mozilla/libgtkxtbin.so #48 0x288ca338 in ?? () from /usr/local/lib/libglib-2.0.so.600 #49 0x086fd800 in ?? () #50 0xbfbfe478 in ?? () #51 0x2887326c in g_main_context_wakeup () from /usr/local/lib/libglib-2.0.so.600 Previous frame identical to this frame (corrupt stack?) (gdb) I obviously don't have a clue about how to use gdb, what can I do next? tnx, Uwe From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 11:42:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B192416A421 for ; Tue, 11 Oct 2005 11:42:13 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A97A43D83 for ; Tue, 11 Oct 2005 11:42:12 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from [192.168.1.109] (pcp0011002249pcs.longhl01.md.comcast.net[68.55.192.50]) by comcast.net (sccrmhc13) with ESMTP id <2005101111420801300bcs0le>; Tue, 11 Oct 2005 11:42:08 +0000 From: Derrick Edwards To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2005 07:41:49 -0400 User-Agent: KMail/1.8.2 References: <1128613406.84353.5.camel@beeyatch.mean.net> <20051011101642.GA17532@laverenz.de> In-Reply-To: <20051011101642.GA17532@laverenz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510110741.49953.dantavious@comcast.net> Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 11:42:13 -0000 On Tuesday 11 October 2005 06:16, Uwe Laverenz wrote: Hi, I am seeing the same thing also. I updated my /etc/libmap.conf for FreeBSD 6. I recompiled Firefox also. When I go to nfl.com, firefox dies. Any ideas, Derrick > On Thu, Oct 06, 2005 at 05:43:25PM +0200, Mika wrote: > > has anyone have the problem that firefox dies spontaneously ? I get this > > I have the same problem with Mozilla since I switched from RELENG_5 to > RELENG_6. I've rebuilt all my ports completely but it keeps crashing > from time to time. This can happen after hours or after a few minutes, > mostly when klicking a link. > > I think it's related to FreeBSD 6 as I don't see this problem on 5.x > machines with similar setup. I have linuxpluginwrapper installed on all > machines. > > I would like to make a PR but I'm not sure how to collect some useful > information from the mozilla-bin.core. I start gdb with: > > $ gdb /usr/X11R6/lib/mozilla/mozilla-bin mozilla-bin.core > > 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"...(no debugging > symbols found)... > Core was generated by `mozilla-bin'. > Program terminated with signal 11, Segmentation fault. > ... > [Reading/Loading symbols information snipped] > ... > #0 0x285ba40b in pthread_testcancel () from /usr/lib/libpthread.so.2 > [New Thread 0xa826400 (sleeping)] > [New Thread 0x83c4400 (sleeping)] > [New Thread 0x8f78e00 (sleeping)] > [New Thread 0x8f78600 (sleeping)] > [New Thread 0x8f53e00 (sleeping)] > [New Thread 0x8f53600 (sleeping)] > [New Thread 0x8f1ce00 (sleeping)] > [New Thread 0x80cee00 (sleeping)] > [New Thread 0x8132600 (runnable)] > [New Thread 0x8132400 (LWP 100156)] > [New Thread 0x8074000 (LWP 100152)] > > (gdb) where > #0 0x285ba40b in pthread_testcancel () from /usr/lib/libpthread.so.2 > #1 0x285ab1e5 in sigaction () from /usr/lib/libpthread.so.2 > #2 0x285a5269 in pthread_kill () from /usr/lib/libpthread.so.2 > #3 0x285a4c38 in raise () from /usr/lib/libpthread.so.2 > #4 0x29829667 in nsProfileLock::FatalSignalHandler () from > /usr/X11R6/lib/mozilla/components/libprofile.so > #5 0x285a9ec6 in sigaction () from /usr/lib/libpthread.so.2 > #6 0x285a9d4b in sigaction () from /usr/lib/libpthread.so.2 > #7 0x285aa90c in sigaction () from /usr/lib/libpthread.so.2 > #8 0x285b3134 in pthread_mutexattr_init () from > /usr/lib/libpthread.so.2 > #9 0x285b3028 in pthread_mutexattr_init () from > /usr/lib/libpthread.so.2 > #10 0x286619a7 in _ctx_start () from /lib/libc.so.6 > #11 0x00000000 in ?? () > #12 0xbfbf9f80 in ?? () > #13 0xbfbf9cc0 in ?? () > #14 0x00000000 in ?? () > #15 0x285b2fc4 in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 > #16 0x2aa4e5da in ChunkMalloc::Free () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #17 0x2aa4eaaa in > __builtin_delete () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #18 0x2aad3f96 in > jpeg_free_small () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so > #19 0x2aad3fe4 in jpeg_free_large () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #20 0x2aad3d5e in > jpeg_idct_islow () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so > #21 0x2aaccaf7 in jpeg_abort () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #22 0x2aacd197 in > jpeg_finish_decompress () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #23 0x2aad45dc in > PlatformJpeg::ReadJPEGImage () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #24 0x2aad4694 in > PlatformJpeg::GetImageBitmap () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #25 0x2aa7b89c in > ScriptThread::BuildBits () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #26 0x2aa78a16 in > SShapeParser::GetStyles () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #27 0x2aa71e99 in > SCharacterParser::BuildEdges () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #28 0x2aa72b1b in > SObject::BuildEdges () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #29 0x2aa752a2 in > SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so > #30 0x2aa74f86 in SObject::DrawClipBracket () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #31 0x2aa75301 in > SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so > #32 0x2aa7532f in SObject::Draw () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #33 0x2aa7532f in > SObject::Draw () from /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so > #34 0x2aa6513d in DisplayList::UpdateRect () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #35 0x2aa6548b in > DisplayList::Update () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #36 0x2aaa3099 in > CorePlayer::UpdateBuffer () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #37 0x2aaa29c2 in > CorePlayer::DrawScreen () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #38 0x2aaa2f5d in > CorePlayer::UpdateScreen () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #39 0x2aa9b8d2 in > CorePlayer::DoPlay () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #40 0x2aac5dd5 in > UnixCommonPlayer::OnTimer () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #41 0x2aafaad5 in > PlatformPlayer::TimerProc () from > /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so #42 0x297705cd in > XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #43 0x29741ad8 in ?? () > from /usr/X11R6/lib/mozilla/libgtkxtbin.so #44 0x09bc8200 in ?? () > #45 0x0000000f in ?? () > #46 0xbfbfe478 in ?? () > #47 0x29741aaa in ?? () from /usr/X11R6/lib/mozilla/libgtkxtbin.so > #48 0x288ca338 in ?? () from /usr/local/lib/libglib-2.0.so.600 > #49 0x086fd800 in ?? () > #50 0xbfbfe478 in ?? () > #51 0x2887326c in g_main_context_wakeup () from > /usr/local/lib/libglib-2.0.so.600 > Previous frame identical to this frame (corrupt stack?) > (gdb) > > I obviously don't have a clue about how to use gdb, what can I do next? > > tnx, > Uwe > > _______________________________________________ > 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 Tue Oct 11 12:15:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95AF216A420 for ; Tue, 11 Oct 2005 12:15:14 +0000 (GMT) (envelope-from roger@gwch.net) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFDDC43D73 for ; Tue, 11 Oct 2005 12:15:13 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (84-73-90-203.dclient.hispeed.ch [84.73.90.203]) (authenticated bits=0) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j9BCFCqA015774 for ; Tue, 11 Oct 2005 14:15:12 +0200 Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id 1608340522 for ; Tue, 11 Oct 2005 14:15:12 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23972-06 for ; Tue, 11 Oct 2005 14:15:08 +0200 (CEST) Received: from [10.0.0.98] (frodo.gwch.net [192.168.2.101]) by mail.gwch.net (Postfix) with ESMTP id 4CCD4404D9 for ; Tue, 11 Oct 2005 14:15:08 +0200 (CEST) Message-ID: <434BACCA.6030806@gwch.net> Date: Tue, 11 Oct 2005 14:15:06 +0200 From: Roger Grosswiler User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on smtp-03.tornado.cablecom.ch X-Virus-Scanned: amavisd-new at gwch.net X-Virus-Status: Clean X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-03.tornado.cablecom.ch 32701; Body=1 Fuz1=1 Fuz2=1 Subject: GNOME: Docklets not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 12:15:14 -0000 Hey, Have 6.0/B5 up and running. But running apps such as gaim, psi or others, that use docklets under gnome do not work. if i "close" the app, this terminates instead of minimizes the application. Is there something special to follow? Roger From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:33:48 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE5A16A423 for ; Tue, 11 Oct 2005 12:33:48 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from e0-a11.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC71843D9E for ; Tue, 11 Oct 2005 12:33:28 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1]) by e0-a11.b1.lan.prg.vol.cz (8.13.4/8.13.4) with ESMTP id j9BCXQMW070389; Tue, 11 Oct 2005 14:33:26 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.13.4/8.13.4/Submit) id j9BCXPKb070388; Tue, 11 Oct 2005 14:33:25 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Roger Grosswiler In-Reply-To: <434BACCA.6030806@gwch.net> References: <434BACCA.6030806@gwch.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/c2RHm+CpyF32oij1SH7" Date: Tue, 11 Oct 2005 14:33:24 +0200 Message-Id: <1129034004.64291.10.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-current@FreeBSD.org Subject: Re: GNOME: Docklets not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@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: Tue, 11 Oct 2005 12:33:48 -0000 --=-/c2RHm+CpyF32oij1SH7 Content-Type: text/plain; charset=ISO8859-2 Content-Transfer-Encoding: quoted-printable Roger Grosswiler p=ED=B9e v =FAt 11. 10. 2005 v 14:15 +0200: > Hey, >=20 > Have 6.0/B5 up and running. But running apps such as gaim, psi or=20 > others, that use docklets under gnome do not work. >=20 > if i "close" the app, this terminates instead of minimizes the applicatio= n. >=20 > Is there something special to follow? What do you mean by "docklet"? That's nonexistant term. How is this related to running -CURRENT? --=20 Pav Lucistnik God is real unless declared integer. --=-/c2RHm+CpyF32oij1SH7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDS7EUntdYP8FOsoIRAvD1AJ9J+UnLFCeKkYXS8wYheJul31o4qQCeIT3W +aUyk7YCGuRtmC96ZjTH4bk= =DRr2 -----END PGP SIGNATURE----- --=-/c2RHm+CpyF32oij1SH7-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 21:56:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F77E16A41F for ; Mon, 10 Oct 2005 21:56:18 +0000 (GMT) (envelope-from reddie@gmx.net) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C502343D45 for ; Mon, 10 Oct 2005 21:56:17 +0000 (GMT) (envelope-from reddie@gmx.net) Received: (qmail 11256 invoked by uid 0); 10 Oct 2005 21:56:16 -0000 Received: from 62.194.236.237 by www15.gmx.net with HTTP; Mon, 10 Oct 2005 23:56:16 +0200 (MEST) Date: Mon, 10 Oct 2005 23:56:16 +0200 (MEST) From: "reddie crack" To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated: #520211 Message-ID: <4906.1128981376@www15.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 Oct 2005 12:39:14 +0000 Subject: ACPI Resume problem on Acer Aspire 2001WLCi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2005 21:56:18 -0000 Hello, I've installed BSD on my Acer Apsire 2001WLCi laptop. I was trying to suspend the laptop in S3 state. The suspend was working, but on resume the laptop only spins the drive up and some leds. No display, No keyboard, No network (tryd ssh). When i suspend to S4 state then the systems goes off en when i press the powerbutton the systems display comes back for 2 seconds. The two second screen is frozen en mouse or keyboard doesn't work. tryd serveral options like vtswicth and reset_video but that don't make any difference. Some data: http://bsd.dewijzenuithetoosten.nl/dmesg.boot http://bsd.dewijzenuithetoosten.nl/hw.acpi http://bsd.dewijzenuithetoosten.nl/reddie-AcerAspire2001WLCi.asl Hope there will be a solution soon. Greetingz. -- NEU: Telefon-Flatrate fürs dt. Festnetz! GMX Phone_Flat: 9,99 Euro/Mon.* Für DSL-Nutzer. Ohne Providerwechsel! http://www.gmx.net/de/go/telefonie From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 02:56:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CA4316A41F for ; Tue, 11 Oct 2005 02:56:14 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B3A43D45 for ; Tue, 11 Oct 2005 02:56:13 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9B2uC0J024230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Oct 2005 19:56:13 -0700 X-Auth-Received: from yggdrasil.seektruth.org (c-67-171-38-33.hsd1.wa.comcast.net [67.171.38.33]) (authenticated authid=dsyphers) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9B2uCaM019321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Oct 2005 19:56:12 -0700 From: David Syphers To: freebsd-current@freebsd.org User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 10 Oct 2005 19:56:12 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200510101956.12743.dsyphers@u.washington.edu> X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CD 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __USER_AGENT 0' X-Mailman-Approved-At: Tue, 11 Oct 2005 12:39:14 +0000 Subject: Intel 810 and agpgart on 6.0-beta5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 02:56:14 -0000 I'm trying to install X.org 6.8.2 on a new machine, and failing. I'm running 6-BETA5. When I try to run X (say with 'X -config /root/xorg.conf.new') it fails with (WW) I810: No matching Device section for instance (BusID PCI:0:2:1) found (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) (If it helps, at this point the message "1. Analog Input Cannot Display This Video Mode" appears on the ttyv8 screen.) I'm working on trying to figure out the warning, since I think my xorg.conf looks okay, but my question at the moment is how do I get /dev/agpgart? Sure enough it isn't in /dev, but I have 'device agp' in my kernel config, _and_ I have 'agp_load="YES"' in /boot/loader.conf. So I'm not sure why it's not being created... http://www.seektruth.org/errors/Xorg.0.log http://www.seektruth.org/errors/xorg.conf.new Any ideas? Thanks, -David -- "What's the good of having mastery over cosmic balance and knowing the secrets of fate if you can't blow something up?" -Terry Pratchett From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:03:10 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6938916A420 for ; Tue, 11 Oct 2005 12:03:10 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F4D43D73 for ; Tue, 11 Oct 2005 12:03:03 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ydilcl@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j9BC32Kf098195 for ; Tue, 11 Oct 2005 14:03:02 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j9BC31nj098194; Tue, 11 Oct 2005 14:03:01 +0200 (CEST) (envelope-from olli) Date: Tue, 11 Oct 2005 14:03:01 +0200 (CEST) Message-Id: <200510111203.j9BC31nj098194@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <200510110741.49953.dantavious@comcast.net> X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) X-Mailman-Approved-At: Tue, 11 Oct 2005 12:39:14 +0000 Cc: Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Tue, 11 Oct 2005 12:03:10 -0000 [broken quoting fixed] Derrick Edwards wrote: > On Tuesday 11 October 2005 06:16, Uwe Laverenz wrote: > > On Thu, Oct 06, 2005 at 05:43:25PM +0200, Mika wrote: > > > has anyone have the problem that firefox dies spontaneously ? I get this > > > > I have the same problem with Mozilla since I switched from RELENG_5 to > > RELENG_6. I've rebuilt all my ports completely but it keeps crashing > > from time to time. This can happen after hours or after a few minutes, > > mostly when klicking a link. > > I am seeing the same thing also. I updated my /etc/libmap.conf for FreeBSD 6. > I recompiled Firefox also. When I go to nfl.com, firefox dies. Do you happen to have any unusual settings in your /etc/make.conf file? Particularly CFLAGS? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:48:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0A4A16A43A for ; Tue, 11 Oct 2005 12:48:05 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 495E343D46 for ; Tue, 11 Oct 2005 12:48:04 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id j9BClNX1093434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Oct 2005 14:47:23 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id j9BClNi0093433 for freebsd-current@freebsd.org; Tue, 11 Oct 2005 14:47:23 +0200 (CEST) (envelope-from csaba) Date: Tue, 11 Oct 2005 14:47:23 +0200 From: Csaba Henk To: freebsd-current@freebsd.org Message-ID: <20051011124723.GD2911@beastie.creo.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: panic: softdep_setup_inomapdep: found inode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 12:48:06 -0000 Hi! I was installing some binary packages on my CURRENT of Sep 29, when I ran into the following: Script started on Tue Oct 11 06:36:48 2005 bash-3.00# kgdb kernel /mnt/foo/crash/vmcore.60 [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: panic: softdep_setup_inomapdep: found inode cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 9m35s Dumping 479 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 479MB (122608 pages) 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:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0636b9c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0636eb1 in panic (fmt=0xc0834e12 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc04696e1 in db_panic (addr=-1067127777, have_addr=0, count=-1, modif=0xd96b6724 "") at /usr/src/sys/ddb/db_command.c:432 #4 0xc0469678 in db_command (last_cmdp=0xc091be04, cmd_table=0x0, aux_cmd_tablep=0xc08978a4, aux_cmd_tablep_end=0xc08978c0) at /usr/src/sys/ddb/db_command.c:401 #5 0xc0469740 in db_command_loop () at /usr/src/sys/ddb/db_command.c:452 #6 0xc046b2e1 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc064eeb8 in kdb_trap (type=3, code=0, tf=0xd96b6868) at /usr/src/sys/kern/subr_kdb.c:473 #8 0xc07ffd10 in trap (frame= {tf_fs = -647299064, tf_es = -1067122648, tf_ds = -1064959960, tf_edi = -1064813645, tf_esi = 1, tf_ebp = -647272280, tf_isp = -647272300, tf_ebx = -647272236, tf_edx = 0, tf_ecx = -1056755712, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067127777, tf_cs = 32, tf_eflags = 642, tf_esp = -647272248, tf_ss = -1067225501}) at /usr/src/sys/i386/i386/trap.c:601 #9 0xc07ed72a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xc064ec1f in kdb_enter (msg=0x12
) at cpufunc.h:60 #11 0xc0636e63 in panic (fmt=0xc0883bb3 "softdep_setup_inomapdep: found inode") at /usr/src/sys/kern/kern_shutdown.c:539 #12 0xc07759a5 in softdep_setup_inomapdep (bp=0xcb3d6be0, ip=0x12, newinum=12904) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1388 #13 0xc07692ec in ffs_nodealloccg (ip=0xc26f97bc, cg=0, ipref=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1740 #14 0xc0767ca7 in ffs_hashalloc (ip=0xc26f97bc, cg=0, pref=0, size=16832, allocator=0xc0768cc0 ) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1226 #15 0xc07673df in ffs_valloc (pvp=0xc26e8cc0, mode=16832, cred=0xc1fb2300, vpp=0xd96b6a10) at /usr/src/sys/ufs/ffs/ffs_alloc.c:920 #16 0xc078a70c in ufs_mkdir (ap=0xd96b6bb8) at /usr/src/sys/ufs/ufs/ufs_vnops.c:1334 #17 0xc0811272 in VOP_MKDIR_APV (vop=0x12, a=0xd96b6bb8) at vnode_if.c:1251 #18 0xc0692d62 in kern_mkdir (td=0xc1b6c480, path=0x805a0c0
, segflg=UIO_USERSPACE, mode=448) at vnode_if.h:653 #19 0xc0692a95 in mkdir (td=0xc1b6c480, uap=0x12) at /usr/src/sys/kern/vfs_syscalls.c:3301 #20 0xc08004fb in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134586560, tf_esi = 134586580, tf_ebp = -1077942104, tf_isp = -647271068, tf_ebx = 671699716, tf_edx = 0, tf_ecx = -1077942384, tf_eax = 136, tf_trapno = 0, tf_err = 2, tf_eip = 672522563, tf_cs = 51, tf_eflags = 662, tf_esp = -1077942260, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:986 #21 0xc07ed77f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #22 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) bash-3.00# logout Script done on Tue Oct 11 06:36:56 2005 Csaba From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:00:09 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9588216A43C; Tue, 11 Oct 2005 13:00:09 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mxout.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B0EC43D49; Tue, 11 Oct 2005 13:00:06 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (84-73-90-203.dclient.hispeed.ch [84.73.90.203]) (authenticated bits=0) by mxout.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j9BD04aY016911; Tue, 11 Oct 2005 15:00:05 +0200 Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id E8D8F40522; Tue, 11 Oct 2005 15:00:00 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24129-09; Tue, 11 Oct 2005 14:59:55 +0200 (CEST) Received: from [10.0.0.98] (frodo.gwch.net [192.168.2.101]) by mail.gwch.net (Postfix) with ESMTP id A82734051D; Tue, 11 Oct 2005 14:59:55 +0200 (CEST) Message-ID: <434BB749.5000102@gwch.net> Date: Tue, 11 Oct 2005 14:59:53 +0200 From: Roger Grosswiler User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pav@FreeBSD.org References: <434BACCA.6030806@gwch.net> <1129034004.64291.10.camel@pav.hide.vol.cz> In-Reply-To: <1129034004.64291.10.camel@pav.hide.vol.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on smtp-04.tornado.cablecom.ch X-Virus-Scanned: amavisd-new at gwch.net X-Virus-Status: Clean X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-04.tornado.cablecom.ch 32701; Body=2 Fuz1=2 Fuz2=2 Cc: freebsd-current@FreeBSD.org Subject: Re: GNOME: Docklets not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:00:09 -0000 Pav Lucistnik wrote: > Roger Grosswiler píše v út 11. 10. 2005 v 14:15 +0200: > >>Hey, >> >>Have 6.0/B5 up and running. But running apps such as gaim, psi or >>others, that use docklets under gnome do not work. >> >>if i "close" the app, this terminates instead of minimizes the application. >> >>Is there something special to follow? > > > What do you mean by "docklet"? That's nonexistant term. > > How is this related to running -CURRENT? > Definition of a Docklet: http://developer.gnome.org/doc/API/panel/r1373.html Related tu running -CURRENT: state working in Linux (has not been tested in FreeBSD 5.4) Roger From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:13:58 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5182F16A427 for ; Tue, 11 Oct 2005 13:13:58 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id D81E143D8D for ; Tue, 11 Oct 2005 13:13:49 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (hktgbs@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j9BDDl07000936; Tue, 11 Oct 2005 15:13:48 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j9BDDlgi000935; Tue, 11 Oct 2005 15:13:47 +0200 (CEST) (envelope-from olli) Date: Tue, 11 Oct 2005 15:13:47 +0200 (CEST) Message-Id: <200510111313.j9BDDlgi000935@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, dsyphers@u.washington.edu In-Reply-To: <200510101956.12743.dsyphers@u.washington.edu> X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) X-Mailman-Approved-At: Tue, 11 Oct 2005 13:15:22 +0000 Cc: Subject: Re: Intel 810 and agpgart on 6.0-beta5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:13:58 -0000 David Syphers wrote: > I'm trying to install X.org 6.8.2 on a new machine, and failing. I'm running > 6-BETA5. > > When I try to run X (say with 'X -config /root/xorg.conf.new') it fails with > > (WW) I810: No matching Device section for instance (BusID PCI:0:2:1) found > (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) > > (If it helps, at this point the message "1. Analog Input Cannot Display This > Video Mode" appears on the ttyv8 screen.) > > I'm working on trying to figure out the warning, since I think my xorg.conf > looks okay, but my question at the moment is how do I get /dev/agpgart? Sure > enough it isn't in /dev, but I have 'device agp' in my kernel config, _and_ I > have 'agp_load="YES"' in /boot/loader.conf. So I'm not sure why it's not being > created... Because you don't have a supported chipset. I have the same situation on my notebook with intel i915GM, for which there is no agpgart support yet for FreeBSD. I suggest you use the latest X.org snapshot from the ports collection (6.8.99.12, ports/x11-servers/xorg-server-snap), or download a precompiled package. It works fine with 2D acceleration, which is sufficient for standard applications (web browsing, office apps, gimp). However, you won't get 3D acceleration (for games), no hardware cursor support, no xvideo extension (for video playback). It's not a big problem for me, because the CPU is fast enough for video playback without acceleration support. YMMV. Having said that, there _are_ patches for i810 support. You can find them in PR 80396. After applying the patches, I got /dev/agpgart and X.org picked it up -- but I had to disable hardware cursor and acceleration in the X.org conf. That means, even though I got the agpgart device, I ended up losing 2D acceleration support. Therefore I currently recommend _not_ to use the patches from that PR. I suspect that a newer X.org snapshot might help. There's even a recent release candidate of X.org 6.9. But nobody has done a FreeBSD port from it, and my half-hearted (due to lack of time) attempt to it failed. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:20:44 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18F8516A430 for ; Tue, 11 Oct 2005 13:20:44 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from e0-a11.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1943943D45 for ; Tue, 11 Oct 2005 13:20:42 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1]) by e0-a11.b1.lan.prg.vol.cz (8.13.4/8.13.4) with ESMTP id j9BDKeQD070775; Tue, 11 Oct 2005 15:20:40 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.13.4/8.13.4/Submit) id j9BDKeIs070774; Tue, 11 Oct 2005 15:20:40 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Roger Grosswiler In-Reply-To: <434BB749.5000102@gwch.net> References: <434BACCA.6030806@gwch.net> <1129034004.64291.10.camel@pav.hide.vol.cz> <434BB749.5000102@gwch.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZCIVR/iclPQx391eAAUw" Date: Tue, 11 Oct 2005 15:20:39 +0200 Message-Id: <1129036839.64291.15.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-current@FreeBSD.org Subject: Re: GNOME: Docklets not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@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: Tue, 11 Oct 2005 13:20:44 -0000 --=-ZCIVR/iclPQx391eAAUw Content-Type: text/plain; charset=ISO8859-2 Content-Transfer-Encoding: quoted-printable Roger Grosswiler p=ED=B9e v =FAt 11. 10. 2005 v 14:59 +0200: > Pav Lucistnik wrote: > > Roger Grosswiler p=ED=B9e v =FAt 11. 10. 2005 v 14:15 +0200: > >=20 > >>Hey, > >> > >>Have 6.0/B5 up and running. But running apps such as gaim, psi or=20 > >>others, that use docklets under gnome do not work. > >> > >>if i "close" the app, this terminates instead of minimizes the applicat= ion. > >> > >>Is there something special to follow? > >=20 > >=20 > > What do you mean by "docklet"? That's nonexistant term. > >=20 > > How is this related to running -CURRENT? > >=20 > Definition of a Docklet: http://developer.gnome.org/doc/API/panel/r1373.h= tml >=20 > Related tu running -CURRENT: state working in Linux (has not been tested=20 > in FreeBSD 5.4) So, those are the icons that appear in Notification Area Applet? They work quite fine here. Make sure you have "Panel icon" plugin enabled in Gaim. (The names can be a bit off - I'm translating from czech translation back to english) --=20 Pav Lucistnik Quantum physics was developed in the 1930's, as a result of a bet between Albert Einstein and Niels Bohr, to see who could come up with the most ridiculous theory and still have it published. --=-ZCIVR/iclPQx391eAAUw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDS7wnntdYP8FOsoIRAh5/AJwMba9O8HKqU355hVdNnV9P1q6V4ACglCvk UeT/3GU3+tGNWTAr7GlpBy4= =AnnR -----END PGP SIGNATURE----- --=-ZCIVR/iclPQx391eAAUw-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:23:36 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE3216A42F; Tue, 11 Oct 2005 13:23:36 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mxout.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC02743D78; Tue, 11 Oct 2005 13:23:29 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (84-73-90-203.dclient.hispeed.ch [84.73.90.203]) (authenticated bits=0) by mxout.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j9BDNSii001277; Tue, 11 Oct 2005 15:23:28 +0200 Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id 3E6E040522; Tue, 11 Oct 2005 15:23:28 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26902-02; Tue, 11 Oct 2005 15:23:22 +0200 (CEST) Received: from [10.0.0.98] (frodo.gwch.net [192.168.2.101]) by mail.gwch.net (Postfix) with ESMTP id 838C54051D; Tue, 11 Oct 2005 15:23:22 +0200 (CEST) Message-ID: <434BBCC6.5030902@gwch.net> Date: Tue, 11 Oct 2005 15:23:18 +0200 From: Roger Grosswiler User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pav@FreeBSD.org References: <434BACCA.6030806@gwch.net> <1129034004.64291.10.camel@pav.hide.vol.cz> <434BB749.5000102@gwch.net> <1129036839.64291.15.camel@pav.hide.vol.cz> In-Reply-To: <1129036839.64291.15.camel@pav.hide.vol.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on smtp-02.tornado.cablecom.ch X-Virus-Scanned: amavisd-new at gwch.net X-Virus-Status: Clean X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics: smtp-02.tornado.cablecom.ch 32700; Body=2 Fuz1=2 Fuz2=2 Cc: freebsd-current@FreeBSD.org Subject: Re: GNOME: Docklets not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:23:36 -0000 Pav Lucistnik wrote: > Roger Grosswiler píše v út 11. 10. 2005 v 14:59 +0200: > >>Pav Lucistnik wrote: >> >>>Roger Grosswiler píše v út 11. 10. 2005 v 14:15 +0200: >>> >>> >>>>Hey, >>>> >>>>Have 6.0/B5 up and running. But running apps such as gaim, psi or >>>>others, that use docklets under gnome do not work. >>>> >>>>if i "close" the app, this terminates instead of minimizes the application. >>>> >>>>Is there something special to follow? >>> >>> >>>What do you mean by "docklet"? That's nonexistant term. >>> >>>How is this related to running -CURRENT? >>> >> >>Definition of a Docklet: http://developer.gnome.org/doc/API/panel/r1373.html >> >>Related tu running -CURRENT: state working in Linux (has not been tested >>in FreeBSD 5.4) > > > So, those are the icons that appear in Notification Area Applet? > They work quite fine here. Make sure you have "Panel icon" plugin > enabled in Gaim. > > (The names can be a bit off - I'm translating from czech translation > back to english) > no prob, pav. i tried this, it is clicked, but it doesn't keep, i have to leave the windows minimized in the menubar.... :-( Roger From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:45:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B06816A42D for ; Tue, 11 Oct 2005 13:45:31 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7056943D45 for ; Tue, 11 Oct 2005 13:45:29 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9BDjSxP017695 for ; Tue, 11 Oct 2005 23:45:28 +1000 Received: from dirk.no.domain (ppp2DF0.dyn.pacific.net.au [61.8.45.240]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9BDjQN1000553 for ; Tue, 11 Oct 2005 23:45:26 +1000 Date: Tue, 11 Oct 2005 23:46:14 +1000 From: Sam Lawrance To: freebsd-current@freebsd.org Message-ID: <20051011234614.20c838a1@dirk.no.domain> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: more usb keyboard (and mouse) troubles with 6.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:45:31 -0000 FreeBSD dirk.no.domain 6.0-RC1 FreeBSD 6.0-RC1 #0: Tue Oct 11 15:51:46 EST 2005 sam@dirk.no.domain:/usr/src/sys/i386/compile/GENERIC i386 This one is interesting. I have two USB keyboard/mouse combination devices here: - An IBM (0x04b3) IBM Standard USB Keyboard (0x3001). Mouse has 2 buttons + Z-dir. - And a Belkin wireless which shows up as something generic (vendor 0x05fe device 0x1010). Mouse has 5 buttons + Z-dir. The IBM setup works fine. No troubles in console or X, both kbd and mouse work as expected. The Belkin setup works OK initially. But as soon as I move the mouse, all keyboard and mouse input is locked up. The system is not frozen - if I reboot, run top and repeat, it continues to run and shows nothing ominous. The result is the same in console or X. Since the IBM works, I guess something about the Belkin is tickling a fairly specific problem somewhere. A ktrace of moused shows: 265 moused 0.000000 RET select 1 265 moused 0.000204 CALL read(0x3,0xbfbfe73f,0x1) 265 moused 0.000221 GIO fd 3 read 1 byte 0x0000 83 |.| 265 moused 0.000292 RET read 1 265 moused 0.000294 CALL select(0x400,0xbfbfe780,0,0,0) 265 moused 0.000296 RET select 1 265 moused 0.000298 CALL read(0x3,0xbfbfe73f,0x1) 265 moused 0.000301 GIO fd 3 read 1 byte "\0" (6 more of the previous block) 265 moused 0.000302 RET read 1 265 moused 0.000305 CALL select(0x400,0xbfbfe780,0,0,0) 265 moused 0.000307 RET select 1 265 moused 0.000309 CALL read(0x3,0xbfbfe73f,0x1) 265 moused 0.000312 GIO fd 3 read 1 byte 0x0000 7f |.| 265 moused 0.000313 RET read 1 265 moused 0.000319 CALL gettimeofday(0xbfbfe6d0,0) 265 moused 0.000322 RET gettimeofday 0 265 moused 0.000331 CALL ioctl(0x5,CONS_MOUSECTL,0xbfbfe6b0) 265 moused 0.000354 RET ioctl 0 265 moused 0.000357 CALL select(0x400,0xbfbfe780,0,0,0) 265 moused 22.376219 RET select -1 errno 4 Interrupted system call 265 moused 22.376229 PSIG SIGTERM caught handler=0x8049874 mask=0x0 code=0x0 265 moused 22.376322 CALL exit(0) You can see I waited about 20 seconds before rebooting. Lots of mouse-wiggling and key-bashing in that time to no avail. Any ideas where to look next? I'm building a kernel now with debugging and USB debugging turned on. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:43:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E06616A42F for ; Tue, 11 Oct 2005 13:43:54 +0000 (GMT) (envelope-from gwenj-pas-de-spam@free.fr) Received: from mail.libertysurf.net (mx-out.tiscali.fr [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1ACF43D46 for ; Tue, 11 Oct 2005 13:43:53 +0000 (GMT) (envelope-from gwenj-pas-de-spam@free.fr) Received: from [83.154.141.7] (83.154.141.7) by mail.libertysurf.net (7.1.026) id 432E7DD700485F11 for freebsd-current@freebsd.org; Tue, 11 Oct 2005 15:43:52 +0200 Message-ID: <434BC199.40004@free.fr> Date: Tue, 11 Oct 2005 15:43:53 +0200 From: gwenj User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 Oct 2005 13:47:57 +0000 Subject: sagem fast 800+PPPoA on freebsd6 Beta 5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:43:54 -0000 Hello, I wish to use the sagem fast 800, but it's impossible to connect this modem. I've already modified the driver ueagle 1.5 for compiling, installing them and using without kernel panic. But in /var/log/ppp.log it's said : Warning : Cannot exec "PPPoA:ueagle0:8.35" : No such file or directory. It's true ueagle0 doesn't exist in /dev. I'm newbie in module developement and I need information and help for this work Thank you very much PS: for send me email you must delete -pas-de-spam from my address From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:46:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 215D916A42D for ; Tue, 11 Oct 2005 13:46:36 +0000 (GMT) (envelope-from gwenj@free.fr) Received: from mail.libertysurf.net (mx-out.tiscali.fr [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC68C43D7D for ; Tue, 11 Oct 2005 13:46:34 +0000 (GMT) (envelope-from gwenj@free.fr) Received: from [83.154.141.7] (83.154.141.7) by mail.libertysurf.net (7.1.026) id 432E7DD700486227 for freebsd-current@freebsd.org; Tue, 11 Oct 2005 15:46:34 +0200 Message-ID: <434BC23D.6080103@free.fr> Date: Tue, 11 Oct 2005 15:46:37 +0200 From: gwenj User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 Oct 2005 13:47:57 +0000 Subject: sagem fast 800+PPPoA on freebsd6 Beta 5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:46:36 -0000 Hello, I wish to use the sagem fast 800, but it's impossible to connect this modem. I've already modified the driver ueagle 1.5 for compiling, installing them and using without kernel panic. But in /var/log/ppp.log it's said : Warning : Cannot exec "PPPoA:ueagle0:8.35" : No such file or directory. It's true ueagle0 doesn't exist in /dev. I'm newbie in module developement and I need information and help for this work Thank you very much From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:54:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B3716A42B; Tue, 11 Oct 2005 13:54:19 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mxout.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id E769B43D5F; Tue, 11 Oct 2005 13:54:18 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (84-73-90-203.dclient.hispeed.ch [84.73.90.203]) (authenticated bits=0) by mxout.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with ESMTP id j9BDsDii012342; Tue, 11 Oct 2005 15:54:13 +0200 Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id 2C37C40522; Tue, 11 Oct 2005 15:54:13 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26770-05; Tue, 11 Oct 2005 15:54:07 +0200 (CEST) Received: from niobe.gwch.net (frodo.gwch.net [192.168.2.101]) by mail.gwch.net (Postfix) with ESMTP id 27710404D9; Tue, 11 Oct 2005 15:54:07 +0200 (CEST) From: Roger Grosswiler To: Jeremy Messenger In-Reply-To: References: <434BACCA.6030806@gwch.net> <1129034004.64291.10.camel@pav.hide.vol.cz> <434BB749.5000102@gwch.net> Content-Type: text/plain; charset=UTF-8 Date: Tue, 11 Oct 2005 15:54:03 +0200 Message-Id: <1129038843.1369.0.camel@niobe> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on smtp-02.tornado.cablecom.ch X-Virus-Scanned: amavisd-new at gwch.net X-Virus-Status: Clean X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics: smtp-02.tornado.cablecom.ch 32700; Body=4 Fuz1=4 Fuz2=4 Cc: freebsd-current@freebsd.org, pav@freebsd.org, freebsd-gnome@freebsd.org Subject: [SOLVED] Re: GNOME: Docklets not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 13:54:19 -0000 Am Dienstag, den 11.10.2005, 08:32 -0500 schrieb Jeremy Messenger: > Let's moving it to freebsd-gnome, so remove freebsd-current from CC. > > On Tue, 11 Oct 2005 07:59:53 -0500, Roger Grosswiler > wrote: > > > Pav Lucistnik wrote: > >> Roger Grosswiler píše v út 11. 10. 2005 v 14:15 +0200: > >> > >>> Hey, > >>> > >>> Have 6.0/B5 up and running. But running apps such as gaim, psi or > >>> others, that use docklets under gnome do not work. > >>> > >>> if i "close" the app, this terminates instead of minimizes the > >>> application. > >>> > >>> Is there something special to follow? > >> What do you mean by "docklet"? That's nonexistant term. > >> How is this related to running -CURRENT? > >> > > Definition of a Docklet: > > http://developer.gnome.org/doc/API/panel/r1373.html > > It looks like it's GNOME1, so it's what you are using? You need to show us > your pkg_info. If you are using GNOME2, then right click on the panel and > click on 'add to panel' to add 'Notification Area Applet'. > > BTW: There is no 'docklet' term in GNOME2 that I know. > > Cheers, > Mezz > > > Related tu running -CURRENT: state working in Linux (has not been tested > > in FreeBSD 5.4) > > > > Roger > > in fact, notification area was the resolution. thanks, roger From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 14:02:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C16416A428 for ; Tue, 11 Oct 2005 14:02:52 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E91443D64 for ; Tue, 11 Oct 2005 14:02:47 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9BE2jab020080; Wed, 12 Oct 2005 00:02:45 +1000 Received: from dirk.no.domain (ppp2DF0.dyn.pacific.net.au [61.8.45.240]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9BE2iMX003940; Wed, 12 Oct 2005 00:02:44 +1000 Date: Wed, 12 Oct 2005 00:03:32 +1000 From: Sam Lawrance To: Sam Lawrance Message-ID: <20051012000332.1398e596@dirk.no.domain> In-Reply-To: <20051011234614.20c838a1@dirk.no.domain> References: <20051011234614.20c838a1@dirk.no.domain> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: more usb keyboard (and mouse) troubles with 6.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 14:02:52 -0000 On Tue, 11 Oct 2005 23:46:14 +1000 Sam Lawrance wrote: > FreeBSD dirk.no.domain 6.0-RC1 FreeBSD 6.0-RC1 #0: Tue Oct 11 15:51:46 > EST 2005 sam@dirk.no.domain:/usr/src/sys/i386/compile/GENERIC > i386 > > This one is interesting. > > I have two USB keyboard/mouse combination devices here: > > - An IBM (0x04b3) IBM Standard USB Keyboard (0x3001). > Mouse has 2 buttons + Z-dir. > - And a Belkin wireless which shows up as something generic > (vendor 0x05fe device 0x1010). Mouse has 5 buttons + Z-dir. > > The IBM setup works fine. No troubles in console or X, both kbd and > mouse work as expected. > > The Belkin setup works OK initially. But as soon as I move the mouse, > all keyboard and mouse input is locked up. The system is not frozen - > if I reboot, run top and repeat, it continues to run and shows > nothing ominous. The result is the same in console or X. BTW, looks like a similar problem was reported in http://www.freebsd.org/cgi/query-pr.cgi?pr=85972. The submitter has a logitech wireless keyboard, but the report seems to be distinct from other recent reports and mumblings about logitech wireless stuff not working). From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 14:36:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF2CA16A449; Tue, 11 Oct 2005 14:36:56 +0000 (GMT) (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 A94B643DA0; Tue, 11 Oct 2005 14:36:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9BEaTCw051072; Tue, 11 Oct 2005 08:36:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434BCDF6.3090303@samsco.org> Date: Tue, 11 Oct 2005 08:36:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Subject: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 14:36:57 -0000 Announcement ------------ The release engineering team is proud to announce the availability of FreeBSD 6.0. We encourage everyone to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6_0 Problem reports can be submitted using the send-pr(1) command. This will likely be the last release candidate before the final release of FreeBSD 6.0. Known Issues ------------ The following issues are known and will be fixed before the release: - A late change in the aac(4) driver may result in the driver failing on some Dell systems. - Some systems with only USB keyboards might loose keyboard input. - Some laptops with certain IDE controllers may crash on bootup. - The QEMU and VMWare packages are known to expose problems in the IDE CDROM driver during OS install. - System lock ups may occur under extreme filesystem activity or with active filesystem snapshots. Availability ------------ Install distribution sets and ISO images are available for from ftp://ftp.freebsd.org as well as most FreeBSD mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html ISO images for sparc64 are not available yet but will be made available soon. Also, the release engineering team will switch from using MD5 to SHA256 checksums in the future. Until the switch is fully made, we will be providing both types of checksums. MD5: MD5 (6.0-RC1-alpha-bootonly.iso) = 362193d00cd931f6dc7ac68d0527089f MD5 (6.0-RC1-alpha-disc1.iso) = 7f9f9f4a6fe22515aadf4d718e04976c MD5 (6.0-RC1-amd64-bootonly.iso) = ea1b6e768a366856c09d3b9d3af4041b MD5 (6.0-RC1-amd64-disc1.iso) = c75501d2797c161b1888cb960deff269 MD5 (6.0-RC1-amd64-disc2.iso) = e21e3f9f6b1cf22786559169cbe1f5f7 MD5 (6.0-RC1-i386-bootonly.iso) = 1a26bc2f9f516cb309f1ff9a7480ff09 MD5 (6.0-RC1-i386-disc1.iso) = 2dd00155814fa3bbf4fa7d4ff26357ad MD5 (6.0-RC1-i386-disc2.iso) = b0c1a42ba384f615d90f5c2efd76d114 MD5 (6.0-RC1-ia64-bootonly.iso) = 55ce77c6d43aa15328ca20e5d58d365b MD5 (6.0-RC1-ia64-disc1.iso) = 2557c76f407eb8b9fcece243c1507bda MD5 (6.0-RC1-ia64-disc2.iso) = c04084bf5d21e4c3aec003700385246f MD5 (6.0-RC1-ia64-livefs.iso) = 5c5f298febc50226fba4bad3c049a917 MD5 (6.0-RC1-pc98-disc1.iso) = 0df5c0d86fc11c09c913e20e25a47c09 SHA256: SHA256 (6.0-RC1-amd64-bootonly.iso) = a4853ceb04c0f0bd634b4e078828669552890bdac0ff550cf110f5f077f81220 SHA256 (6.0-RC1-amd64-disc1.iso) = 922cbd9cd46e2637c288c3e442bf24c320dcc432d1e65df850991cf3317d22b7 SHA256 (6.0-RC1-amd64-disc2.iso) = c5a7d502d7e29c6a4c9db12091f56ed6b99ab1c217e23b7361bae306b4b1e521 SHA256 (6.0-RC1-i386-bootonly.iso) = a0f26a37e5e24c4ba9b69cdd209491c20d8b9c049fd3a2a35796bafd9321d8b1 SHA256 (6.0-RC1-i386-disc1.iso) = 2ff78e197177ac7992793805d8a8a45510466a00b839e0f7c59fe3e16505db00 SHA256 (6.0-RC1-i386-disc2.iso) = 5d82fdcf38768d8351bbcbd32bebc9c50a85a6b5669759fad3beb2f4c5e90c91 SHA256 (6.0-RC1-ia64-bootonly.iso) = 088f31b5ba08f65cf68c5f2b9623cc75475ccf9e8527edda92951a344f0849b2 SHA256 (6.0-RC1-ia64-disc1.iso) = 59a9f6c9b9d51e280896789fab5dc97ef45b61294dc9d68382ac572a187e6199 SHA256 (6.0-RC1-ia64-disc2.iso) = 6eed6817554be253c50a7c9b7a8be8942f00d9d41b96ba43fdc9c92228e3fdb9 SHA256 (6.0-RC1-ia64-livefs.iso) = c51617ab7328f69221cd7b9119d40dd9644e8aa3d69066cc7abbb38b64304963 SHA256 (6.0-RC1-pc98-disc1.iso) = 31838e7f656e098c206fe7995bbdcbcedf5ac9dbd379605ada1c1741498cce35 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 15:23:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9469A16A426 for ; Tue, 11 Oct 2005 15:23:26 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.76.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ACB243D5A for ; Tue, 11 Oct 2005 15:23:26 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from [192.168.1.109] (pcp0011002249pcs.longhl01.md.comcast.net[68.55.192.50]) by comcast.net (sccrmhc11) with ESMTP id <20051011152324011009a7f2e>; Tue, 11 Oct 2005 15:23:25 +0000 From: Derrick Edwards To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2005 11:23:34 -0400 User-Agent: KMail/1.8.2 References: <200510111203.j9BC31nj098194@lurza.secnetix.de> In-Reply-To: <200510111203.j9BC31nj098194@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510111123.35565.dantavious@comcast.net> Cc: Oliver Fromme Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 15:23:26 -0000 On Tuesday 11 October 2005 08:03, Oliver Fromme wrote: Thanks for the responce. I have CFLAGS= -O2 -pipe -funroll-loops in /etc/make.conf Would this do any damage? I have been using this for a long time now. Derrick > [broken quoting fixed] > > Derrick Edwards wrote: > > On Tuesday 11 October 2005 06:16, Uwe Laverenz wrote: > > > On Thu, Oct 06, 2005 at 05:43:25PM +0200, Mika wrote: > > > > has anyone have the problem that firefox dies spontaneously ? I get > > > > this > > > > > > I have the same problem with Mozilla since I switched from RELENG_5 to > > > RELENG_6. I've rebuilt all my ports completely but it keeps crashing > > > from time to time. This can happen after hours or after a few minutes, > > > mostly when klicking a link. > > > > I am seeing the same thing also. I updated my /etc/libmap.conf for > > FreeBSD 6. I recompiled Firefox also. When I go to nfl.com, firefox > > dies. > > Do you happen to have any unusual settings in your > /etc/make.conf file? Particularly CFLAGS? > > Best regards > Oliver From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 16:07:16 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 973E416A42F; Tue, 11 Oct 2005 16:07:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8A743D48; Tue, 11 Oct 2005 16:07:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9BG7FiN002926; Tue, 11 Oct 2005 09:07:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9BG7FgR002925; Tue, 11 Oct 2005 09:07:15 -0700 Date: Tue, 11 Oct 2005 09:07:15 -0700 From: Brooks Davis To: Pawel Jakub Dawidek Message-ID: <20051011160715.GA2264@odin.ac.hmc.edu> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051011064014.GA76710@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20051011064014.GA76710@garage.freebsd.pl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Brooks Davis , FreeBSD Current , Andrew Thompson Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 16:07:16 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2005 at 08:41:16AM +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 05, 2005 at 01:55:15PM -0700, Brooks Davis wrote: > +> On Wed, Oct 05, 2005 at 10:36:39PM +0200, Pawel Jakub Dawidek wrote: > +> > On Wed, Oct 05, 2005 at 03:49:03PM +1300, Andrew Thompson wrote: > +> > +> Hi, > +> > +>=20 > +> > +> I have found a repeatable panic with network device cloning, unfo= rtunatly I am > +> > +> unable to dump on this box. This is sparc64 with a 2 day old curr= ent. > +> >=20 > +> > The order is wrong in vlan_modevent(). > +> >=20 > +> > if_clone_detach() is freeing ifc_units field, so ifc_free_unit() sho= uld not > +> > be called after that. > +> >=20 > +> > This patch should fix the problem: > +> >=20 > +> > http://people.freebsd.org/~pjd/patches/if_vlan.c.patch > +>=20 > +> Yes. This does introduce a race in that a new interface could > +> be created between the vlan_clone_destroy loop and the call to > +> if_clone_detach. It's going to be hard to trigger, but it probably > +> should be fixed. Since cloning isn't performance critical, I think > +> adding a dead flag to the clone structure and failing all attempts once > +> the flag is set. >=20 > I think it is a low-risk patch and the race isn't really critical. > What do you guys think about going with this fix for 6.0? > I'm all for better fix (the one thompsa@ is working on) going to HEAD > and 6.1, but better fix - higher risk. > So what's your opinion? >=20 > Or maybe we will be able to create low-risk complete fix? The race is mostly a non-issue so I'd be OK with the low-risk fix. To hit the race you'd have to be trying (or forget that you are running some sort of interface management daemon). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDS+MyXY6L6fI4GtQRAvY4AKCSq9kBz4+X42rna8XNSUvg/oXokACghTDP yqIVOFyo0fCnytwAu9/FaZ8= =NFiy -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 16:40:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E54F116A41F for ; Tue, 11 Oct 2005 16:40:55 +0000 (GMT) (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 6BB2B43D4C for ; Tue, 11 Oct 2005 16:40:55 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EPN6T-0003Lr-RY for freebsd-current@freebsd.org; Tue, 11 Oct 2005 18:35:49 +0200 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Oct 2005 18:35:49 +0200 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Oct 2005 18:35:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Joshua Coombs" Date: Tue, 11 Oct 2005 12:33:01 -0400 Lines: 5 Message-ID: References: <434BCDF6.3090303@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: news Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 16:40:56 -0000 Given that we're in the RC stage, is it too late to get a PR stuffed in to correct ntpd/ntpdate behavior in /etc/rc.d? Joshua Coombs From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 16:47:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE7D616A420 for ; Tue, 11 Oct 2005 16:47:19 +0000 (GMT) (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 3928843D46 for ; Tue, 11 Oct 2005 16:47:19 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9BGlImL051759; Tue, 11 Oct 2005 10:47:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434BEC96.4050801@samsco.org> Date: Tue, 11 Oct 2005 10:47:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Coombs References: <434BCDF6.3090303@samsco.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 16:47:19 -0000 Joshua Coombs wrote: > Given that we're in the RC stage, is it too late to get a PR stuffed in > to correct ntpd/ntpdate behavior in /etc/rc.d? > > Joshua Coombs > Depends on the kind of problem that you are seeing. Any details? Scott From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:28:20 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAFA616A420 for ; Tue, 11 Oct 2005 17:28:20 +0000 (GMT) (envelope-from mnag@FreeBSD.org) Received: from mail.grupos.com.br (mail.grupos.com.br [200.203.183.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F67843D53 for ; Tue, 11 Oct 2005 17:28:20 +0000 (GMT) (envelope-from mnag@FreeBSD.org) Received: from corp.grupos.com.br (unknown [150.162.166.55]) by mail.grupos.com.br (Postfix) with ESMTP id 935B911E161 for ; Tue, 11 Oct 2005 14:28:15 -0300 (BRT) Received: from [150.162.166.51] (unknown [150.162.166.51]) by corp.grupos.com.br (Postfix) with ESMTP id 70A745501 for ; Tue, 11 Oct 2005 14:28:15 -0300 (BRT) Message-ID: <434BF62F.5010201@FreeBSD.org> Date: Tue, 11 Oct 2005 14:28:15 -0300 From: Marcus Alves Grando User-Agent: Thunderbird 1.4.1 (X11/20051010) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: "failed to enable memory mapping!" problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 17:28:20 -0000 Hi List, "failed to enable memory mapping!" is a problem or not? # uname -r 6.0-RC1 dmesg -v output: http://marcus.grupos.com.br:8080/dmesg.log Regards -- Marcus Alves Grando marcus(at)corp.grupos.com.br | Grupos Internet S/A mnag(at)FreeBSD.org | FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:45:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED8416A41F for ; Tue, 11 Oct 2005 17:45:54 +0000 (GMT) (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 B85E143D45 for ; Tue, 11 Oct 2005 17:45:53 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EPO8Y-0001xH-SY for freebsd-current@freebsd.org; Tue, 11 Oct 2005 19:42:03 +0200 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Oct 2005 19:42:02 +0200 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Oct 2005 19:42:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Joshua Coombs" Date: Tue, 11 Oct 2005 13:39:10 -0400 Lines: 56 Message-ID: References: <434BCDF6.3090303@samsco.org> <434BEC96.4050801@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: news Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 17:45:54 -0000 "Scott Long" wrote in message news:434BEC96.4050801@samsco.org... > Joshua Coombs wrote: > >> Given that we're in the RC stage, is it too late to get a PR >> stuffed in to correct ntpd/ntpdate behavior in /etc/rc.d? >> >> Joshua Coombs >> > > Depends on the kind of problem that you are seeing. Any details? > > Scott Two issues I spotted. First, ntpdate is still being used, despite it being marked as depreciated for quite some time. The preferred replacement is to call ntpd with the -q switch. This causes ntpd to match ntpdate's behavior, it sets the time, and then exits with a status code indicating success or failure. Second, when ntpdate, or what ever is set in ntpdate_program is called, there is an IP appended to the end of the arguments, which is not controlled by ntpdate_flags. This means you cannot setup ntpd -q to be used in place of ntpdate without editing the ntpdate rc.d script or creating a new one, a regression from 4.x's setup. I see some effort was put into the new ntpdate rc.d script, having it pull potential servers from /etc/ntp.conf rather than require the user specify one in rc.conf using ntpdate_flags. ntpd called with -q uses the ntp.conf server entries automatically, so the extra work by the rc.d script isn't required if we switch to ntpd -q in place of ntpdate. I was going to work up a tweaked ntpdate rc.d script that included a new option, ntpdate_use_ntpd, that when set, would use the preferred practice of calling ntpd -q after verifying a valid ntp.conf exists. If one isn't present, I was going to have it throw a warning, and reference an example conf using pool.ntp.org servers to get baseline time established. The ntpd rc.d script would receive the same check, the example conf would lock ntpd down such that it would only operate as a client for the local machine, and not act as a server for external hosts, or respond to external ntp query/command/conf requests. Unfortunately, I'm getting into this rather late, I just moved my 386 to 6.0b5 this weekend, hence my tardiness discovering ntpdate still in use in later releases of FreeBSD. I would like to see the correct behavior implemented for release, but if I'm beyond the deadline for this level of change, I'll accept that and work on making it the norm for 6.1. Joshua Coombs From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:49:39 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6178616A41F for ; Tue, 11 Oct 2005 17:49:39 +0000 (GMT) (envelope-from scottro@nyc.rr.com) Received: from mail.starlofashions.com (mail.starlofashions.com [12.44.50.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD17243D48 for ; Tue, 11 Oct 2005 17:49:38 +0000 (GMT) (envelope-from scottro@nyc.rr.com) Received: from nyserve3.starlofashions.com ([192.0.0.230]) by mail.starlofashions.com (8.9.3/8.9.3) with ESMTP id NAA14891 for ; Tue, 11 Oct 2005 13:49:02 -0400 Received: from uws1.starlofashions.com (uws1.starlofashions.com [192.168.1.230]) by nyserve3.starlofashions.com (Postfix) with SMTP id 55A6E60FB for ; Tue, 11 Oct 2005 13:49:02 -0400 (EDT) Received: by uws1.starlofashions.com (sSMTP sendmail emulation); Tue, 11 Oct 2005 13:49:02 -0400 Date: Tue, 11 Oct 2005 13:49:02 -0400 From: Scott Robbins To: freebsd-current@FreeBSD.ORG Message-ID: <20051011174902.GC91474@uws1.starlofashions.com> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <200510110741.49953.dantavious@comcast.net> <200510111203.j9BC31nj098194@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200510111203.j9BC31nj098194@lurza.secnetix.de> User-Agent: mutt-ng/devel-r535 (FreeBSD) Cc: Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 17:49:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 11, 2005 at 02:03:01PM +0200, Oliver Fromme wrote: > [broken quoting fixed] > > Derrick Edwards wrote: > > On Tuesday 11 October 2005 06:16, Uwe Laverenz wrote: > > > On Thu, Oct 06, 2005 at 05:43:25PM +0200, Mika wrote: > > > > has anyone have the problem that firefox dies spontaneously ? I get this > > > > > > I have the same problem with Mozilla since I switched from RELENG_5 to > > > RELENG_6. I've rebuilt all my ports completely but it keeps crashing > > > from time to time. This can happen after hours or after a few minutes, > > > mostly when klicking a link. > > > > I am seeing the same thing also. I updated my /etc/libmap.conf for FreeBSD 6. > > I recompiled Firefox also. When I go to nfl.com, firefox dies. > > Do you happen to have any unusual settings in your > /etc/make.conf file? Particularly CFLAGS? One thing--I have been guilty of this too--on nfl.com does it die as in crash or die as in freeze? I find that native firefox will freeze on some flash heavy sites (this thread's come up on forums from time to time.) espn.com is one, tvguide.com when one tries to view the description of a particular show's listing is another. (The same holds for mozilla and epiphany and no doubt any others using gecko). They don't crash as in close, leaving a .core file--they simply freeze completely, not responding to keyboard or mouse. - -- Scott GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: I have my pride. Okay, so I don't have a *lot* of my pride, but I have enough so that I can't do this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDS/sO+lTVdes0Z9YRAqvgAKCbVVAaIUE0Vv41rqzsenqQOw8SHACfeNzh quD/74u8Zw/mei+slzbxBFw= =8Rrd -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:59:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7145A16A41F for ; Tue, 11 Oct 2005 17:59:46 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 95CB343D55 for ; Tue, 11 Oct 2005 17:59:45 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 11 Oct 2005 17:33:01 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp031) with SMTP; 11 Oct 2005 19:33:01 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2005 19:32:32 +0200 User-Agent: KMail/1.8.1 X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Message-Id: <200510111932.50224@harrymail> Content-Type: multipart/signed; boundary="nextPart3320351.WGJmCM0FJv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: nss_ldap segmentation fault with 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, 11 Oct 2005 17:59:46 -0000 --nextPart3320351.WGJmCM0FJv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I set up ldap authentication against (MS)AD-Server and see segmentation=20 faults of `id user-xy` for example. The strange thing is that if I fire id for the first time it works, but=20 then it segfaults. The cause is the following line in /etc/nsswitch.conf:=20 "group: file ldap". As soon as I add ldap I can't su anymore because=20 nss_ldap.so seems to crash. If I remove the group ldap directive (and=20 leave shells and passwd with ldap) everything is working fine again. How can I provide useful info to get this fixed? Thanks, =2DHarry --nextPart3320351.WGJmCM0FJv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDS/dCBylq0S4AzzwRAon8AJ9jxE+LDh2upqkDfYzweL7kXQMrWgCfV9Uo SVboODUY/ybstRF5fNBL+6o= =DY0/ -----END PGP SIGNATURE----- --nextPart3320351.WGJmCM0FJv-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:02:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0087916A420 for ; Tue, 11 Oct 2005 18:02:10 +0000 (GMT) (envelope-from murcielako@yahoo.com) Received: from web50101.mail.yahoo.com (web50101.mail.yahoo.com [206.190.38.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 80C4B43D4C for ; Tue, 11 Oct 2005 18:02:10 +0000 (GMT) (envelope-from murcielako@yahoo.com) Received: (qmail 56320 invoked by uid 60001); 11 Oct 2005 18:02:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Z2+oaJ5LGq18paZoXqVUPzR9LZ6PX5PK0lo8OiJx7EzrZ2mkegPUcviYZTv99z1quV9Kayh03LXah2uAQOwnDvv97QJG7ItgolCuH/VrxT0qk8rZ0BnUNWgvIIwb0KtzSiUacjFnt7h7D+rdI3Ii2VOwLDoNFsltgIv4hiXLPXQ= ; Message-ID: <20051011180206.56318.qmail@web50101.mail.yahoo.com> Received: from [200.116.162.73] by web50101.mail.yahoo.com via HTTP; Tue, 11 Oct 2005 13:02:05 CDT Date: Tue, 11 Oct 2005 13:02:05 -0500 (CDT) From: "Jorge Mario G. Mazo" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: 6-0-RC1 keeps failing on radeondrm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 18:02:11 -0000 hi there in 5.4 radeondrm was working properly since my switch to 6-BETAX and now RC1 make buildkernel keeps failing on radeondrm. here is the log. I have tested it in 3 diff machines! and same problem! ... cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror vers.c linking kernel r300_cmdbuf.o(.text+0x19): In function `r300_emit_cliprects': : undefined reference to `drm_debug_flag' r300_cmdbuf.o(.text+0x866): In function `r300_do_cp_cmdbuf': : undefined reference to `drm_debug_flag' r300_cmdbuf.o(.text+0xb80): In function `r300_do_cp_cmdbuf': : undefined reference to `drm_debug_flag' r300_cmdbuf.o(.text+0xc3b): In function `r300_do_cp_cmdbuf': : undefined reference to `drm_debug_flag' r300_cmdbuf.o(.text+0xcd2): In function `r300_do_cp_cmdbuf': : undefined reference to `drm_debug_flag' r300_cmdbuf.o(.text+0xd5e): more undefined references to `drm_debug_flag' followradeon_cp.o(.text+0xc2e): In function `radeon_do_cleanup_cp': : undefined reference to `drm_ioremapfree' radeon_cp.o(.text+0xc59): In function `radeon_do_cleanup_cp': : undefined reference to `drm_ioremapfree' radeon_cp.o(.text+0xc93): In function `radeon_do_cleanup_cp': : undefined reference to `drm_ioremapfree' radeon_cp.o(.text+0xcb8): In function `radeon_do_cleanup_cp': : undefined reference to `drm_ati_pcigart_cleanup' radeon_cp.o(.text+0xce9): In function `radeon_do_cleanup_cp': : undefined reference to `drm_irq_uninstall' radeon_cp.o(.text+0xdcc): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0xe07): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0xe8b): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x10e8): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x11a7): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x11e3): In function `radeon_cp_init': : undefined reference to `drm_order' radeon_cp.o(.text+0x12d9): In function `radeon_cp_init': : undefined reference to `drm_ati_pcigart_init' radeon_cp.o(.text+0x1344): In function `radeon_cp_init': : undefined reference to `drm_ioremap' radeon_cp.o(.text+0x135f): In function `radeon_cp_init': : undefined reference to `drm_ioremap' radeon_cp.o(.text+0x137a): In function `radeon_cp_init': : undefined reference to `drm_ioremap' radeon_cp.o(.text+0x1402): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x1439): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x14a5): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x14e2): In function `radeon_cp_init': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x1620): In function `radeon_cp_start': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x16ac): more undefined references to `drm_debug_flag' follow radeon_cp.o(.text+0x2280): In function `radeon_preinit': : undefined reference to `drm_alloc' radeon_cp.o(.text+0x22c3): In function `radeon_preinit': : undefined reference to `drm_device_is_agp' radeon_cp.o(.text+0x22d9): In function `radeon_preinit': : undefined reference to `drm_device_is_pcie' radeon_cp.o(.text+0x22ed): In function `radeon_preinit': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x2363): In function `radeon_postcleanup': : undefined reference to `drm_debug_flag' radeon_cp.o(.text+0x238e): In function `radeon_postcleanup': : undefined reference to `drm_free' radeon_drv.o(.text+0x15): In function `radeon_probe': : undefined reference to `drm_probe' radeon_drv.o(.text+0xf8): In function `radeon_attach': : undefined reference to `drm_attach' radeon_drv.o(.data+0x48): undefined reference to `drm_devclass' radeon_drv.o(.data+0x94): undefined reference to `drm_detach' radeon_irq.o(.text+0x85): In function `radeon_driver_irq_handler': : undefined reference to `drm_vbl_send_signals' radeon_mem.o(.text+0x72): In function `radeon_mem_release': : undefined reference to `drm_free' radeon_mem.o(.text+0xb9): In function `radeon_mem_takedown': : undefined reference to `drm_free' radeon_mem.o(.text+0xd7): In function `radeon_mem_takedown': : undefined reference to `drm_free' radeon_mem.o(.text+0x252): In function `radeon_mem_alloc': : undefined reference to `drm_alloc' radeon_mem.o(.text+0x29c): In function `radeon_mem_alloc': : undefined reference to `drm_alloc' radeon_mem.o(.text+0x3ce): In function `radeon_mem_free': : undefined reference to `drm_free' radeon_mem.o(.text+0x3f5): In function `radeon_mem_free': : undefined reference to `drm_free' radeon_mem.o(.text+0x4a8): In function `radeon_mem_init_heap': : undefined reference to `drm_alloc' radeon_mem.o(.text+0x4c7): In function `radeon_mem_init_heap': : undefined reference to `drm_alloc' radeon_mem.o(.text+0x4e5): In function `radeon_mem_init_heap': : undefined reference to `drm_free' radeon_state.o(.text+0xf): In function `radeon_emit_state': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x45): In function `radeon_emit_state': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8f): In function `radeon_emit_state': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x581): In function `radeon_emit_state': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x65f): In function `radeon_emit_state': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8bc): more undefined references to `drm_debug_flag' follow radeon_state.o(.text+0x4732): In function `radeon_cp_vertex': : undefined reference to `drm_find_file_by_proc' radeon_state.o(.text+0x4759): In function `radeon_cp_vertex': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x4b81): In function `radeon_cp_indices': : undefined reference to `drm_find_file_by_proc' radeon_state.o(.text+0x4bc2): In function `radeon_cp_indices': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x5188): In function `radeon_cp_texture': : undefined reference to `drm_find_file_by_proc' radeon_state.o(.text+0x51b2): In function `radeon_cp_texture': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x5327): In function `radeon_cp_texture': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x5571): In function `radeon_cp_texture': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x55e3): In function `radeon_cp_texture': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x5b1f): In function `radeon_cp_texture': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x5c79): more undefined references to `drm_debug_flag' follow radeon_state.o(.text+0x62c9): In function `radeon_cp_vertex2': : undefined reference to `drm_find_file_by_proc' radeon_state.o(.text+0x6319): In function `radeon_cp_vertex2': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6929): In function `radeon_cp_cmdbuf': : undefined reference to `drm_find_file_by_proc' radeon_state.o(.text+0x6a06): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6aa0): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' radeon_state.o(.text+0x6aaa): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6b66): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6cdb): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6daf): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6e03): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x6f39): more undefined references to `drm_debug_flag' follow radeon_state.o(.text+0x71a1): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' radeon_state.o(.text+0x71cf): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7338): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x73b1): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7421): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7480): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7540): more undefined references to `drm_debug_flag' follow radeon_state.o(.text+0x75e2): In function `radeon_cp_cmdbuf': : undefined reference to `drm_alloc' radeon_state.o(.text+0x7694): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' radeon_state.o(.text+0x76ee): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x77be): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x78c0): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7a12): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7a67): In function `radeon_cp_cmdbuf': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x7dad): more undefined references to `drm_debug_flag' follow radeon_state.o(.text+0x85e4): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' radeon_state.o(.text+0x87c8): In function `radeon_cp_getparam': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x89c3): In function `radeon_cp_setparam': : undefined reference to `drm_find_file_by_proc' radeon_state.o(.text+0x8a15): In function `radeon_cp_setparam': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8a5b): In function `radeon_cp_setparam': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8acc): In function `radeon_cp_setparam': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8c46): In function `radeon_driver_prerelease': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8caf): In function `radeon_driver_open_helper': : undefined reference to `drm_debug_flag' radeon_state.o(.text+0x8cc7): In function `radeon_driver_open_helper': : undefined reference to `drm_alloc' radeon_state.o(.text+0x8d41): In function `radeon_driver_free_filp_priv': : undefined reference to `drm_free' *** Error code 1 Stop in /usr/obj/usr/src/sys/VERDE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ================================================================= Either write things worth reading, Or do things worth the writing. -Benjamin Franklin __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:08:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A08A116A41F for ; Tue, 11 Oct 2005 18:08:36 +0000 (GMT) (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 2980143D4C for ; Tue, 11 Oct 2005 18:08:35 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 8EC1ABC6D; Tue, 11 Oct 2005 18:08:33 +0000 (UTC) To: "Joshua Coombs" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 11 Oct 2005 13:39:10 EDT." Date: Tue, 11 Oct 2005 20:08:33 +0200 Message-ID: <23758.1129054113@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 18:08:36 -0000 In message , "Joshua Coombs" writes: > >"Scott Long" wrote in message >news:434BEC96.4050801@samsco.org... >> Joshua Coombs wrote: >> >>> Given that we're in the RC stage, is it too late to get a PR >>> stuffed in to correct ntpd/ntpdate behavior in /etc/rc.d? >>> >>> Joshua Coombs >>> >> >> Depends on the kind of problem that you are seeing. Any details? >> >> Scott > >Two issues I spotted. I'd vote that neither is urgent enough at this point in time. -- 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 Tue Oct 11 18:11:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE40F16A421; Tue, 11 Oct 2005 18:11:14 +0000 (GMT) (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 6312D43D46; Tue, 11 Oct 2005 18:11:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9BIBCb9065334; Tue, 11 Oct 2005 14:11:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9BIBDxK073876; Tue, 11 Oct 2005 14:11:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1AB7B7302F; Tue, 11 Oct 2005 14:11:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051011181113.1AB7B7302F@freebsd-current.sentex.ca> Date: Tue, 11 Oct 2005 14:11:13 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Tue, 11 Oct 2005 18:11:15 -0000 TB --- 2005-10-11 16:21:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-11 16:21:34 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-10-11 16:21:34 - cleaning the object tree TB --- 2005-10-11 16:22:13 - checking out the source tree TB --- 2005-10-11 16:22:13 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-10-11 16:22:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-11 16:28:55 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-11 16:28:55 - cd /src TB --- 2005-10-11 16:28:55 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-10-11 17:59:48 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-11 17:59:48 - cd /src TB --- 2005-10-11 17:59:48 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Oct 11 17:59:48 UTC 2005 >>> 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 -d -warn-common -r -d -o if_gre.ko.debug if_gre.o ip_gre.o touch export_syms awk -f /src/sys/modules/if_gre/../../conf/kmod_syms.awk if_gre.ko.debug export_syms | xargs -J% objcopy % if_gre.ko.debug objcopy --strip-debug if_gre.ko.debug if_gre.ko ===> if_ndis (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -fno-omit-frame-pointer -I/obj/amd64/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_detach': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:920: error: structure has no member named `ndis_mtx' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-11 18:11:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-11 18:11:12 - ERROR: failed to build generic kernel TB --- 2005-10-11 18:11:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:18:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AA8C16A41F for ; Tue, 11 Oct 2005 18:18:01 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA2DB43D45 for ; Tue, 11 Oct 2005 18:18:00 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9BIHxJ05570 for ; Tue, 11 Oct 2005 14:17:59 -0400 Message-ID: <434C01D2.4040003@savvis.net> Date: Tue, 11 Oct 2005 11:17:54 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: buildkernel is broken in if_ndis X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 18:18:01 -0000 dear hackers, make buildworld is broken for me. since NDIS_LOCK(sc) does not uses sc->ndis_mtx anymore, shouldn't the following patch be put in place? max p.s. i could not find KeIsInitializedSpinLock function in subr_ndis.c. quick look at msdn did not reveal it either --- if_ndis.c.orig Tue Oct 11 11:11:52 2005 +++ if_ndis.c Tue Oct 11 11:11:31 2005 @@ -917,8 +917,6 @@ driver_object *drv; sc = device_get_softc(dev); - KASSERT(mtx_initialized(&sc->ndis_mtx), - ("ndis mutex not initialized")); NDIS_LOCK(sc); ifp = sc->ifp; ifp->if_flags &= ~IFF_UP; From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:21:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECAB516A41F for ; Tue, 11 Oct 2005 19:21:29 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2585743D5A for ; Tue, 11 Oct 2005 19:21:28 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [208.206.151.59] (host59.gtisd.com[208.206.151.59]) by comcast.net (sccrmhc11) with ESMTP id <20051011192054011008ms7ne>; Tue, 11 Oct 2005 19:20:54 +0000 Message-ID: <434C1095.3060806@computer.org> Date: Tue, 11 Oct 2005 14:20:53 -0500 From: Eric Schuele User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jorge Mario G. Mazo" References: <20051011180206.56318.qmail@web50101.mail.yahoo.com> In-Reply-To: <20051011180206.56318.qmail@web50101.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: 6-0-RC1 keeps failing on radeondrm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 19:21:30 -0000 Jorge Mario G. Mazo wrote: > hi there > in 5.4 radeondrm was working properly since my switch > to 6-BETAX and now RC1 make buildkernel keeps failing > on radeondrm. here is the log. Do you have: device agp device drm device radeondrm in your kernel config file? > I have tested it in 3 diff machines! and same problem! > > ... > cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 > -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -std=c99 -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica > -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf > -I/usr/src/sys/contrib/dev/ath > -I/usr/src/sys/contrib/dev/ath/freebsd > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -ffreestanding -Werror vers.c > linking kernel > r300_cmdbuf.o(.text+0x19): In function > `r300_emit_cliprects': > : undefined reference to `drm_debug_flag' > r300_cmdbuf.o(.text+0x866): In function > `r300_do_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > r300_cmdbuf.o(.text+0xb80): In function > `r300_do_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > r300_cmdbuf.o(.text+0xc3b): In function > `r300_do_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > r300_cmdbuf.o(.text+0xcd2): In function > `r300_do_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > r300_cmdbuf.o(.text+0xd5e): more undefined references > to `drm_debug_flag' followradeon_cp.o(.text+0xc2e): In > function `radeon_do_cleanup_cp': > : undefined reference to `drm_ioremapfree' > radeon_cp.o(.text+0xc59): In function > `radeon_do_cleanup_cp': > : undefined reference to `drm_ioremapfree' > radeon_cp.o(.text+0xc93): In function > `radeon_do_cleanup_cp': > : undefined reference to `drm_ioremapfree' > radeon_cp.o(.text+0xcb8): In function > `radeon_do_cleanup_cp': > : undefined reference to `drm_ati_pcigart_cleanup' > radeon_cp.o(.text+0xce9): In function > `radeon_do_cleanup_cp': > : undefined reference to `drm_irq_uninstall' > radeon_cp.o(.text+0xdcc): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0xe07): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0xe8b): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x10e8): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x11a7): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x11e3): In function > `radeon_cp_init': > : undefined reference to `drm_order' > radeon_cp.o(.text+0x12d9): In function > `radeon_cp_init': > : undefined reference to `drm_ati_pcigart_init' > radeon_cp.o(.text+0x1344): In function > `radeon_cp_init': > : undefined reference to `drm_ioremap' > radeon_cp.o(.text+0x135f): In function > `radeon_cp_init': > : undefined reference to `drm_ioremap' > radeon_cp.o(.text+0x137a): In function > `radeon_cp_init': > : undefined reference to `drm_ioremap' > radeon_cp.o(.text+0x1402): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x1439): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x14a5): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x14e2): In function > `radeon_cp_init': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x1620): In function > `radeon_cp_start': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x16ac): more undefined references > to `drm_debug_flag' follow > radeon_cp.o(.text+0x2280): In function > `radeon_preinit': > : undefined reference to `drm_alloc' > radeon_cp.o(.text+0x22c3): In function > `radeon_preinit': > : undefined reference to `drm_device_is_agp' > radeon_cp.o(.text+0x22d9): In function > `radeon_preinit': > : undefined reference to `drm_device_is_pcie' > radeon_cp.o(.text+0x22ed): In function > `radeon_preinit': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x2363): In function > `radeon_postcleanup': > : undefined reference to `drm_debug_flag' > radeon_cp.o(.text+0x238e): In function > `radeon_postcleanup': > : undefined reference to `drm_free' > radeon_drv.o(.text+0x15): In function `radeon_probe': > : undefined reference to `drm_probe' > radeon_drv.o(.text+0xf8): In function `radeon_attach': > : undefined reference to `drm_attach' > radeon_drv.o(.data+0x48): undefined reference to > `drm_devclass' > radeon_drv.o(.data+0x94): undefined reference to > `drm_detach' > radeon_irq.o(.text+0x85): In function > `radeon_driver_irq_handler': > : undefined reference to `drm_vbl_send_signals' > radeon_mem.o(.text+0x72): In function > `radeon_mem_release': > : undefined reference to `drm_free' > radeon_mem.o(.text+0xb9): In function > `radeon_mem_takedown': > : undefined reference to `drm_free' > radeon_mem.o(.text+0xd7): In function > `radeon_mem_takedown': > : undefined reference to `drm_free' > radeon_mem.o(.text+0x252): In function > `radeon_mem_alloc': > : undefined reference to `drm_alloc' > radeon_mem.o(.text+0x29c): In function > `radeon_mem_alloc': > : undefined reference to `drm_alloc' > radeon_mem.o(.text+0x3ce): In function > `radeon_mem_free': > : undefined reference to `drm_free' > radeon_mem.o(.text+0x3f5): In function > `radeon_mem_free': > : undefined reference to `drm_free' > radeon_mem.o(.text+0x4a8): In function > `radeon_mem_init_heap': > : undefined reference to `drm_alloc' > radeon_mem.o(.text+0x4c7): In function > `radeon_mem_init_heap': > : undefined reference to `drm_alloc' > radeon_mem.o(.text+0x4e5): In function > `radeon_mem_init_heap': > : undefined reference to `drm_free' > radeon_state.o(.text+0xf): In function > `radeon_emit_state': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x45): In function > `radeon_emit_state': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8f): In function > `radeon_emit_state': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x581): In function > `radeon_emit_state': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x65f): In function > `radeon_emit_state': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8bc): more undefined references > to `drm_debug_flag' follow > radeon_state.o(.text+0x4732): In function > `radeon_cp_vertex': > : undefined reference to `drm_find_file_by_proc' > radeon_state.o(.text+0x4759): In function > `radeon_cp_vertex': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x4b81): In function > `radeon_cp_indices': > : undefined reference to `drm_find_file_by_proc' > radeon_state.o(.text+0x4bc2): In function > `radeon_cp_indices': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x5188): In function > `radeon_cp_texture': > : undefined reference to `drm_find_file_by_proc' > radeon_state.o(.text+0x51b2): In function > `radeon_cp_texture': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x5327): In function > `radeon_cp_texture': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x5571): In function > `radeon_cp_texture': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x55e3): In function > `radeon_cp_texture': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x5b1f): In function > `radeon_cp_texture': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x5c79): more undefined > references to `drm_debug_flag' follow > radeon_state.o(.text+0x62c9): In function > `radeon_cp_vertex2': > : undefined reference to `drm_find_file_by_proc' > radeon_state.o(.text+0x6319): In function > `radeon_cp_vertex2': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6929): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_find_file_by_proc' > radeon_state.o(.text+0x6a06): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6aa0): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_free' > radeon_state.o(.text+0x6aaa): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6b66): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6cdb): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6daf): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6e03): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x6f39): more undefined > references to `drm_debug_flag' follow > radeon_state.o(.text+0x71a1): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_free' > radeon_state.o(.text+0x71cf): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7338): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x73b1): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7421): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7480): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7540): more undefined > references to `drm_debug_flag' follow > radeon_state.o(.text+0x75e2): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_alloc' > radeon_state.o(.text+0x7694): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_free' > radeon_state.o(.text+0x76ee): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x77be): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x78c0): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7a12): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7a67): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x7dad): more undefined > references to `drm_debug_flag' follow > radeon_state.o(.text+0x85e4): In function > `radeon_cp_cmdbuf': > : undefined reference to `drm_free' > radeon_state.o(.text+0x87c8): In function > `radeon_cp_getparam': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x89c3): In function > `radeon_cp_setparam': > : undefined reference to `drm_find_file_by_proc' > radeon_state.o(.text+0x8a15): In function > `radeon_cp_setparam': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8a5b): In function > `radeon_cp_setparam': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8acc): In function > `radeon_cp_setparam': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8c46): In function > `radeon_driver_prerelease': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8caf): In function > `radeon_driver_open_helper': > : undefined reference to `drm_debug_flag' > radeon_state.o(.text+0x8cc7): In function > `radeon_driver_open_helper': > : undefined reference to `drm_alloc' > radeon_state.o(.text+0x8d41): In function > `radeon_driver_free_filp_priv': > : undefined reference to `drm_free' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/VERDE. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > ================================================================= > Either write things worth reading, Or do things worth the writing. > -Benjamin Franklin > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam ¡gratis! > Regístrate ya - http://correo.espanol.yahoo.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" > -- Regards, Eric From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:34:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D87C016A41F; Tue, 11 Oct 2005 19:34:13 +0000 (GMT) (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 7E1D943D60; Tue, 11 Oct 2005 19:34:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9BJYAm1078164; Tue, 11 Oct 2005 15:34:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9BJYBdq077627; Tue, 11 Oct 2005 15:34:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 61EB17302F; Tue, 11 Oct 2005 15:34:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051011193411.61EB17302F@freebsd-current.sentex.ca> Date: Tue, 11 Oct 2005 15:34:11 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Tue, 11 Oct 2005 19:34:14 -0000 TB --- 2005-10-11 18:11:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-11 18:11:13 - starting HEAD tinderbox run for i386/i386 TB --- 2005-10-11 18:11:13 - cleaning the object tree TB --- 2005-10-11 18:11:34 - checking out the source tree TB --- 2005-10-11 18:11:34 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-10-11 18:11:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-11 18:18:13 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-11 18:18:13 - cd /src TB --- 2005-10-11 18:18:13 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-11 19:21:55 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-11 19:21:55 - cd /src TB --- 2005-10-11 19:21:55 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Oct 11 19:21:55 UTC 2005 >>> 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 [...] touch export_syms awk -f /src/sys/modules/if_gre/../../conf/kmod_syms.awk if_gre.kld export_syms | xargs -J% objcopy % if_gre.kld ld -Bshareable -d -warn-common -o if_gre.ko.debug if_gre.kld objcopy --strip-debug if_gre.ko.debug if_gre.ko ===> if_ndis (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/obj/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_detach': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:920: error: structure has no member named `ndis_mtx' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-11 19:34:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-11 19:34:11 - ERROR: failed to build generic kernel TB --- 2005-10-11 19:34:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 20:54:51 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42FAC16A41F; Tue, 11 Oct 2005 20:54:51 +0000 (GMT) (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 DB25343D45; Tue, 11 Oct 2005 20:54:50 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9BKsnm3086089; Tue, 11 Oct 2005 16:54:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9BKsnIv083384; Tue, 11 Oct 2005 16:54:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AE84C7302F; Tue, 11 Oct 2005 16:54:49 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051011205449.AE84C7302F@freebsd-current.sentex.ca> Date: Tue, 11 Oct 2005 16:54:49 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Tue, 11 Oct 2005 20:54:51 -0000 TB --- 2005-10-11 19:34:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-11 19:34:11 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-10-11 19:34:11 - cleaning the object tree TB --- 2005-10-11 19:34:33 - checking out the source tree TB --- 2005-10-11 19:34:33 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-10-11 19:34:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-11 19:40:57 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-11 19:40:57 - cd /src TB --- 2005-10-11 19:40:57 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-11 20:44:48 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-11 20:44:48 - cd /src TB --- 2005-10-11 20:44:48 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Oct 11 20:44:48 UTC 2005 >>> 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 [...] touch export_syms awk -f /src/sys/modules/if_gre/../../conf/kmod_syms.awk if_gre.kld export_syms | xargs -J% objcopy % if_gre.kld ld -Bshareable -d -warn-common -o if_gre.ko.debug if_gre.kld objcopy --strip-debug if_gre.ko.debug if_gre.ko ===> if_ndis (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/obj/pc98/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function `ndis_detach': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:920: error: structure has no member named `ndis_mtx' *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-11 20:54:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-11 20:54:49 - ERROR: failed to build generic kernel TB --- 2005-10-11 20:54:49 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 20:56:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D73AB16A41F for ; Tue, 11 Oct 2005 20:56:32 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA5D843D62 for ; Tue, 11 Oct 2005 20:56:27 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9BKuQn1014660; Tue, 11 Oct 2005 13:56:27 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9BKuQ8v014659; Tue, 11 Oct 2005 13:56:26 -0700 Date: Tue, 11 Oct 2005 13:56:26 -0700 From: Brooks Davis To: Joshua Coombs Message-ID: <20051011205626.GA13461@odin.ac.hmc.edu> References: <434BCDF6.3090303@samsco.org> <434BEC96.4050801@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 20:56:33 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2005 at 01:39:10PM -0400, Joshua Coombs wrote: >=20 > "Scott Long" wrote in message=20 > news:434BEC96.4050801@samsco.org... > >Joshua Coombs wrote: > > > >>Given that we're in the RC stage, is it too late to get a PR=20 > >>stuffed in to correct ntpd/ntpdate behavior in /etc/rc.d? > >> > >>Joshua Coombs > >> > > > >Depends on the kind of problem that you are seeing. Any details? > > > >Scott >=20 > Two issues I spotted. >=20 > First, ntpdate is still being used, despite it being marked as=20 > depreciated for quite some time. The preferred replacement is to call=20 > ntpd with the -q switch. This causes ntpd to match ntpdate's=20 > behavior, it sets the time, and then exits with a status code=20 > indicating success or failure. >=20 > Second, when ntpdate, or what ever is set in ntpdate_program is=20 > called, there is an IP appended to the end of the arguments, which is=20 > not controlled by ntpdate_flags. This means you cannot setup ntpd -q=20 > to be used in place of ntpdate without editing the ntpdate rc.d script=20 > or creating a new one, a regression from 4.x's setup. >=20 > I see some effort was put into the new ntpdate rc.d script, having it=20 > pull potential servers from /etc/ntp.conf rather than require the user=20 > specify one in rc.conf using ntpdate_flags. ntpd called with -q uses=20 > the ntp.conf server entries automatically, so the extra work by the=20 > rc.d script isn't required if we switch to ntpd -q in place of=20 > ntpdate. >=20 > I was going to work up a tweaked ntpdate rc.d script that included a=20 > new option, ntpdate_use_ntpd, that when set, would use the preferred=20 > practice of calling ntpd -q after verifying a valid ntp.conf exists.=20 > If one isn't present, I was going to have it throw a warning, and=20 > reference an example conf using pool.ntp.org servers to get baseline=20 > time established. The ntpd rc.d script would receive the same check,=20 > the example conf would lock ntpd down such that it would only operate=20 > as a client for the local machine, and not act as a server for=20 > external hosts, or respond to external ntp query/command/conf=20 > requests. >=20 > Unfortunately, I'm getting into this rather late, I just moved my 386=20 > to 6.0b5 this weekend, hence my tardiness discovering ntpdate still in=20 > use in later releases of FreeBSD. I would like to see the correct=20 > behavior implemented for release, but if I'm beyond the deadline for=20 > this level of change, I'll accept that and work on making it the norm=20 > for 6.1. Since this is a matter of mostly pedantic correctness, I can't see risking the release on these changes. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTCb6XY6L6fI4GtQRApNQAJ9fNYj27SXEy6MH/RrkFPaNCSrVrwCg1GbQ MG7tlmaLhIpRR/DLnspJlxg= =p6GL -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:06:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2513C16A41F; Tue, 11 Oct 2005 21:06:09 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2143F43D45; Tue, 11 Oct 2005 21:06:06 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 01A061CCDD; Wed, 12 Oct 2005 10:06:02 +1300 (NZDT) Date: Wed, 12 Oct 2005 10:06:02 +1300 From: Andrew Thompson To: Brooks Davis Message-ID: <20051011210602.GA5714@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Brooks Davis , Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20051010202900.GA24213@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 21:06:09 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: > On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > > On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: > > > FWIW, I tried to look at the $subject problem since I had had it > > > before, but just got a different panic: > > > > > > Memory modified after free 0xc140b000(4092) val=deadc0dc @ 0xc140b000 > > > panic: Most recently used by clone > > > > > > The clone code seems to have decremented something (refcount?) twice > > > after freeing the memory chunk. > > > > I have been testing this patch and I think it fixes all the problems > > discussed. > > > > It changes refcounting to count the number of cloned interfaces so > > ifc_units is only freed when its safe. A new function has been added to > > decrement this when a simple cloner module is unloaded. The cloner is > > still detached first to prevent the race. > > > > In most cases the change is as simple as: > > I don't see any reason why you can't just replace the specific destroy > calls with calls to ifc_simple_destroy(). That would avoid expanding > the API. I have updated the patch and yes, its a nicer way to do it. Please review. Ive run through interations of create/kldunload with bridge, disc, faith, gif, gre and ppp with extra printf's and its freeing correctly. Andrew --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ifclone.diff" Index: contrib/pf/net/if_pflog.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pflog.c,v retrieving revision 1.15 diff -u -p -r1.15 if_pflog.c --- contrib/pf/net/if_pflog.c 9 Aug 2005 11:59:02 -0000 1.15 +++ contrib/pf/net/if_pflog.c 11 Oct 2005 19:19:06 -0000 @@ -370,7 +370,8 @@ pflog_modevent(module_t mod, int type, v case MOD_UNLOAD: if_clone_detach(&pflog_cloner); while (!LIST_EMPTY(&pflog_list)) - pflog_clone_destroy(SCP2IFP(LIST_FIRST(&pflog_list))); + ifc_simple_destroy(&pflog_cloner, + SCP2IFP(LIST_FIRST(&pflog_list))); break; default: Index: contrib/pf/net/if_pfsync.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pfsync.c,v retrieving revision 1.23 diff -u -p -r1.23 if_pfsync.c --- contrib/pf/net/if_pfsync.c 11 Sep 2005 11:55:39 -0000 1.23 +++ contrib/pf/net/if_pfsync.c 11 Oct 2005 19:19:15 -0000 @@ -1852,7 +1852,7 @@ pfsync_modevent(module_t mod, int type, case MOD_UNLOAD: if_clone_detach(&pfsync_cloner); while (!LIST_EMPTY(&pfsync_list)) - pfsync_clone_destroy( + ifc_simple_destroy(&pfsync_cloner, SCP2IFP(LIST_FIRST(&pfsync_list))); break; Index: net/if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.23 diff -u -p -r1.23 if_bridge.c --- net/if_bridge.c 2 Oct 2005 19:15:56 -0000 1.23 +++ net/if_bridge.c 11 Oct 2005 19:16:18 -0000 @@ -357,7 +357,8 @@ bridge_modevent(module_t mod, int type, case MOD_UNLOAD: if_clone_detach(&bridge_cloner); while (!LIST_EMPTY(&bridge_list)) - bridge_clone_destroy(LIST_FIRST(&bridge_list)->sc_ifp); + ifc_simple_destroy(&bridge_cloner, + LIST_FIRST(&bridge_list)->sc_ifp); uma_zdestroy(bridge_rtnode_zone); bridge_input_p = NULL; bridge_output_p = NULL; Index: net/if_clone.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_clone.c,v retrieving revision 1.6 diff -u -p -r1.6 if_clone.c --- net/if_clone.c 24 Feb 2005 13:14:41 -0000 1.6 +++ net/if_clone.c 11 Oct 2005 09:47:35 -0000 @@ -124,7 +124,6 @@ if_clone_create(char *name, size_t len) IF_CLONERS_LOCK(); LIST_FOREACH(ifc, &if_cloners, ifc_list) { if (ifc->ifc_match(ifc, name)) { - IF_CLONE_ADDREF(ifc); break; } } @@ -134,7 +133,6 @@ if_clone_create(char *name, size_t len) return (EINVAL); err = (*ifc->ifc_create)(ifc, name, len); - IF_CLONE_REMREF(ifc); return (err); } @@ -156,7 +154,6 @@ if_clone_destroy(const char *name) IF_CLONERS_LOCK(); LIST_FOREACH(ifc, &if_cloners, ifc_list) { if (strcmp(ifc->ifc_name, ifp->if_dname) == 0) { - IF_CLONE_ADDREF(ifc); break; } } @@ -172,7 +169,6 @@ if_clone_destroy(const char *name) err = (*ifc->ifc_destroy)(ifc, ifp); done: - IF_CLONE_REMREF(ifc); return (err); } @@ -224,6 +220,10 @@ if_clone_detach(struct if_clone *ifc) static void if_clone_free(struct if_clone *ifc) { + for (int bytoff = 0; bytoff < ifc->ifc_bmlen; bytoff++) { + KASSERT(ifc->ifc_units[bytoff] == 0x00, + ("ifc_units[%d] is not empty", bytoff)); + } IF_CLONE_LOCK_DESTROY(ifc); free(ifc->ifc_units, M_CLONE); @@ -352,7 +352,10 @@ ifc_alloc_unit(struct if_clone *ifc, int /* * Allocate the unit in the bitmap. */ + KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) == 0, + ("%s: bit is already set", __func__)); ifc->ifc_units[bytoff] |= (1 << bitoff); + IF_CLONE_ADDREF_LOCKED(ifc); done: IF_CLONE_UNLOCK(ifc); @@ -375,7 +378,7 @@ ifc_free_unit(struct if_clone *ifc, int KASSERT((ifc->ifc_units[bytoff] & (1 << bitoff)) != 0, ("%s: bit is already cleared", __func__)); ifc->ifc_units[bytoff] &= ~(1 << bitoff); - IF_CLONE_UNLOCK(ifc); + IF_CLONE_REMREF_LOCKED(ifc); /* releases lock */ } void Index: net/if_disc.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_disc.c,v retrieving revision 1.48 diff -u -p -r1.48 if_disc.c --- net/if_disc.c 26 Jun 2005 18:11:10 -0000 1.48 +++ net/if_disc.c 11 Oct 2005 19:17:03 -0000 @@ -111,17 +111,6 @@ disc_clone_create(struct if_clone *ifc, } static void -disc_destroy(struct disc_softc *sc) -{ - - bpfdetach(sc->sc_ifp); - if_detach(sc->sc_ifp); - if_free(sc->sc_ifp); - - free(sc, M_DISC); -} - -static void disc_clone_destroy(struct ifnet *ifp) { struct disc_softc *sc; @@ -131,7 +120,11 @@ disc_clone_destroy(struct ifnet *ifp) LIST_REMOVE(sc, sc_list); mtx_unlock(&disc_mtx); - disc_destroy(sc); + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + + free(sc, M_DISC); } static int @@ -150,9 +143,8 @@ disc_modevent(module_t mod, int type, vo mtx_lock(&disc_mtx); while ((sc = LIST_FIRST(&disc_softc_list)) != NULL) { - LIST_REMOVE(sc, sc_list); mtx_unlock(&disc_mtx); - disc_destroy(sc); + ifc_simple_destroy(&disc_cloner, sc->sc_ifp); mtx_lock(&disc_mtx); } mtx_unlock(&disc_mtx); Index: net/if_faith.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_faith.c,v retrieving revision 1.37 diff -u -p -r1.37 if_faith.c --- net/if_faith.c 9 Aug 2005 10:19:58 -0000 1.37 +++ net/if_faith.c 11 Oct 2005 19:17:45 -0000 @@ -103,7 +103,6 @@ static LIST_HEAD(, faith_softc) faith_so static int faith_clone_create(struct if_clone *, int); static void faith_clone_destroy(struct ifnet *); -static void faith_destroy(struct faith_softc *); IFC_SIMPLE_DECLARE(faith, 0); @@ -137,9 +136,8 @@ faithmodevent(mod, type, data) mtx_lock(&faith_mtx); while ((sc = LIST_FIRST(&faith_softc_list)) != NULL) { - LIST_REMOVE(sc, sc_list); mtx_unlock(&faith_mtx); - faith_destroy(sc); + ifc_simple_destroy(&faith_cloner, sc->sc_ifp); mtx_lock(&faith_mtx); } mtx_unlock(&faith_mtx); @@ -195,16 +193,6 @@ faith_clone_create(ifc, unit) } static void -faith_destroy(struct faith_softc *sc) -{ - - bpfdetach(sc->sc_ifp); - if_detach(sc->sc_ifp); - if_free(sc->sc_ifp); - free(sc, M_FAITH); -} - -static void faith_clone_destroy(ifp) struct ifnet *ifp; { @@ -214,7 +202,10 @@ faith_clone_destroy(ifp) LIST_REMOVE(sc, sc_list); mtx_unlock(&faith_mtx); - faith_destroy(sc); + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + free(sc, M_FAITH); } int Index: net/if_gif.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gif.c,v retrieving revision 1.54 diff -u -p -r1.54 if_gif.c --- net/if_gif.c 9 Aug 2005 10:19:58 -0000 1.54 +++ net/if_gif.c 11 Oct 2005 19:17:56 -0000 @@ -186,10 +186,15 @@ gifattach0(sc) } static void -gif_destroy(struct gif_softc *sc) +gif_clone_destroy(ifp) + struct ifnet *ifp; { - struct ifnet *ifp = GIF2IFP(sc); int err; + struct gif_softc *sc = ifp->if_softc; + + mtx_lock(&gif_mtx); + LIST_REMOVE(sc, gif_list); + mtx_unlock(&gif_mtx); gif_delete_tunnel(ifp); #ifdef INET6 @@ -214,18 +219,6 @@ gif_destroy(struct gif_softc *sc) free(sc, M_GIF); } -static void -gif_clone_destroy(ifp) - struct ifnet *ifp; -{ - struct gif_softc *sc = ifp->if_softc; - - mtx_lock(&gif_mtx); - LIST_REMOVE(sc, gif_list); - mtx_unlock(&gif_mtx); - gif_destroy(sc); -} - static int gifmodevent(mod, type, data) module_t mod; @@ -250,9 +243,8 @@ gifmodevent(mod, type, data) mtx_lock(&gif_mtx); while ((sc = LIST_FIRST(&gif_softc_list)) != NULL) { - LIST_REMOVE(sc, gif_list); mtx_unlock(&gif_mtx); - gif_destroy(sc); + ifc_simple_destroy(&gif_cloner, GIF2IFP(sc)); mtx_lock(&gif_mtx); } mtx_unlock(&gif_mtx); Index: net/if_gre.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gre.c,v retrieving revision 1.34 diff -u -p -r1.34 if_gre.c --- net/if_gre.c 9 Aug 2005 10:19:58 -0000 1.34 +++ net/if_gre.c 11 Oct 2005 19:18:08 -0000 @@ -202,20 +202,6 @@ gre_clone_create(ifc, unit) } static void -gre_destroy(struct gre_softc *sc) -{ - -#ifdef INET - if (sc->encap != NULL) - encap_detach(sc->encap); -#endif - bpfdetach(GRE2IFP(sc)); - if_detach(GRE2IFP(sc)); - if_free(GRE2IFP(sc)); - free(sc, M_GRE); -} - -static void gre_clone_destroy(ifp) struct ifnet *ifp; { @@ -224,7 +210,15 @@ gre_clone_destroy(ifp) mtx_lock(&gre_mtx); LIST_REMOVE(sc, sc_list); mtx_unlock(&gre_mtx); - gre_destroy(sc); + +#ifdef INET + if (sc->encap != NULL) + encap_detach(sc->encap); +#endif + bpfdetach(ifp); + if_detach(ifp); + if_free(ifp); + free(sc, M_GRE); } /* @@ -791,9 +785,8 @@ gremodevent(module_t mod, int type, void mtx_lock(&gre_mtx); while ((sc = LIST_FIRST(&gre_softc_list)) != NULL) { - LIST_REMOVE(sc, sc_list); mtx_unlock(&gre_mtx); - gre_destroy(sc); + ifc_simple_destroy(&gre_cloner, GRE2IFP(sc)); mtx_lock(&gre_mtx); } mtx_unlock(&gre_mtx); Index: net/if_ppp.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ppp.c,v retrieving revision 1.108 diff -u -p -r1.108 if_ppp.c --- net/if_ppp.c 19 Sep 2005 22:27:07 -0000 1.108 +++ net/if_ppp.c 11 Oct 2005 19:18:23 -0000 @@ -242,11 +242,15 @@ ppp_clone_create(struct if_clone *ifc, i } static void -ppp_destroy(struct ppp_softc *sc) +ppp_clone_destroy(struct ifnet *ifp) { - struct ifnet *ifp; + struct ppp_softc *sc; + + sc = ifp->if_softc; + PPP_LIST_LOCK(); + LIST_REMOVE(sc, sc_list); + PPP_LIST_UNLOCK(); - ifp = PPP2IFP(sc); bpfdetach(ifp); if_detach(ifp); if_free(ifp); @@ -256,18 +260,6 @@ ppp_destroy(struct ppp_softc *sc) free(sc, M_PPP); } -static void -ppp_clone_destroy(struct ifnet *ifp) -{ - struct ppp_softc *sc; - - sc = ifp->if_softc; - PPP_LIST_LOCK(); - LIST_REMOVE(sc, sc_list); - PPP_LIST_UNLOCK(); - ppp_destroy(sc); -} - static int ppp_modevent(module_t mod, int type, void *data) { @@ -296,9 +288,8 @@ ppp_modevent(module_t mod, int type, voi PPP_LIST_LOCK(); while ((sc = LIST_FIRST(&ppp_softc_list)) != NULL) { - LIST_REMOVE(sc, sc_list); PPP_LIST_UNLOCK(); - ppp_destroy(sc); + ifc_simple_destroy(&ppp_cloner, PPP2IFP(sc)); PPP_LIST_LOCK(); } PPP_LIST_LOCK_DESTROY(); Index: netinet/ip_carp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_carp.c,v retrieving revision 1.31 diff -u -p -r1.31 ip_carp.c --- netinet/ip_carp.c 9 Sep 2005 08:41:39 -0000 1.31 +++ netinet/ip_carp.c 11 Oct 2005 19:19:36 -0000 @@ -2144,7 +2144,8 @@ carp_modevent(module_t mod, int type, vo case MOD_UNLOAD: if_clone_detach(&carp_cloner); while (!LIST_EMPTY(&carpif_list)) - carp_clone_destroy(SC2IFP(LIST_FIRST(&carpif_list))); + ifc_simple_destroy(&carp_cloner, + SC2IFP(LIST_FIRST(&carpif_list))); mtx_destroy(&carp_mtx); break; --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:07:47 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F93816A420 for ; Tue, 11 Oct 2005 21:07:47 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F1D243D5E for ; Tue, 11 Oct 2005 21:07:43 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id j9BL73jo004442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Oct 2005 23:07:03 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id j9BL73uQ004441 for current@freebsd.org; Tue, 11 Oct 2005 23:07:03 +0200 (CEST) (envelope-from csaba) Date: Tue, 11 Oct 2005 23:07:03 +0200 From: Csaba Henk To: current@freebsd.org Message-ID: <20051011210703.GE2911@beastie.creo.hu> References: <434BCDF6.3090303@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434BCDF6.3090303@samsco.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 21:07:47 -0000 On Tue, Oct 11, 2005 at 08:36:38AM -0600, Scott Long wrote: > Known Issues > ------------ [ ... ] > - System lock ups may occur under extreme filesystem activity or with > active filesystem snapshots. Could someone give me a pointer what is this exactly? I wouldn't like to mistake a known kernel bug for my own beloved miserable fs code bugs. Csaba From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:16:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28B6C16A41F for ; Tue, 11 Oct 2005 21:16:28 +0000 (GMT) (envelope-from murcielako@yahoo.com) Received: from web50106.mail.yahoo.com (web50106.mail.yahoo.com [206.190.38.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E75643D60 for ; Tue, 11 Oct 2005 21:16:27 +0000 (GMT) (envelope-from murcielako@yahoo.com) Received: (qmail 5697 invoked by uid 60001); 11 Oct 2005 21:16:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JrHu975mphbXcK6mdyRUulsc3PBOh0OP6AkE/74T3FumeyXMYrS2vrxVcTznqjicFGEe8DiZ5Z1TWWl9fSrXwDpnk3S8ghDfaEWG1Nz2ZbiMm3/QXylWRar40+Ba5r4CZ7m90PtOI9i/0G+63ui8ITwSthV2ILkf8OeZyGj1d9Y= ; Message-ID: <20051011211626.5695.qmail@web50106.mail.yahoo.com> Received: from [200.116.162.73] by web50106.mail.yahoo.com via HTTP; Tue, 11 Oct 2005 16:16:26 CDT Date: Tue, 11 Oct 2005 16:16:26 -0500 (CDT) From: "Jorge Mario G. Mazo" To: Eric Schuele In-Reply-To: <434C1095.3060806@computer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: 6-0-RC1 keeps failing on radeondrm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 21:16:28 -0000 --- Eric Schuele escribió: > Jorge Mario G. Mazo wrote: > > hi there > > in 5.4 radeondrm was working properly since my > switch > > to 6-BETAX and now RC1 make buildkernel keeps > failing > > on radeondrm. here is the log. > > Do you have: > > device agp > device drm > device radeondrm > > in your kernel config file? hi there seems like device drm was the problem but I have never used that, since when was that introduced and where is documented? ================================================================= Either write things worth reading, Or do things worth the writing. -Benjamin Franklin __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:37:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6003216A41F for ; Tue, 11 Oct 2005 21:37:27 +0000 (GMT) (envelope-from kstewart@owt.com) Received: from smtp.owt.com (smtp.owt.com [204.118.6.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9D1943D45 for ; Tue, 11 Oct 2005 21:37:26 +0000 (GMT) (envelope-from kstewart@owt.com) Received: from topaz-out (owt-207-41-94-233.owt.com [207.41.94.233]) by smtp.owt.com (8.12.8/8.12.8) with ESMTP id j9BLbDSH031230; Tue, 11 Oct 2005 14:37:15 -0700 From: Kent Stewart To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2005 14:37:20 -0700 User-Agent: KMail/1.8.2 References: <200510110741.49953.dantavious@comcast.net> <200510111203.j9BC31nj098194@lurza.secnetix.de> <20051011174902.GC91474@uws1.starlofashions.com> In-Reply-To: <20051011174902.GC91474@uws1.starlofashions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510111437.20369.kstewart@owt.com> Cc: Scott Robbins Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 21:37:27 -0000 On Tuesday 11 October 2005 10:49 am, Scott Robbins wrote: > On Tue, Oct 11, 2005 at 02:03:01PM +0200, Oliver Fromme wrote: > > [broken quoting fixed] > > > > Derrick Edwards wrote: > > > On Tuesday 11 October 2005 06:16, Uwe Laverenz wrote: > > > > On Thu, Oct 06, 2005 at 05:43:25PM +0200, Mika wrote: > > > > > has anyone have the problem that firefox dies spontaneously > > > > > ? I get this > > > > > > > > I have the same problem with Mozilla since I switched from > > > > RELENG_5 to RELENG_6. I've rebuilt all my ports completely but > > > > it keeps crashing from time to time. This can happen after > > > > hours or after a few minutes, mostly when klicking a link. > > > > > > I am seeing the same thing also. I updated my /etc/libmap.conf > > > for FreeBSD 6. I recompiled Firefox also. When I go to nfl.com, > > > firefox dies. > > > > Do you happen to have any unusual settings in your > > /etc/make.conf file? Particularly CFLAGS? > > One thing--I have been guilty of this too--on nfl.com does it die as > in crash or die as in freeze? I find that native firefox will freeze > on some flash heavy sites (this thread's come up on forums from time > to time.) espn.com is one, tvguide.com when one tries to view the > description of a particular show's listing is another. (The same > holds for mozilla and epiphany and no doubt any others using gecko). > > They don't crash as in close, leaving a .core file--they simply > freeze completely, not responding to keyboard or mouse. I see the blink and it is gone even on 4-stable. I went there using Internet Explorer and it appears that my connection from Firefox to Realplayer is not functional. When it starts to bring up realplayer for the audio/video is when firefox seems to blink and go away. Konqueror will bring up the page but it won't do the nfl audio-video. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:38:02 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C07216A41F; Tue, 11 Oct 2005 21:38:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24A0943D48; Tue, 11 Oct 2005 21:38:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [70.30.70.180]) by elvis.mu.org (Postfix) with ESMTP id C5F321A3C25; Tue, 11 Oct 2005 14:38:01 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B2D6851334; Tue, 11 Oct 2005 17:38:00 -0400 (EDT) Date: Tue, 11 Oct 2005 17:38:00 -0400 From: Kris Kennaway To: current@FreeBSD.org, sparc64@FreeBSD.org Message-ID: <20051011213800.GA8839@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: des@FreeBSD.org Subject: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 21:38:02 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A few weeks ago I reported that bufinit() on sparc64 machines with >12GB of RAM goes into an infinite loop because of a 32-bit integer counter overflowing. On 5.x it was possible to work around this with the kern.maxbcache tunable, but this didn't work on 6.0 or above. It turns out the problem began here: ---- Revision 1.67 / (download) - annotate - [select for diffs], Mon Nov 8 18:20= :02 2004 UTC (11 months ago) by des Branch: MAIN Changes since 1.66: +17 -17 lines Diff to previous 1.66 (colored) #include instead of (the former includes the latter, but also declares variables which are defined in kern/subr_param.c). Change som VM parameters from quad_t to unsigned long. They refer to quantities (size limits for text, heap and stack segments) which must necessarily be smaller than the size of the address space, so long is adequate on all platforms. MFC after: 1 week ---- which contained: -int maxswzone; /* max swmeta KVA storage */ -int maxbcache; /* max buffer cache KVA storage */ +long maxswzone; /* max swmeta KVA storage */ +long maxbcache; /* max buffer cache KVA storage */ However, des forgot to change the other definition of maxbcache in : extern int maxbcache; /* Max KVA for buffer cache */ In fact, it's a good thing he didn't. On sparc64 if you make that variable a long it causes 32-bit integer overflows elsewhere, which lead to severe filesystem damage on systems with >12GB RAM. With the above bug this is reduced to a hang at boot. The hang is because maxbcache is not capped to a maximum value on sparc64, and a loop termination condition never occurs because of a 32-bit integer overflow. On amd64 it's capped to /* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. */ #ifndef VM_BCACHE_SIZE_MAX #define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) #endif so large-memory amd64 systems never see it. ia64 and ppc would also hang at boot with >12GB, I think. On 5.x, the same hang exists, but you can work around it with the tunable. This tunable was broken by the long/int mismatch on 6.0, so sparc64 systems with >12GB were unusable. This patch reverts the above int->long change, and adds definitions for VM_BCACHE_SIZE_MAX and VM_SWZONE_SIZE_MAX on sparc64 copied from amd64. Actually, they should probably be added on other architectures too (ia64, ppc). Can someone please review? Kris Index: kern/subr_param.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/sys/kern/subr_param.c,v retrieving revision 1.71 diff -u -r1.71 subr_param.c --- kern/subr_param.c 16 Apr 2005 15:07:41 -0000 1.71 +++ kern/subr_param.c 11 Oct 2005 21:09:01 -0000 @@ -75,8 +75,8 @@ int ncallout; /* maximum # of timer events */ int nbuf; int nswbuf; -long maxswzone; /* max swmeta KVA storage */ -long maxbcache; /* max buffer cache KVA storage */ +int maxswzone; /* max swmeta KVA storage */ +int maxbcache; /* max buffer cache KVA storage */ int maxpipekva; /* Limit on pipe KVA */ u_long maxtsiz; /* max text size */ u_long dfldsiz; /* initial data size limit */ @@ -106,11 +106,11 @@ #ifdef VM_SWZONE_SIZE_MAX maxswzone =3D VM_SWZONE_SIZE_MAX; #endif - TUNABLE_LONG_FETCH("kern.maxswzone", &maxswzone); + TUNABLE_INT_FETCH("kern.maxswzone", &maxswzone); #ifdef VM_BCACHE_SIZE_MAX maxbcache =3D VM_BCACHE_SIZE_MAX; #endif - TUNABLE_LONG_FETCH("kern.maxbcache", &maxbcache); + TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); =20 maxtsiz =3D MAXTSIZ; TUNABLE_ULONG_FETCH("kern.maxtsiz", &maxtsiz); Index: sparc64/include/param.h =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/sys/sparc64/include/param.h,v retrieving revision 1.19 diff -u -r1.19 param.h --- sparc64/include/param.h 20 Nov 2004 02:29:50 -0000 1.19 +++ sparc64/include/param.h 11 Oct 2005 20:54:30 -0000 @@ -110,6 +110,22 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ #define PCPU_PAGES 1 =20 +/* + * Ceiling on amount of swblock kva space, can be changed via + * the kern.maxswzone /boot/loader.conf variable. + */ +#ifndef VM_SWZONE_SIZE_MAX +#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) +#endif + +/* + * Ceiling on size of buffer cache (really only effects write queueing, + * the VM page cache is not effected), can be changed via + * the kern.maxbcache /boot/loader.conf variable. + */ +#ifndef VM_BCACHE_SIZE_MAX +#define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) +#endif =20 /* * Mach derived conversion macros Index: sparc64/include/vmparam.h =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/sys/sparc64/include/vmparam.h,v retrieving revision 1.14 diff -u -r1.14 vmparam.h --- sparc64/include/vmparam.h 27 Dec 2002 19:31:26 -0000 1.14 +++ sparc64/include/vmparam.h 11 Oct 2005 20:54:30 -0000 @@ -171,6 +171,13 @@ #endif =20 /* + * Ceiling on amount of kmem_map kva space. + */ +#ifndef VM_KMEM_SIZE_MAX +#define VM_KMEM_SIZE_MAX (400 * 1024 * 1024) +#endif + +/* * Initial pagein size of beginning of executable file. */ #ifndef VM_INITIAL_PAGEIN --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDTDC4Wry0BWjoQKURAkJgAKDIdrvK7BIwszOZzA4j4aIoLzxjlwCglEmc 0c949Eta0QRcZL2IGt8aNcg= =b4Eg -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:39:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E62BA16A421 for ; Tue, 11 Oct 2005 21:39:28 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26C0143D4C for ; Tue, 11 Oct 2005 21:39:28 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [208.206.151.59] (host59.gtisd.com[208.206.151.59]) by comcast.net (sccrmhc14) with ESMTP id <20051011213917014002ftr6e>; Tue, 11 Oct 2005 21:39:25 +0000 Message-ID: <434C3101.5090208@computer.org> Date: Tue, 11 Oct 2005 16:39:13 -0500 From: Eric Schuele User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jorge Mario G. Mazo" References: <20051011211626.5695.qmail@web50106.mail.yahoo.com> In-Reply-To: <20051011211626.5695.qmail@web50106.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: 6-0-RC1 keeps failing on radeondrm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 21:39:29 -0000 Jorge Mario G. Mazo wrote: > --- Eric Schuele escribió: > > >>Jorge Mario G. Mazo wrote: >> >>>hi there >>>in 5.4 radeondrm was working properly since my >> >>switch >> >>>to 6-BETAX and now RC1 make buildkernel keeps >> >>failing >> >>>on radeondrm. here is the log. >> >>Do you have: >> >>device agp >>device drm >>device radeondrm >> >>in your kernel config file? > > hi there > seems like device drm was the problem > but I have never used that, since when was that > introduced and where is documented? I think it showed up in releng_6. I don't recalll any other documentation other than inside NOTES. > > > > ================================================================= > Either write things worth reading, Or do things worth the writing. > -Benjamin Franklin > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam ¡gratis! > Regístrate ya - http://correo.espanol.yahoo.com/ > -- Regards, Eric From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:08:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7C2616A420; Tue, 11 Oct 2005 22:08:20 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id F22FF43D46; Tue, 11 Oct 2005 22:08:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9BM7nio026950; Tue, 11 Oct 2005 15:07:49 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9BM7nHi026949; Tue, 11 Oct 2005 15:07:49 -0700 Date: Tue, 11 Oct 2005 15:07:49 -0700 From: Brooks Davis To: Andrew Thompson , Brooks Davis , Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current Message-ID: <20051011220749.GD13461@odin.ac.hmc.edu> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> <20051011210602.GA5714@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LTeJQqWS0MN7I/qa" Content-Disposition: inline In-Reply-To: <20051011210602.GA5714@heff.fud.org.nz> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 22:08:21 -0000 --LTeJQqWS0MN7I/qa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 10:06:02AM +1300, Andrew Thompson wrote: > On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: > > On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > > > On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: > > > > FWIW, I tried to look at the $subject problem since I had had it > > > > before, but just got a different panic: > > > >=20 > > > > Memory modified after free 0xc140b000(4092) val=3Ddeadc0dc = @ 0xc140b000 > > > > panic: Most recently used by clone > > > >=20 > > > > The clone code seems to have decremented something (refcount?) twice > > > > after freeing the memory chunk. > > >=20 > > > I have been testing this patch and I think it fixes all the problems > > > discussed. > > >=20 > > > It changes refcounting to count the number of cloned interfaces so > > > ifc_units is only freed when its safe. A new function has been added = to > > > decrement this when a simple cloner module is unloaded. The cloner is > > > still detached first to prevent the race. > > >=20 > > > In most cases the change is as simple as: > >=20 > > I don't see any reason why you can't just replace the specific destroy > > calls with calls to ifc_simple_destroy(). That would avoid expanding > > the API. >=20 > I have updated the patch and yes, its a nicer way to do it. Please > review. >=20 > Ive run through interations of create/kldunload with bridge, disc, > faith, gif, gre and ppp with extra printf's and its freeing correctly. This looks good to me, thanks for working on this and doing the _destory removals. Let's see about getting this committed. Slightly longer term I think should consider hanging the interface list off the cloner or maybe off some more generic per driver struct so if_clone_detach() can destroy the interfaces and the unload code becomes a one-liner in most cases. The current code is a result of not wanting to mess with the drivers too much initially, but I think we need to start looking at moving more bits into the support code. After all, if we only write something once instead of once per interface, that's a lot less opportunities to screw up. :) -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --LTeJQqWS0MN7I/qa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTDe0XY6L6fI4GtQRAmHsAJ0fam9zzgO9GSog2U1+aVrKALjN7wCfSbHH kaolDnUHLNl6Mmg1RrWPD08= =/Kmv -----END PGP SIGNATURE----- --LTeJQqWS0MN7I/qa-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:09:41 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9687C16A41F for ; Tue, 11 Oct 2005 22:09:41 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3108343D46 for ; Tue, 11 Oct 2005 22:09:41 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9BM9ZVl027357; Tue, 11 Oct 2005 15:09:35 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9BM9ZMP027356; Tue, 11 Oct 2005 15:09:35 -0700 Date: Tue, 11 Oct 2005 15:09:35 -0700 From: Brooks Davis To: Csaba Henk Message-ID: <20051011220935.GE13461@odin.ac.hmc.edu> References: <434BCDF6.3090303@samsco.org> <20051011210703.GE2911@beastie.creo.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline In-Reply-To: <20051011210703.GE2911@beastie.creo.hu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Tue, 11 Oct 2005 22:09:41 -0000 --6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2005 at 11:07:03PM +0200, Csaba Henk wrote: > On Tue, Oct 11, 2005 at 08:36:38AM -0600, Scott Long wrote: > > Known Issues > > ------------ > [ ... ] > > - System lock ups may occur under extreme filesystem activity or with > > active filesystem snapshots. >=20 > Could someone give me a pointer what is this exactly? >=20 > I wouldn't like to mistake a known kernel bug for my own beloved > miserable fs code bugs. I believe the only ones I've seen have been UFS related so it probably isn't your code unless you're mucking about in UFS/FFS. :) -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTDgeXY6L6fI4GtQRAi43AJ9RjeC7EZGPLrGJjHJY2jYKLOjzMACg1Vit 6i6Ge/zuCSgLG4Mv/oTX4Z0= =7oOM -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:10:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 5875516A424; Tue, 11 Oct 2005 22:10:45 +0000 (GMT) In-Reply-To: <434C01D2.4040003@savvis.net> from Maksim Yevmenkin at "Oct 11, 2005 11:17:54 am" To: maksim.yevmenkin@savvis.net (Maksim Yevmenkin) Date: Tue, 11 Oct 2005 22:10:45 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051011221045.5875516A424@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: current@freebsd.org Subject: Re: buildkernel is broken in if_ndis X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 22:10:45 -0000 [Charset ISO-8859-1 unsupported, filtering to ASCII...] > dear hackers, > > make buildworld is broken for me. since NDIS_LOCK(sc) does not uses > sc->ndis_mtx anymore, shouldn't the following patch be put in place? > > max > > p.s. i could not find KeIsInitializedSpinLock function in subr_ndis.c. > quick look at msdn did not reveal it either > > > --- if_ndis.c.orig Tue Oct 11 11:11:52 2005 > +++ if_ndis.c Tue Oct 11 11:11:31 2005 > @@ -917,8 +917,6 @@ > driver_object *drv; > > sc = device_get_softc(dev); > - KASSERT(mtx_initialized(&sc->ndis_mtx), > - ("ndis mutex not initialized")); > NDIS_LOCK(sc); > ifp = sc->ifp; > ifp->if_flags &= ~IFF_UP; > Fixed. The KASSERT just doesn't need to be there anymore. In Windows, a spinlock is just a 32-bit long, and the only thing KeInitializeSpinLock() does is set spinlock = 0. There is no KeDestroySpinLock(): when you're done with the spinlock, you just free the storage in which it resides (after unlocking it for the last time, of course). Now, the NDIS API has NdisAllocateSpinLock() and NdisFreeSpinLock(), however I think Microsoft put them there based on the assumption that someone might want to implement the NDIS API on another OS where you really do have to allocate and free resources for spinlocks. However, NdisAllocateSpinLock() doesn't really allocate anything: it just calls KeInitializeSpinLock(), and NdisFreeSpinLock() does nothing. (Note also there's at least one driver out there which calls NdisFreeSpinLock() _AFTER_ releasing the storage in which the spinlock resides. But since NdisFreeSpinLock() is a no-op in Windows, the Microsoft driver verified never flags the error.) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:18:49 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9176A16A41F; Tue, 11 Oct 2005 22:18:49 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (69-12-149-25.dsl.static.sonic.net [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C23543D46; Tue, 11 Oct 2005 22:18:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j9BMIVpU001462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 15:18:32 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <434C3A27.2000808@errno.com> Date: Tue, 11 Oct 2005 15:18:15 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050927) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> <20051011210602.GA5714@heff.fud.org.nz> <20051011220749.GD13461@odin.ac.hmc.edu> In-Reply-To: <20051011220749.GD13461@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current , Andrew Thompson Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 22:18:49 -0000 Brooks Davis wrote: > On Wed, Oct 12, 2005 at 10:06:02AM +1300, Andrew Thompson wrote: > >>On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: >> >>>On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: >>> >>>>On Mon, Oct 10, 2005 at 03:28:49AM +0400, Yar Tikhiy wrote: >>>> >>>>>FWIW, I tried to look at the $subject problem since I had had it >>>>>before, but just got a different panic: >>>>> >>>>> Memory modified after free 0xc140b000(4092) val=deadc0dc @ 0xc140b000 >>>>> panic: Most recently used by clone >>>>> >>>>>The clone code seems to have decremented something (refcount?) twice >>>>>after freeing the memory chunk. >>>> >>>>I have been testing this patch and I think it fixes all the problems >>>>discussed. >>>> >>>>It changes refcounting to count the number of cloned interfaces so >>>>ifc_units is only freed when its safe. A new function has been added to >>>>decrement this when a simple cloner module is unloaded. The cloner is >>>>still detached first to prevent the race. >>>> >>>>In most cases the change is as simple as: >>> >>>I don't see any reason why you can't just replace the specific destroy >>>calls with calls to ifc_simple_destroy(). That would avoid expanding >>>the API. >> >>I have updated the patch and yes, its a nicer way to do it. Please >>review. >> >>Ive run through interations of create/kldunload with bridge, disc, >>faith, gif, gre and ppp with extra printf's and its freeing correctly. > > > This looks good to me, thanks for working on this and doing the > _destory removals. Let's see about getting this committed. > > Slightly longer term I think should consider hanging the interface list > off the cloner or maybe off some more generic per driver struct so > if_clone_detach() can destroy the interfaces and the unload code becomes > a one-liner in most cases. The current code is a result of not wanting > to mess with the drivers too much initially, but I think we need to > start looking at moving more bits into the support code. After all, if > we only write something once instead of once per interface, that's a lot > less opportunities to screw up. :) There's also the changes I have to pass parameter blocks on clone create... Sam From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:41:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D86916A420; Tue, 11 Oct 2005 22:41:13 +0000 (GMT) (envelope-from lofi@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 D0FAC43D55; Tue, 11 Oct 2005 22:41:10 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-09-z2.arcor-online.net (mail-in-09-z2.arcor-online.net [151.189.8.21]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id E971BA9814; Wed, 12 Oct 2005 00:41:09 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-09-z2.arcor-online.net (Postfix) with ESMTP id DD9D07586E; Wed, 12 Oct 2005 00:41:09 +0200 (CEST) Received: from lofi.dyndns.org (dslb-084-061-129-250.pools.arcor-ip.net [84.61.129.250]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 5AB1DA9814; Wed, 12 Oct 2005 00:41:09 +0200 (CEST) Received: from kiste.my.domain (root@kiste.my.domain [192.168.8.4]) by lofi.dyndns.org (8.13.4/8.13.3) with ESMTP id j9BMf7I3001561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 00:41:08 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from kiste.my.domain (lofi@localhost [127.0.0.1]) by kiste.my.domain (8.13.4/8.13.1) with ESMTP id j9BMf44G009337; Wed, 12 Oct 2005 00:41:04 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from localhost (localhost [[UNIX: localhost]]) by kiste.my.domain (8.13.4/8.13.1/Submit) id j9BMf3xs009336; Wed, 12 Oct 2005 00:41:03 +0200 (CEST) (envelope-from lofi@freebsd.org) X-Authentication-Warning: kiste.my.domain: lofi set sender to lofi@freebsd.org using -f From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2005 00:40:57 +0200 User-Agent: KMail/1.8.2 References: <200509220113.06667.lofi@freebsd.org> <20050929221041.H34322@fledge.watson.org> <200509292335.52277.lofi@freebsd.org> In-Reply-To: <200509292335.52277.lofi@freebsd.org> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o; >bD>c:]^; :>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new Cc: Robert Watson Subject: Re: UFS_EXTATTR(_AUTOSTART) broken on 6.0-BETA5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 22:41:13 -0000 --nextPart3094037.cbW3fh2tEm Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday, 29. September 2005 23:35, Michael Nottebrock wrote: > > I may have the opportunity to work on this this weekend, but not entire= ly > > clear. If Christian is already running with it, I'd much rather let him > > take this one on as I have a lot of other things on my plate. > > Just wanted to make sure it didn't get lost in mailing list traffic, > thanks! Still panics in 6.0RC1. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart3094037.cbW3fh2tEm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTD9/Xhc68WspdLARAnL9AKCLqkjw5mzKzXVUhVWL0rqp4zRAowCeKRvP d4MpFiZshgNjHYshDQXg0jw= =DIsP -----END PGP SIGNATURE----- --nextPart3094037.cbW3fh2tEm-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 23:40:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5280A16A420; Tue, 11 Oct 2005 23:40:20 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D58443D4C; Tue, 11 Oct 2005 23:40:18 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 1E75C1CCDD; Wed, 12 Oct 2005 12:40:14 +1300 (NZDT) Date: Wed, 12 Oct 2005 12:40:14 +1300 From: Andrew Thompson To: Brooks Davis Message-ID: <20051011234014.GA6179@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Brooks Davis , Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> <20051011210602.GA5714@heff.fud.org.nz> <20051011220749.GD13461@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051011220749.GD13461@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 23:40:20 -0000 On Tue, Oct 11, 2005 at 03:07:49PM -0700, Brooks Davis wrote: > On Wed, Oct 12, 2005 at 10:06:02AM +1300, Andrew Thompson wrote: > > On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: > > > On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > > > > I have been testing this patch and I think it fixes all the problems > > > > discussed. > > > > > > > > > > I don't see any reason why you can't just replace the specific destroy > > > calls with calls to ifc_simple_destroy(). That would avoid expanding > > > the API. > > > > I have updated the patch and yes, its a nicer way to do it. Please > > review. > > > > Ive run through interations of create/kldunload with bridge, disc, > > faith, gif, gre and ppp with extra printf's and its freeing correctly. > > This looks good to me, thanks for working on this and doing the > _destory removals. Let's see about getting this committed. > There was one problem where pflog0 would loop on EINVAL since it was a precloned device, livelocking the system. This addition fixes it, it was either this or a dying flag. void if_clone_detach(struct if_clone *ifc) { + struct ifc_simple_data *ifcs = ifc->ifc_data; IF_CLONERS_LOCK(); LIST_REMOVE(ifc, ifc_list); if_cloners_count--; IF_CLONERS_UNLOCK(); + /* Allow all to be destroyed */ + ifcs->ifcs_minifs = 0; + IF_CLONE_REMREF(ifc); } From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 23:46:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 575E416A41F; Tue, 11 Oct 2005 23:46:13 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9125043D45; Tue, 11 Oct 2005 23:46:12 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9BNjrdO013830; Tue, 11 Oct 2005 16:45:53 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9BNjr73013829; Tue, 11 Oct 2005 16:45:53 -0700 Date: Tue, 11 Oct 2005 16:45:52 -0700 From: Brooks Davis To: Andrew Thompson , Brooks Davis , Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current Message-ID: <20051011234551.GF13461@odin.ac.hmc.edu> References: <20051005024903.GA72743@heff.fud.org.nz> <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> <20051011210602.GA5714@heff.fud.org.nz> <20051011220749.GD13461@odin.ac.hmc.edu> <20051011234014.GA6179@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="924gEkU1VlJlwnwX" Content-Disposition: inline In-Reply-To: <20051011234014.GA6179@heff.fud.org.nz> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 23:46:13 -0000 --924gEkU1VlJlwnwX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 12:40:14PM +1300, Andrew Thompson wrote: > On Tue, Oct 11, 2005 at 03:07:49PM -0700, Brooks Davis wrote: > > On Wed, Oct 12, 2005 at 10:06:02AM +1300, Andrew Thompson wrote: > > > On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: > > > > On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > > > > > I have been testing this patch and I think it fixes all the probl= ems > > > > > discussed. > > > > >=20 > > > >=20 > > > > I don't see any reason why you can't just replace the specific dest= roy > > > > calls with calls to ifc_simple_destroy(). That would avoid expandi= ng > > > > the API. > > >=20 > > > I have updated the patch and yes, its a nicer way to do it. Please > > > review. > > >=20 > > > Ive run through interations of create/kldunload with bridge, disc, > > > faith, gif, gre and ppp with extra printf's and its freeing correctly. > >=20 > > This looks good to me, thanks for working on this and doing the > > _destory removals. Let's see about getting this committed. > >=20 >=20 > There was one problem where pflog0 would loop on EINVAL since it was a > precloned device, livelocking the system. >=20 > This addition fixes it, it was either this or a dying flag. Good catch. I think this is an OK fix. Did lo0 have the same issue? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --924gEkU1VlJlwnwX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTE6vXY6L6fI4GtQRAoEXAJ9BKGk0Df82RCFXz5ClJ0ZfX4JSQQCdGNlh BYQ4c+1D3sRfJcbqkhuU46Q= =nbws -----END PGP SIGNATURE----- --924gEkU1VlJlwnwX-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 23:58:59 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CCE316A41F; Tue, 11 Oct 2005 23:58:59 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16A8143D66; Tue, 11 Oct 2005 23:58:52 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3C14F1CCE5; Wed, 12 Oct 2005 12:58:49 +1300 (NZDT) Date: Wed, 12 Oct 2005 12:58:49 +1300 From: Andrew Thompson To: Brooks Davis Message-ID: <20051011235849.GB6179@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Brooks Davis , Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current References: <20051005203639.GA20552@garage.freebsd.pl> <20051005205515.GA30350@odin.ac.hmc.edu> <20051005210950.GB75848@heff.fud.org.nz> <20051009232849.GA27349@comp.chem.msu.su> <20051010022208.GA97249@heff.fud.org.nz> <20051010202900.GA24213@odin.ac.hmc.edu> <20051011210602.GA5714@heff.fud.org.nz> <20051011220749.GD13461@odin.ac.hmc.edu> <20051011234014.GA6179@heff.fud.org.nz> <20051011234551.GF13461@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051011234551.GF13461@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: Yar Tikhiy , Pawel Jakub Dawidek , FreeBSD Current Subject: Re: panic: ifc_free_unit: bit is already cleared X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 23:58:59 -0000 On Tue, Oct 11, 2005 at 04:45:52PM -0700, Brooks Davis wrote: > On Wed, Oct 12, 2005 at 12:40:14PM +1300, Andrew Thompson wrote: > > On Tue, Oct 11, 2005 at 03:07:49PM -0700, Brooks Davis wrote: > > > On Wed, Oct 12, 2005 at 10:06:02AM +1300, Andrew Thompson wrote: > > > > On Mon, Oct 10, 2005 at 01:29:00PM -0700, Brooks Davis wrote: > > > > > On Mon, Oct 10, 2005 at 03:22:08PM +1300, Andrew Thompson wrote: > > > > > > I have been testing this patch and I think it fixes all the problems > > > > > > discussed. > > > > > > > > > > > > > > > > I don't see any reason why you can't just replace the specific destroy > > > > > calls with calls to ifc_simple_destroy(). That would avoid expanding > > > > > the API. > > > > > > > > I have updated the patch and yes, its a nicer way to do it. Please > > > > review. > > > > > > > > Ive run through interations of create/kldunload with bridge, disc, > > > > faith, gif, gre and ppp with extra printf's and its freeing correctly. > > > > > > This looks good to me, thanks for working on this and doing the > > > _destory removals. Let's see about getting this committed. > > > > > > > There was one problem where pflog0 would loop on EINVAL since it was a > > precloned device, livelocking the system. > > > > This addition fixes it, it was either this or a dying flag. > > Good catch. I think this is an OK fix. Did lo0 have the same issue? No, as its not an unloadable module :) Just pflog and pfsync. Andrew From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 02:07:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7941516A41F for ; Wed, 12 Oct 2005 02:07:52 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id DCBE343D45 for ; Wed, 12 Oct 2005 02:07:51 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 32687 invoked from network); 12 Oct 2005 02:07:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-Squirrel-UserHash:X-Squirrel-FromHash:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4l+UwurvtgJUNkFBpBQfBoTZucDhPdHT7yBGLnE1EsI1PYIL2FxJLqzjZUEZaCxYqdGmD0Q5aoe2wfw/sXPgGSSVUj7wgMCbAIjw2jJnuerjoJr74S8aZTVL8ND3bfyO2y0WhYO3lsIukx1dIRSqIe+eDbXOPaziRsn45AgncDA= ; Received: from unknown (HELO 172.16.0.1) (mikej@rogers.com@70.31.50.81 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 12 Oct 2005 02:07:50 -0000 X-Squirrel-UserHash: GgEKEQ8= X-Squirrel-FromHash: FgtQRFVGBkU= Message-ID: <1422.FgtQRFVGBkU=.1129082866.squirrel@172.16.0.1> In-Reply-To: References: <434BCDF6.3090303@samsco.org> <434BEC96.4050801@samsco.org> Date: Tue, 11 Oct 2005 22:07:46 -0400 (EDT) From: "Mike Jakubik" To: "Joshua Coombs" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Wed, 12 Oct 2005 02:07:52 -0000 On Tue, October 11, 2005 1:39 pm, Joshua Coombs wrote: > > "Scott Long" wrote in message > news:434BEC96.4050801@samsco.org... > >> Joshua Coombs wrote: >> >> >>> Given that we're in the RC stage, is it too late to get a PR >>> stuffed in to correct ntpd/ntpdate behavior in /etc/rc.d? >>> >>> Joshua Coombs >>> >>> >> >> Depends on the kind of problem that you are seeing. Any details? >> >> >> Scott >> > > Two issues I spotted. > > > First, ntpdate is still being used, despite it being marked as > depreciated for quite some time. The preferred replacement is to call ntpd > with the -q switch. This causes ntpd to match ntpdate's behavior, it sets I like my ntpdate command, and im not about to change all my scripts and configure some ntpd servers just to quickly sync the time. From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 02:11:34 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B37216A439 for ; Wed, 12 Oct 2005 02:11:34 +0000 (GMT) (envelope-from cisbjc@cs.unisa.edu.au) Received: from reason.levels.unisa.edu.au (reason.levels.unisa.edu.au [130.220.33.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE73043D45 for ; Wed, 12 Oct 2005 02:11:33 +0000 (GMT) (envelope-from cisbjc@cs.unisa.edu.au) Received: from [192.168.0.209] (cis220313.levels.unisa.edu.au [130.220.37.202]) by reason.levels.unisa.edu.au (8.12.10/8.12.10) with ESMTP id j9C2BSKu028677; Wed, 12 Oct 2005 11:41:31 +0930 (CST) Message-ID: <434C7096.7000007@cs.unisa.edu.au> Date: Wed, 12 Oct 2005 11:40:30 +0930 From: Benjamin Close User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050627) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <434BCDF6.3090303@samsco.org> In-Reply-To: <434BCDF6.3090303@samsco.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Wed, 12 Oct 2005 02:11:34 -0000 Since we are now in RC, could someone please put in a warning about the ata driver not supporting parity on raid5 arrays. It's sure to bite someone otherwise. src/sys/dev/ata/ata-raid.c:512 Still shows it's not implemented. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 06:34:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0073716A41F for ; Wed, 12 Oct 2005 06:34:11 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 867A343D46 for ; Wed, 12 Oct 2005 06:34:11 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.100] (cpe-065-184-205-194.ec.res.rr.com [65.184.205.194]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j9C6Y7We026941; Wed, 12 Oct 2005 02:34:07 -0400 (EDT) Message-ID: <434CB029.1080508@ec.rr.com> Date: Wed, 12 Oct 2005 02:41:45 -0400 From: jason User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050814) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Schuele References: <20051011211626.5695.qmail@web50106.mail.yahoo.com> <434C3101.5090208@computer.org> In-Reply-To: <434C3101.5090208@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: "Jorge Mario G. Mazo" , freebsd-current@freebsd.org Subject: Re: 6-0-RC1 keeps failing on radeondrm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 06:34:12 -0000 Eric Schuele wrote: > Jorge Mario G. Mazo wrote: > >> --- Eric Schuele escribió: >> >> >>> Jorge Mario G. Mazo wrote: >>> >>>> hi there >>>> in 5.4 radeondrm was working properly since my >>> >>> >>> switch >>> >>>> to 6-BETAX and now RC1 make buildkernel keeps >>> >>> >>> failing >>> >>>> on radeondrm. here is the log. >>> >>> >>> Do you have: >>> >>> device agp >>> device drm >>> device radeondrm >>> >>> in your kernel config file? >> >> >> hi there >> seems like device drm was the problem >> but I have never used that, since when was that >> introduced and where is documented? > > > I think it showed up in releng_6. > I don't recalll any other documentation other than inside NOTES. > >> >> >> >> ================================================================= >> Either write things worth reading, Or do things worth the writing. >> -Benjamin Franklin >> >> __________________________________________________ >> Correo Yahoo! >> Espacio para todos tus mensajes, antivirus y antispam ¡gratis! >> Regístrate ya - http://correo.espanol.yahoo.com/ > > > I just built world on the ninth, and webcvs shows no updates since. Maybe you could try to clean world or delete src and try again? From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 06:36:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DE1B16A41F for ; Wed, 12 Oct 2005 06:36:18 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABECC43D4C for ; Wed, 12 Oct 2005 06:36:17 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.100] (cpe-065-184-205-194.ec.res.rr.com [65.184.205.194]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j9C6aDl8000794; Wed, 12 Oct 2005 02:36:13 -0400 (EDT) Message-ID: <434CB0A7.6000800@ec.rr.com> Date: Wed, 12 Oct 2005 02:43:51 -0400 From: jason User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050814) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Schuele References: <20051011211626.5695.qmail@web50106.mail.yahoo.com> <434C3101.5090208@computer.org> In-Reply-To: <434C3101.5090208@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: "Jorge Mario G. Mazo" , freebsd-current@freebsd.org Subject: Re: 6-0-RC1 keeps failing on radeondrm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 06:36:18 -0000 sorry, it's late. I read the first post and replied with out reading the rest. Please disregard my posts. From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 08:04:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 289A016A41F for ; Wed, 12 Oct 2005 08:04:06 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7804E43D49 for ; Wed, 12 Oct 2005 08:04:05 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id j9C83OL3019139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Oct 2005 10:03:24 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id j9C83OSF019138 for current@freebsd.org; Wed, 12 Oct 2005 10:03:24 +0200 (CEST) (envelope-from csaba) Date: Wed, 12 Oct 2005 10:03:24 +0200 From: Csaba Henk To: current@freebsd.org Message-ID: <20051012080324.GF2911@beastie.creo.hu> References: <434BCDF6.3090303@samsco.org> <20051011210703.GE2911@beastie.creo.hu> <20051011220935.GE13461@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051011220935.GE13461@odin.ac.hmc.edu> User-Agent: Mutt/1.5.9i Cc: Subject: Re: FreeBSD 6.0-RC1 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: Wed, 12 Oct 2005 08:04:06 -0000 On Tue, Oct 11, 2005 at 03:09:35PM -0700, Brooks Davis wrote: > I believe the only ones I've seen have been UFS related so it probably > isn't your code unless you're mucking about in UFS/FFS. :) God save me from that :) Good to hear, thx. Csaba From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 10:36:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 135B116A41F; Wed, 12 Oct 2005 10:36:27 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC4B43D53; Wed, 12 Oct 2005 10:36:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3E2AA.dip.t-dialin.net [84.163.226.170] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1EPdyC06sI-0003z2; Wed, 12 Oct 2005 12:36:24 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2005 12:36:50 +0200 User-Agent: KMail/1.8.2 References: <20051011213800.GA8839@xor.obsecurity.org> In-Reply-To: <20051011213800.GA8839@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3464263.jPie93MmLt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510121237.07383.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: sparc64@freebsd.org, des@freebsd.org, Kris Kennaway Subject: Re: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 10:36:27 -0000 --nextPart3464263.jPie93MmLt Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 October 2005 23:38, Kris Kennaway wrote: > A few weeks ago I reported that bufinit() on sparc64 machines with > > >12GB of RAM goes into an infinite loop because of a 32-bit integer > > counter overflowing. On 5.x it was possible to work around this with > the kern.maxbcache tunable, but this didn't work on 6.0 or above. > > It turns out the problem began here: > > ---- > Revision 1.67 / (download) - annotate - [select for diffs], Mon Nov 8 > 18:20:02 2004 UTC (11 months ago) by des Branch: MAIN > Changes since 1.66: +17 -17 lines > Diff to previous 1.66 (colored) > > #include instead of (the former > includes the latter, but also declares variables which are defined > in kern/subr_param.c). > > Change som VM parameters from quad_t to unsigned long. They refer to > quantities (size limits for text, heap and stack segments) which must > necessarily be smaller than the size of the address space, so long is > adequate on all platforms. > > MFC after: 1 week > ---- > > which contained: > > -int maxswzone; /* max swmeta KVA storage */ > -int maxbcache; /* max buffer cache KVA storage */ > +long maxswzone; /* max swmeta KVA storage */ > +long maxbcache; /* max buffer cache KVA storage */ > > However, des forgot to change the other definition of maxbcache in > : > > extern int maxbcache; /* Max KVA for buffer cache */ > > In fact, it's a good thing he didn't. On sparc64 if you make that > variable a long it causes 32-bit integer overflows elsewhere, which > lead to severe filesystem damage on systems with >12GB RAM. With the > above bug this is reduced to a hang at boot. Isn't it enough to introduce the maximum values below? I imagine that the= =20 ultimate goal is to get rid of the constrains, which will be easier if we=20 already have enough bits. > The hang is because maxbcache is not capped to a maximum value on > sparc64, and a loop termination condition never occurs because of a > 32-bit integer overflow. On amd64 it's capped to > > /* > * Ceiling on size of buffer cache (really only effects write queueing, > * the VM page cache is not effected), can be changed via > * the kern.maxbcache /boot/loader.conf variable. > */ > #ifndef VM_BCACHE_SIZE_MAX > #define VM_BCACHE_SIZE_MAX (400 * 1024 * 1024) > #endif > > so large-memory amd64 systems never see it. ia64 and ppc would also > hang at boot with >12GB, I think. > > On 5.x, the same hang exists, but you can work around it with the > tunable. This tunable was broken by the long/int mismatch on 6.0, so > sparc64 systems with >12GB were unusable. > > This patch reverts the above int->long change, and adds definitions > for VM_BCACHE_SIZE_MAX and VM_SWZONE_SIZE_MAX on sparc64 copied from > amd64. Actually, they should probably be added on other architectures > too (ia64, ppc). > > Can someone please review? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3464263.jPie93MmLt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTOdTXyyEoT62BG0RAhYIAJ9MlHeu+lXjwgrOw/ZQ/ecl90Lo+gCcDxLL 4BSiJP1pYKOfeRTr2Y8Voo0= =oq8D -----END PGP SIGNATURE----- --nextPart3464263.jPie93MmLt-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 14:59:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C8016A42A for ; Tue, 11 Oct 2005 14:59:40 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E120C43D45 for ; Tue, 11 Oct 2005 14:59:39 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9BExcBR001407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2005 07:59:39 -0700 X-Auth-Received: from yggdrasil.seektruth.org (c-67-171-38-33.hsd1.wa.comcast.net [67.171.38.33]) (authenticated authid=dsyphers) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.09) with ESMTP id j9BExcun019359 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Oct 2005 07:59:38 -0700 From: David Syphers To: Oliver Fromme Date: Tue, 11 Oct 2005 07:59:37 -0700 User-Agent: KMail/1.8.2 References: <200510111313.j9BDDlgi000935@lurza.secnetix.de> In-Reply-To: <200510111313.j9BDDlgi000935@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510110759.38444.dsyphers@u.washington.edu> X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='LOCALE_ARABIC 0, __CD 0, __CHAR_ARABIC_CT 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Mailman-Approved-At: Wed, 12 Oct 2005 11:49:31 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Intel 810 and agpgart on 6.0-beta5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 14:59:40 -0000 On Tuesday 11 October 2005 06:13 am, Oliver Fromme wrote: > David Syphers wrote: > > I'm trying to install X.org 6.8.2 on a new machine, and failing. I'm > > running 6-BETA5. > > Because you don't have a supported chipset. I have the > same situation on my notebook with intel i915GM, for which > there is no agpgart support yet for FreeBSD. Thanks for the help. I didn't purchase the computer myself, so it's true I didn't actually know what chipset I had (bad thing when installing X, I know). I'll try using a newer Xorg. -David -- "What's the good of having mastery over cosmic balance and knowing the secrets of fate if you can't blow something up?" -Terry Pratchett From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 15:34:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7613F16A423 for ; Tue, 11 Oct 2005 15:34:17 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4FCD43D46 for ; Tue, 11 Oct 2005 15:34:16 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mzebix@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j9BFYC56025840; Tue, 11 Oct 2005 17:34:13 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j9BFYCTl025838; Tue, 11 Oct 2005 17:34:12 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <200510111534.j9BFYCTl025838@lurza.secnetix.de> To: dantavious@comcast.net (Derrick Edwards) Date: Tue, 11 Oct 2005 17:34:12 +0200 (CEST) In-Reply-To: <200510111123.35565.dantavious@comcast.net> from "Derrick Edwards" at Oct 11, 2005 11:23:34 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Oct 2005 11:49:31 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Firefox dies unexpectedly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 15:34:17 -0000 Derrick Edwards wrote: > I have CFLAGS= -O2 -pipe -funroll-loops in /etc/make.conf > Would this do any damage? Yes. You should either remove that line completely, or reduce -O2 to -O, or add -fno-strict-aliasing to it. Note that the default is: -O2 -fno-strict-aliasing -pipe If you use -O2 without -fno-strict-aliasing, then you get problems in programs which are not aliasing-clean. The best solution is probably to just remove the CFLAGS line from your /etc/make.conf, then rebuild everything. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "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 Oct 11 18:22:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D204D16A41F for ; Tue, 11 Oct 2005 18:22:42 +0000 (GMT) (envelope-from jd@philemon.async.caltech.edu) Received: from philemon.async.caltech.edu (philemon.async.caltech.edu [131.215.39.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838EA43D53 for ; Tue, 11 Oct 2005 18:22:42 +0000 (GMT) (envelope-from jd@philemon.async.caltech.edu) Received: from philemon.async.caltech.edu (localhost [127.0.0.1]) by philemon.async.caltech.edu (8.13.4/8.13.4) with ESMTP id j9BINdOK063093; Tue, 11 Oct 2005 11:23:39 -0700 (PDT) (envelope-from jd@philemon.async.caltech.edu) Received: (from jd@localhost) by philemon.async.caltech.edu (8.13.4/8.13.1/Submit) id j9BINctg063092; Tue, 11 Oct 2005 11:23:38 -0700 (PDT) (envelope-from jd) Date: Tue, 11 Oct 2005 11:23:38 -0700 From: Paul Allen To: Sam Lawrance Message-ID: <20051011182337.GE35013@philemon.async.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailman-Approved-At: Wed, 12 Oct 2005 11:49:31 +0000 Cc: freebsd-current@freebsd.org Subject: Re: more usb keyboard (and mouse) troubles with 6.X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2005 18:22:42 -0000 I've seen this happen without using a USB keyboard as well. Let me take this opportunity to mention that it would be nice if moused_enable in rc.conf had a "NONE" option just like sendmail. I guess I wasn't paying enough attention when someone snuck those moused startups in devd based on a different set of variables... -Paul From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:26:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E919B16A41F for ; Tue, 11 Oct 2005 22:26:34 +0000 (GMT) (envelope-from tobias.m81@web.de) Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6210F43D45 for ; Tue, 11 Oct 2005 22:26:34 +0000 (GMT) (envelope-from tobias.m81@web.de) Received: from [217.247.130.97] (helo=[192.168.0.102]) by smtp06.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.105 #317) id 1EPSZs-00059g-00 for freebsd-current@freebsd.org; Wed, 12 Oct 2005 00:26:33 +0200 Message-ID: <434C5861.3060405@web.de> Date: Wed, 12 Oct 2005 00:27:13 +0000 From: =?ISO-8859-1?Q?Tobias_Mohrl=FCder?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: tobias.m81@web.de X-Sender: tobias.m81@web.de X-Mailman-Approved-At: Wed, 12 Oct 2005 11:49:31 +0000 Subject: 6.0-RC1: Boot panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 22:26:35 -0000 Hello all, I have just updated my system from 5-STABLE to 6.0-RC1 and experienced a kernel panic while booting. First it occured only few lines after the boot menu (two times at the same position). Then, after deleting some lines in loader.conf ('nvidia', 'acpi_ppc' and later on everything but 'autoboot_delay="1"' and 'hw.ata.atapi_dma=1'), the panic came up right after the 'rtc' line after the kernel init (when the color turns from white to grey - I am too lazy to boot again, let it panic and write it down. If it is important, please tell me). Again, the exact position of the panic stayed the same. Which seems strange to me, since the panic itself didn't change. The first thing printed on screen was 'Warning: Device "' (and nothing more) followed by the actual panic message, which looked like this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc057b4d0 stack pointer = 0x28:0xd712fa80 frame pointer = 0x28:0xd712fab4 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 = 32 (kldload) trap number = 12 panic: page fault I say 'like this' because it is not the exact message. I have a kernel dump, but get a 'kgdb: cannot read PTD' error - if someone can tell me how to solve this (the mailing lists did not), I would be really pleased. Anyway, these items I am sure of: The first line, the third line, the 'code segment' line (not including the 'DPL ..' line) and the last two lines. And I am sure that the *last* panic had 'kldload' as the current process, but I don't know if the other panic messages had that too. And here the info file: Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 33554432 Dump Length: 1072234496B (1022 MB) Blocksize: 512 Dumptime: Tue Oct 11 22:55:07 2005 Hostname: acheron.network Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.0-RC1 #0: Tue Oct 11 22:47:16 UTC 2005 tobiasmo@acheron.network:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 2875165490 Bounds: 32 Dump Status: good I tested both my own kernel config and GENERIC, with the same results. Any suggestions? Bye, Tobias Mohrlüder From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:37:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABF9C16A41F for ; Wed, 12 Oct 2005 13:37:05 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id E4B9C43D48 for ; Wed, 12 Oct 2005 13:37:04 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 12 Oct 2005 10:50:23 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp006) with SMTP; 12 Oct 2005 12:50:23 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2005 12:50:11 +0200 User-Agent: KMail/1.8.1 X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Message-Id: <200510121250.20515@harrymail> Content-Type: multipart/signed; boundary="nextPart2206294.xtqj7iZgWP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Ugly BETA5 crashes, VM fault (with trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 13:37:05 -0000 --nextPart2206294.xtqj7iZgWP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, my desktop box crashed for severla weeks every few days and since beta5 was= =20 withoug kdb I had to rebuild a debugging kernel to get this recorded (no=20 dump was written, so nothing in /var/crash) Like mentioned, I see the crash every view days, I think when having=20 simultaniously NFS and local disk load. Please tell me if I can provide more info! =2DHarry =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x5a fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc06ec5a9 stack pointer =3D 0x28:0xdad2c99c frame pointer =3D 0x28:0xdad2ca88 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 741 (kdeinit) [thread pid 741 tid 100102 ] Stopped at vm_fault+0x239: cmpw $0,0x5a(%eax) db> trace Tracing pid 741 tid 100102 td 0xc2470a80 vm_fault(c1443000,c144f000,2,0,c2470a80) at vm_fault+0x239 trap_pfault(dad2cb14,0,c144fff4,dad2cae8,c144fff4) at trap_pfault+0x156 trap(c0790008,28,c0850028,dad2ccb4,2000) at trap+0x38e calltrap() at calltrap+0x5 =2D-- trap 0xc, eip =3D 0xc06fd0ce, esp =3D 0xdad2cb54, ebp =3D 0xdad2cb68 = =2D-- vm_page_cowsetup(c144ffb8,0,c079615b,82,dad2cbf4) at vm_page_cowsetup+0x2e socow_setup(c1ef2300,dad2ccb4,2,2c4,1) at socow_setup+0x98 sosend(c29f4858,0,dad2ccb4,0,0) at sosend+0x56b soo_write(c284d090,dad2ccb4,c26f5980,0,c2470a80) at soo_write+0x87 dofilewrite(c2470a80,f,c284d090,dad2ccb4,ffffffff) at dofilewrite+0x85 kern_writev(c2470a80,f,dad2ccb4,8100ff4,de10) at kern_writev+0x65 write(c2470a80,dad2cd04,c,422,3) at write+0x4f syscall(805003b,3b,bfbf003b,805c000,f) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (4, FreeBSD ELF32, write), eip =3D 0x293791ab, esp =3D 0xbfbf= e15c,=20 ebp =3D 0xbfbfe178 --- db> --nextPart2206294.xtqj7iZgWP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD4DBQBDTOpsBylq0S4AzzwRAqAqAJ9hIe6YAVHB6KJhrrpJPoc0V2vcPgCY1jVd vE8yj2vdTAuAW2V0Am0/Vg== =jhsd -----END PGP SIGNATURE----- --nextPart2206294.xtqj7iZgWP-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:42:48 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 29ECC16A41F for ; Wed, 12 Oct 2005 13:42:43 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <434D12E4.2020406@freebsd.org> Date: Wed, 12 Oct 2005 21:43:00 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: zero process size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 13:42:48 -0000 The process fcitx has size 0, it looks very weired. The machine is UP amd64. last pid: 12142; load averages: 0.77, 0.73, 0.62 up 0+02:41:13 21:40:23 88 processes: 1 starting, 3 running, 84 sleeping CPU states: 26.9% user, 0.0% nice, 0.0% system, 0.0% interrupt, 73.1% idle Mem: 179M Active, 102M Inact, 73M Wired, 25M Cache, 60M Buf, 72M Free Swap: 1024M Total, 105M Used, 919M Free, 10% Inuse PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 11793 davidxu 2 -8 0 103M 16856K piperd 0:31 15.33% gnome-terminal 789 davidxu 1 96 0 0K 0K START 0:00 11.79% fcitx 12139 davidxu 5 96 0 218M 85200K ucond 0:11 5.83% mozilla-bin 785 davidxu 1 96 0 153M 80804K select 5:40 2.93% Xorg 851 davidxu 5 -8 0 61952K 6180K pcmwr 2:25 0.34% xmms 629 root 1 96 0 3528K 696K select 0:29 0.10% moused 855 davidxu 1 96 0 99888K 13792K select 0:12 0.00% wnck-applet 847 davidxu 7 96 0 144M 22116K ucond 0:11 0.00% nautilus From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 14:09:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE0716A420 for ; Wed, 12 Oct 2005 14:09:13 +0000 (GMT) (envelope-from brian@aljex.com) Received: from s1tank.virtdom.com (s1tank.virtdom.com [216.240.101.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 175BA43D45 for ; Wed, 12 Oct 2005 14:09:12 +0000 (GMT) (envelope-from brian@aljex.com) Received: (qmail 40270 invoked by uid 89); 12 Oct 2005 14:34:24 -0000 Received: from ool-4355e580.dyn.optonline.net (HELO venti) (brian@aljex.com@67.85.229.128) by s1tank.virtdom.com with SMTP; 12 Oct 2005 14:34:24 -0000 Message-ID: <00d201c5cf36$8117c750$6b1fa8c0@venti> From: "Brian K. White" To: , Date: Wed, 12 Oct 2005 10:09:04 -0400 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: Subject: re: wireless keyboard with built in mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 14:09:13 -0000 A while back I posted description of the mouse part of a wireless usb keyboard not working on 5.4 this questio and got asked what happens when I cat /dev/uhid0 while moving the mouse, pressing the buttons etc.. http://docs.freebsd.org/cgi/mid.cgi?200507311722.52659.mistry.7 Then later someone else added the comment that the problem is that there is more than one device on one usb receiver and that 6.0 has the necessary usb updates to handle that: I can't find a link to that comment. Maybe they sent it directly rather than to either -current or -usb and I've deleted my copy since then. Well I have a 6.0 box now, cvsupped a couple days ago FreeBSD 6.0-RC1 (AMDEMON) #2: Wed Oct 12 05:28:36 EDT 2005 And so far as I can tell, it behaves exactly the same as 5.4. The keyboard works fine, no part of the mouse works at all. (I had to google up the boot: comand to set a atkbd0 flags hint and set the keyboard to legacy support in the bios in order to install, since the boot menu and it's usb keyboard option went away, but after that I could turn the legacy emulation option back off in the bios and the keyboad continues to work with no manual or loader.conf rc.conf hacks by me) I couldn't answer the first question by the time I received it but now I can. On 6.0 though the original question was for 5.4. Nothing happens. Specifically, cat appears to open the device ok, it sits there as long as I want until I ctrl-c, and outputs nothing. On the same box, it works fine plugging in a non-wireless usb keyboard that has a 2 port usb hub built-in, and a normal usb mouse already plugged into one of the ports on the keyboard. both the keyboard and mouse are recognized and a /dev/ums0 is created and usbd starts a moused on it. Again, it works fully, out of the box with no manual intervention on recent linux (suse 9.3 & up) Is it possible the multiple device recognition thing exists but is really in 7 instead of 6? Thanks Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 14:21:02 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F94C16A420; Wed, 12 Oct 2005 14:21:02 +0000 (GMT) (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 B431643D73; Wed, 12 Oct 2005 14:21:01 +0000 (GMT) (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 BAAAD46BB1; Wed, 12 Oct 2005 10:21:00 -0400 (EDT) Date: Wed, 12 Oct 2005 15:21:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Michael Nottebrock In-Reply-To: <200510120041.03079.lofi@freebsd.org> Message-ID: <20051012150600.O48006@fledge.watson.org> References: <200509220113.06667.lofi@freebsd.org> <20050929221041.H34322@fledge.watson.org> <200509292335.52277.lofi@freebsd.org> <200510120041.03079.lofi@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jeff@FreeBSD.org, freebsd-current@freebsd.org, csjp@FreeBSD.org Subject: Re: UFS_EXTATTR(_AUTOSTART) broken on 6.0-BETA5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 14:21:02 -0000 On Wed, 12 Oct 2005, Michael Nottebrock wrote: > On Thursday, 29. September 2005 23:35, Michael Nottebrock wrote: > >>> I may have the opportunity to work on this this weekend, but not >>> entirely clear. If Christian is already running with it, I'd much >>> rather let him take this one on as I have a lot of other things on my >>> plate. >> >> Just wanted to make sure it didn't get lost in mailing list traffic, >> thanks! > > Still panics in 6.0RC1. Could you try the attached patch? It appears to work for me here, and I've committed it as ufs_extattr.c:1.82 in HEAD due to a high confidence it's the right fix. I will MFC it for 6.x if it also works for you. Given that extended attributes seem to be getting little testing with UFS1 at this point, I'd appreciate it if you could exercise them as much as possible in testing so we can try to catch any other bugs that may have crept in as the infrastructure around this code changed. Thanks, Robert N M Watson Index: ufs_extattr.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_extattr.c,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 --- ufs_extattr.c 31 Mar 2005 05:58:14 -0000 1.81 +++ ufs_extattr.c 12 Oct 2005 14:18:58 -0000 1.82 @@ -251,6 +251,7 @@ cnp.cn_flags = ISLASTCN; if (lockparent == UE_GETDIR_LOCKPARENT) cnp.cn_flags |= LOCKPARENT; + cnp.cn_lkflags = LK_EXCLUSIVE; cnp.cn_thread = td; cnp.cn_cred = td->td_ucred; cnp.cn_pnbuf = uma_zalloc(namei_zone, M_WAITOK); From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 14:22:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55C8F16A41F; Wed, 12 Oct 2005 14:22:05 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0E2643D45; Wed, 12 Oct 2005 14:22:03 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9CEM0OY020115; Thu, 13 Oct 2005 00:22:00 +1000 Received: from dirk.no.domain (ppp227F.dyn.pacific.net.au [61.8.34.127]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9CELw1W007542; Thu, 13 Oct 2005 00:21:59 +1000 Date: Thu, 13 Oct 2005 00:22:48 +1000 From: Sam Lawrance To: "Brian K. White" Message-ID: <20051013002248.65978ccc@dirk.no.domain> In-Reply-To: <00d201c5cf36$8117c750$6b1fa8c0@venti> References: <00d201c5cf36$8117c750$6b1fa8c0@venti> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: wireless keyboard with built in mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 14:22:05 -0000 On Wed, 12 Oct 2005 10:09:04 -0400 "Brian K. White" wrote: > A while back I posted description of the mouse part of a wireless usb > keyboard not working on 5.4 > this questio and got asked what happens when I cat /dev/uhid0 while > moving the mouse, pressing the buttons etc.. > http://docs.freebsd.org/cgi/mid.cgi?200507311722.52659.mistry.7 > > Then later someone else added the comment that the problem is that > there is more than one device on one usb receiver and that 6.0 has > the necessary usb updates to handle that: > I can't find a link to that comment. Maybe they sent it directly > rather than to either -current or -usb and I've deleted my copy since > then. See these PRs: http://www.freebsd.org/cgi/query-pr.cgi?pr=77604 http://www.freebsd.org/cgi/query-pr.cgi?pr=85972 The patches provided solved a similar problem for me. I believe the second PR there is the same problem, just waiting for submitter to confirm. From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 14:34:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3BA716A41F for ; Wed, 12 Oct 2005 14:34:31 +0000 (GMT) (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 5113743D49 for ; Wed, 12 Oct 2005 14:34:31 +0000 (GMT) (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 C1BA346BB1; Wed, 12 Oct 2005 10:34:30 -0400 (EDT) Date: Wed, 12 Oct 2005 15:34:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Emanuel Strobl In-Reply-To: <200510121250.20515@harrymail> Message-ID: <20051012153407.W48006@fledge.watson.org> References: <200510121250.20515@harrymail> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Ugly BETA5 crashes, VM fault (with trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 14:34:31 -0000 On Wed, 12 Oct 2005, Emanuel Strobl wrote: > my desktop box crashed for severla weeks every few days and since beta5 > was withoug kdb I had to rebuild a debugging kernel to get this recorded > (no dump was written, so nothing in /var/crash) Like mentioned, I see > the crash every view days, I think when having simultaniously NFS and > local disk load. Please tell me if I can provide more info! I take it you have zero-copy sockets enabled? Do the panics happen if you don't have it enabled? Robert N M Watson > > -Harry > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x5a > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06ec5a9 > stack pointer = 0x28:0xdad2c99c > frame pointer = 0x28:0xdad2ca88 > 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 = 741 (kdeinit) > [thread pid 741 tid 100102 ] > Stopped at vm_fault+0x239: cmpw $0,0x5a(%eax) > db> trace > Tracing pid 741 tid 100102 td 0xc2470a80 > vm_fault(c1443000,c144f000,2,0,c2470a80) at vm_fault+0x239 > trap_pfault(dad2cb14,0,c144fff4,dad2cae8,c144fff4) at trap_pfault+0x156 > trap(c0790008,28,c0850028,dad2ccb4,2000) at trap+0x38e > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc06fd0ce, esp = 0xdad2cb54, ebp = 0xdad2cb68 --- > vm_page_cowsetup(c144ffb8,0,c079615b,82,dad2cbf4) at vm_page_cowsetup+0x2e > socow_setup(c1ef2300,dad2ccb4,2,2c4,1) at socow_setup+0x98 > sosend(c29f4858,0,dad2ccb4,0,0) at sosend+0x56b > soo_write(c284d090,dad2ccb4,c26f5980,0,c2470a80) at soo_write+0x87 > dofilewrite(c2470a80,f,c284d090,dad2ccb4,ffffffff) at dofilewrite+0x85 > kern_writev(c2470a80,f,dad2ccb4,8100ff4,de10) at kern_writev+0x65 > write(c2470a80,dad2cd04,c,422,3) at write+0x4f > syscall(805003b,3b,bfbf003b,805c000,f) at syscall+0x2c0 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (4, FreeBSD ELF32, write), eip = 0x293791ab, esp = 0xbfbfe15c, > ebp = > 0xbfbfe178 --- > db> > From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 15:28:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CF7F16A42A for ; Wed, 12 Oct 2005 15:28:53 +0000 (GMT) (envelope-from tobias.m81@web.de) Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E6043D45 for ; Wed, 12 Oct 2005 15:28:52 +0000 (GMT) (envelope-from tobias.m81@web.de) Received: from [217.247.135.93] (helo=[192.168.0.102]) by smtp06.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.105 #317) id 1EPiXC-0000x9-00 for freebsd-current@freebsd.org; Wed, 12 Oct 2005 17:28:51 +0200 Message-ID: <434D47F9.5000103@web.de> Date: Wed, 12 Oct 2005 17:29:29 +0000 From: =?ISO-8859-1?Q?Tobias_Mohrl=FCder?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: tobias.m81@web.de X-Sender: tobias.m81@web.de Subject: 6.0-RC1: Boot panic - Update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 15:28:53 -0000 Hello, I was able to get kgdb working - I did not run 'make installworld' of course and the old kgdb version couldn't get along with the 6.0 kernel (I suppose). After installing the libraries needed by the new kgdb binary by hand, I can give you some additional info: Unread portion of the kernel message buffer: <118> rtc WARNING: Device driver " Fatal trap 12: page fault while in kernel mode fault virtual address = 0x400000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc069b924 stack pointer = 0x28:0xe5088aa4 frame pointer = 0x28:0xe5088aa4 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 = 490 (kldload) trap number = 12 panic: page fault Uptime: 20s Dumping 1022 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1022MB (261616 pages) 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc0637816 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0637aac in panic (fmt=0xc084d786 "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0806e70 in trap_fatal (frame=0xe5088a64, eva=4194304) at /usr/src/sys/i386/i386/trap.c:831 #4 0xc0806bdb in trap_pfault (frame=0xe5088a64, usermode=0, eva=4194304) at /usr/src/sys/i386/i386/trap.c:742 #5 0xc0806819 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = 0, tf_ebp = -452425052, tf_isp = -452425072, tf_ebx = -1064940965, tf_edx = 4194304, tf_ecx = 0, tf_eax = 4194304, tf_trapno = 12, tf_err = 0, tf_eip = -1066813148, tf_cs = 32, tf_eflags = 590406, tf_esp = -452424852, tf_ss = -1067113936}) at /usr/src/sys/i386/i386/trap.c:432 #6 0xc07f601a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc069b924 in strlen (str=0x400000
) at /usr/src/sys/libkern/strlen.c:41 #8 0xc0652230 in kvprintf (fmt=0xc0864a5b "\" has wrong version %s\n", func=0xc06519b4 , arg=0xe5088b88, radix=10, ap=0xe5088bac "\031J\206À") at /usr/src/sys/kern/subr_prf.c:679 #9 0xc065192f in printf ( fmt=0xc0864a41 "WARNING: Device driver \"%s\" has wrong version %s\n") at /usr/src/sys/kern/subr_prf.c:296 #10 0xc060f8e3 in prep_cdevsw (devsw=0xc2798de0) at /usr/src/sys/kern/kern_conf.c:451 #11 0xc060fb24 in make_dev_credv (devsw=0xc2798de0, minornr=0, cr=0x0, uid=4194304, gid=4194304, mode=4194304, fmt=0xc2797d54 "rtc", ap=0xe5088c18 "") at /usr/src/sys/kern/kern_conf.c:522 #12 0xc060fbec in make_dev (devsw=0xc2798de0, minornr=0, uid=0, gid=0, mode=420, fmt=0xc2797d54 "rtc") at /usr/src/sys/kern/kern_conf.c:568 #13 0xc2797b33 in ?? () #14 0xc2798de0 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x000001a4 in ?? () #19 0xc2797d54 in ?? () #20 0xc25d3500 in ?? () #21 0xe5088c24 in ?? () #22 0xc2797b7d in ?? () #23 0xe5088c50 in ?? () #24 0xc062e787 in module_register_init (arg=0xe5088c50) at /usr/src/sys/kern/kern_module.c:121 Previous frame inner to this frame (corrupt stack?) Hope this helps. Unfortunatly I am unable to get the dump of the other panic (the one which occured earlier in boot phase), since there is no dump device defined at this point. Tobias Mohrlüder From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 16:55:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72D1516A41F for ; Wed, 12 Oct 2005 16:55:19 +0000 (GMT) (envelope-from brian@aljex.com) Received: from s1tank.virtdom.com (s1tank.virtdom.com [216.240.101.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 8591D43D49 for ; Wed, 12 Oct 2005 16:55:18 +0000 (GMT) (envelope-from brian@aljex.com) Received: (qmail 25645 invoked by uid 89); 12 Oct 2005 17:20:30 -0000 Received: from ool-4355e580.dyn.optonline.net (HELO venti) (brian@aljex.com@67.85.229.128) by s1tank.virtdom.com with SMTP; 12 Oct 2005 17:20:30 -0000 Message-ID: <005301c5cf4d$b4aaefe0$6b1fa8c0@venti> From: "Brian K. White" To: , References: <00d201c5cf36$8117c750$6b1fa8c0@venti> <20051013002248.65978ccc@dirk.no.domain> Date: Wed, 12 Oct 2005 12:55:09 -0400 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: Subject: Re: wireless keyboard with built in mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 16:55:19 -0000 ----- Original Message ----- From: "Sam Lawrance" To: "Brian K. White" Cc: ; Sent: Wednesday, October 12, 2005 10:22 AM Subject: Re: wireless keyboard with built in mouse > On Wed, 12 Oct 2005 10:09:04 -0400 > "Brian K. White" wrote: > >> A while back I posted description of the mouse part of a wireless usb >> keyboard not working on 5.4 >> this questio and got asked what happens when I cat /dev/uhid0 while >> moving the mouse, pressing the buttons etc.. >> http://docs.freebsd.org/cgi/mid.cgi?200507311722.52659.mistry.7 >> >> Then later someone else added the comment that the problem is that >> there is more than one device on one usb receiver and that 6.0 has >> the necessary usb updates to handle that: >> I can't find a link to that comment. Maybe they sent it directly >> rather than to either -current or -usb and I've deleted my copy since >> then. > > See these PRs: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=77604 > http://www.freebsd.org/cgi/query-pr.cgi?pr=85972 > > The patches provided solved a similar problem for me. I believe the > second PR there is the same problem, just waiting for submitter to > confirm. Thanks much. It's building now. Are these patches available in an un-munged form somewhere? Even the "raw pr" option on the web page still only produces a page where the original emails and attachments have been munged with "=D2" etc... When I pasted the hid.c patch into a file, patch just complains about malformed patch. I figured out that the web interface or the cutting & pasting stripped off the single leading space that unchanged lines are supposed to have, manually put them back in the patch. Manually stripped the trailing space that was added to every line, made sure the whitespace was the same (tabs vs spaces) patch doesn't complain anymore, now it just rejects the hunk for no reason I can figure out. I tried using patch -l and -F n , I ended up applying the changes completely by hand. I'm glad it was a small patch! ...time passes... Ok, it built cleanly but didn't change anything I can see. Here's dmesg: Copyright (c) 1992-2005 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 6.0-RC1 #3: Thu Oct 13 00:20:30 EDT 2005 root@amdemon.local:/usr/obj/usr/src/sys/AMDEMON ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3200+ (2191.24-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 1073676288 (1023 MB) avail memory = 1041788928 (993 MB) ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 10 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: on acpi0 pci_link3: irq 12 on acpi0 pci_link4: on acpi0 pci_link5: irq 10 on acpi0 pci_link6: irq 11 on acpi0 pci_link7: on acpi0 pci_link8: on acpi0 pci_link9: irq 5 on acpi0 pci_link10: on acpi0 pci_link11: irq 12 on acpi0 pci_link12: irq 9 on acpi0 pci_link13: on acpi0 pci_link14: on acpi0 pci_link15: on acpi0 pci_link16: irq 16 on acpi0 pci_link17: irq 17 on acpi0 pci_link18: irq 18 on acpi0 pci_link19: irq 19 on acpi0 pci_link20: irq 16 on acpi0 pci_link21: irq 0 on acpi0 pci_link22: irq 0 on acpi0 pci_link23: irq 0 on acpi0 pci_link24: irq 0 on acpi0 pci_link25: irq 0 on acpi0 pci_link26: irq 0 on acpi0 pci_link27: irq 23 on acpi0 pci_link28: irq 0 on acpi0 pci_link29: irq 0 on acpi0 pci_link30: irq 0 on acpi0 pci_link31: irq 0 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0xcf0-0xcf3 on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 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 0xe8003000-0xe8003fff irq 20 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe8004000-0xe8004fff irq 21 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe8005000-0xe80050ff irq 22 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered pci0: at device 6.0 (no driver attached) pcib1: at device 8.0 on pci0 pci_link18: BIOS IRQ 20 for 0.6.INTA is invalid pci1: on pcib1 re0: port 0x9000-0x90ff mem 0xe7000000-0xe70000ff irq 16 at device 11.0 on pci1 miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:0f:ea:48:2b:b5 atapci0: port 0x9410-0x9417,0x9800-0x9803,0x9c10-0x9c17,0xa000-0xa003,0xa400-0xa40f irq 17 at device 12.0 on pci1 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci1 ata1: on atapci1 pcib2: at device 30.0 on pci0 pci2: on pcib2 drm0: port 0xc000-0xc0ff mem 0xd0000000-0xd7ffffff,0xe5000000-0xe500ffff irq 19 at device 0.0 on pci2 info: [drm] AGP at 0xe0000000 64MB info: [drm] Initialized radeon 1.16.0 20050311 on minor 0 pci2: at device 0.1 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A 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/16 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff,0xd0000-0xd17ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub3: vendor 0x0557 product 0x7000, class 9/0, rev 1.10/1.00, addr 2 uhub3: 4 ports with 4 removable, self powered ukbd0: Sony RF Receiver, rev 1.10/1.00, addr 3, iclass 3/1 kbd1 at ukbd0 uhid0: Sony RF Receiver, rev 1.10/1.00, addr 3, iclass 3/1 Timecounter "TSC" frequency 2191237369 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDRW at ata0-master PIO4 ad4: 76319MB at ata2-master UDMA100 ad6: 76319MB at ata3-master UDMA100 ar0: 152638MB status: READY ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad6 at ata3-master Trying to mount root from ufs:/dev/ar0s1a re0: link state changed to UP Thanks anyways! On a positive note. Suse 10.0 couldn't install on the same machine unless I was willing to let it install to one of the physical drives in the raid0 striped array. It's a Gigabyte gigaraid ite8212 chip on the motherboard and the installer claimed that support was present in 2.4 and removed in 2.6 and that I should install to one drive and then use the software raid. Kinda hard with a stripped array! (well, I suppose it's theoretically possible they have a util chop up an existing solid drive into stripes and redistribute half of them, all while the drive is mounted...) Meanwhile, FreeBSD 6 dropped right on the array with no fuss at all. Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 16:55:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1BCB16A46E; Wed, 12 Oct 2005 16:55:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6726B43D48; Wed, 12 Oct 2005 16:55:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [70.30.70.180]) by elvis.mu.org (Postfix) with ESMTP id 483841A3C25; Wed, 12 Oct 2005 09:55:38 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 404B65141B; Wed, 12 Oct 2005 12:55:34 -0400 (EDT) Date: Wed, 12 Oct 2005 12:55:34 -0400 From: Kris Kennaway To: Max Laier Message-ID: <20051012165533.GA55776@xor.obsecurity.org> References: <20051011213800.GA8839@xor.obsecurity.org> <200510121237.07383.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <200510121237.07383.max@love2party.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, sparc64@freebsd.org, des@freebsd.org, Kris Kennaway Subject: Re: int/long confusion with maxbcache and maxswzone (fixes 6.0 on >12GB machines) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 16:55:38 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 12:36:50PM +0200, Max Laier wrote: > > -int maxswzone; /* max swmeta KVA storage */ > > -int maxbcache; /* max buffer cache KVA storage */ > > +long maxswzone; /* max swmeta KVA storage */ > > +long maxbcache; /* max buffer cache KVA storage */ > > > > However, des forgot to change the other definition of maxbcache in > > : > > > > extern int maxbcache; /* Max KVA for buffer cache */ > > > > In fact, it's a good thing he didn't. On sparc64 if you make that > > variable a long it causes 32-bit integer overflows elsewhere, which > > lead to severe filesystem damage on systems with >12GB RAM. With the > > above bug this is reduced to a hang at boot. >=20 > Isn't it enough to introduce the maximum values below? I imagine that th= e=20 > ultimate goal is to get rid of the constrains, which will be easier if we= =20 > already have enough bits. No, it's not. As I mentioned, on 5.x you can work around this problem by using the existing tunable to limit the parameter, but not on 6.0 unless you also revert long to int. Something is getting confused about whether that variable is a long or an int since it's inconsistently defined. Anyway, making these variables consistently long is a very bad idea until more of the system is ready for that - that was the first thing I tried when I identified the problem, and it completely destroyed all of my filesystems within seconds, requiring a reinstall. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDTUAFWry0BWjoQKURAjk5AJ9d29kLADXDiqvwMBuSllZoTQwCGACg/R+4 NoD4Wzq2N1iTjS/VVwU4nxk= =F249 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 18:06:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BDE916A41F for ; Wed, 12 Oct 2005 18:06:38 +0000 (GMT) (envelope-from tech.sivam@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 698A043D46 for ; Wed, 12 Oct 2005 18:06:37 +0000 (GMT) (envelope-from tech.sivam@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so113326wxc for ; Wed, 12 Oct 2005 11:06:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=aeotrQ9h8qYu4GTnEqghZzrt+Jts+0QDKth4+jTWUtnsYqWwv0Y7DCmdRx/waIzoNdR+zX8g/GEavD+zZCbTrx0NT6VcikhST3YGv3Pk8B/QA2Jj5GPyw7C9p+PwutpQCIf4S4WkuJWGSv0b803AB4aHepYC1EfTW3Uy2gj5F88= Received: by 10.70.89.8 with SMTP id m8mr261972wxb; Wed, 12 Oct 2005 10:41:34 -0700 (PDT) Received: by 10.70.61.14 with HTTP; Wed, 12 Oct 2005 10:41:34 -0700 (PDT) Message-ID: <660414a50510121041m4e348783y9e47292c3925fb70@mail.gmail.com> Date: Wed, 12 Oct 2005 12:41:34 -0500 From: siva m To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: compilation failure... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 18:06:38 -0000 hi, I am trying to compile the FreeBSD 6.0_rc1 on my AMD athlon xp box and it failed with the following output. ------------------------- cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../fs/deadfs/dead_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../fs/devfs/devfs_devs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../fs/devfs/devfs_rule.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../fs/devfs/devfs_vfsops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/at= h -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -I../../../dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 --param large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror ../../../fs/devfs/devfs_vnops.c ../../../fs/devfs/devfs_vnops.c:1148: warning: redundant redeclaration of 'devfs_ops_f' ../../../fs/devfs/devfs_vnops.c:70: warning: previous declaration of 'devfs_ops_f' was here ../../../fs/devfs/devfs_vnops.c:1159: warning: redundant redeclaration of 'devfs_vnodeops' ../../../fs/devfs/devfs_vnops.c:68: warning: previous declaration of 'devfs_vnodeops' was here ../../../fs/devfs/devfs_vnops.c:1181: warning: redundant redeclaration of 'devfs_specops' ../../../fs/devfs/devfs_vnops.c:69: warning: previous declaration of 'devfs_specops' was here *** Error code 1 Stop in /usr/src/sys/i386/compile/MYKERNEL. thanks, siva From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 18:09:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D32316A41F for ; Wed, 12 Oct 2005 18:09:21 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAB4F43D46 for ; Wed, 12 Oct 2005 18:09:20 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.3/8.13.3) with ESMTP id j9CI9IBL084347; Wed, 12 Oct 2005 22:09:19 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 12 Oct 2005 22:09:18 +0400 (MSD) From: Maxim Konovalov To: siva m In-Reply-To: <660414a50510121041m4e348783y9e47292c3925fb70@mail.gmail.com> Message-ID: <20051012220847.H84215@mp2.macomnet.net> References: <660414a50510121041m4e348783y9e47292c3925fb70@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: compilation failure... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 18:09:21 -0000 On Wed, 12 Oct 2005, 12:41-0500, siva m wrote: > hi, > I am trying to compile the FreeBSD 6.0_rc1 on my AMD athlon xp box and it > failed with the following output. FFAQ. make buildworld first. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 18:23:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2A3116A41F for ; Wed, 12 Oct 2005 18:23:25 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6403743D49 for ; Wed, 12 Oct 2005 18:23:25 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so113549wxc for ; Wed, 12 Oct 2005 11:23:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=PYLJBnsAozj9TpyNrpfkOzJZ3gWpRoibMjblFRAk/YabpTL0JAi6zCJQotZHouWcZACTp6/38MYbPahOO598eoRk8PfGg3RxutAniBBydOpHfaiDKFPEd+4KwN3+1Fh1/O6zdt+ShPSJeOoaKATayiy5KBgXA3kVBRC/ua1t0Q4= Received: by 10.70.51.7 with SMTP id y7mr255307wxy; Wed, 12 Oct 2005 10:58:57 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Wed, 12 Oct 2005 10:58:57 -0700 (PDT) Message-ID: <2b22951e0510121058u49cccf20kddd55352543c2304@mail.gmail.com> Date: Wed, 12 Oct 2005 10:58:57 -0700 From: "Cai, Quanqing" To: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-firewire@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kiyohara@kk.iij4u.or.jp Subject: Regarding kern/73852, please help to apply the patch thus we can close this bug. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 18:23:25 -0000 Hi guys, I noticed there is bug filed by KIYOHARA Takashi with a patch, link is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/73852, I tested if_fwip w= ith this patch, it works great for me. When we switch byte-order two times on i386, the byte-order will back to original. if you look at the files src/lib/libc/i386/net/ntohl.S and src/lib/libc/i386/net/htonl.S, you will find exact same code: movl 4(%esp),%eax bswap %eax ret This tells everything. So I hope somebody can apply the patch made by KIYOHARA Takashi and close this bug. Thanks Cai, Quanqing From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 18:34:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE3816A422 for ; Wed, 12 Oct 2005 18:34:17 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF2A643D6E for ; Wed, 12 Oct 2005 18:34:02 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9CIY140017804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 14:34:01 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9CIXttj006199; Wed, 12 Oct 2005 14:33:55 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17229.22291.792602.879249@grasshopper.cs.duke.edu> Date: Wed, 12 Oct 2005 14:33:55 -0400 (EDT) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: emanuel.strobl@gmx.net Subject: Re: Ugly BETA5 crashes, VM fault (with trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 18:34:17 -0000 Can you start gdb on your kernel.debug, and show the output of: "list *vm_page_cowsetup+0x2e" Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 18:50:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C355516A421 for ; Wed, 12 Oct 2005 18:50:59 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E51243D48 for ; Wed, 12 Oct 2005 18:50:57 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so117402wxc for ; Wed, 12 Oct 2005 11:50:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Vk10lzzcanNDb607JybyMjZK739D4MvyU4lRjAo3TwTbjACmVFC6WtAp/l5a17YbILnToYd8eUSpWs5Fn8Z5hWq0125G1n6+9UwHTIYqHcxczj9gl88s4B1VaWaeCmpD/8wR5BhT1VXklMlZfelc6mgAJgrzY+MF3astKowSxgo= Received: by 10.70.87.14 with SMTP id k14mr283476wxb; Wed, 12 Oct 2005 11:50:57 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Wed, 12 Oct 2005 11:50:57 -0700 (PDT) Message-ID: <2b22951e0510121150o7be85033ic054cabed7e94e5e@mail.gmail.com> Date: Wed, 12 Oct 2005 11:50:57 -0700 From: "Cai, Quanqing" To: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-firewire@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <2b22951e0510121058u49cccf20kddd55352543c2304@mail.gmail.com> MIME-Version: 1.0 References: <2b22951e0510121058u49cccf20kddd55352543c2304@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: kiyohara@kk.iij4u.or.jp Subject: Re: Regarding kern/73852, please help to apply the patch thus we can close this bug. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 18:51:00 -0000 Forget to mention that my test machines, one is 7.0-CURRENT, another one is FreeBSD 6.0-RC1. So I think we can MFC to 6.x too. Cai, Quanqing On 10/12/05, Cai, Quanqing wrote: > > Hi guys, > > I noticed there is bug filed by KIYOHARA Takashi > with a patch, link is here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/73852, I tested if_fwip > with this patch, it works great for me. When we switch byte-order two tim= es > on i386, the byte-order will back to original. if you look at the files > src/lib/libc/i386/net/ntohl.S and src/lib/libc/i386/net/htonl.S, you will > find exact same code: > > movl 4(%esp),%eax > bswap %eax > ret > > This tells everything. > > So I hope somebody can apply the patch made by KIYOHARA Takashi and close > this bug. > > Thanks > Cai, Quanqing From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 19:52:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E092B16A41F for ; Wed, 12 Oct 2005 19:52:01 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3C9843D53 for ; Wed, 12 Oct 2005 19:51:47 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id B31321A957; Wed, 12 Oct 2005 21:51:45 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (manticore.shapeshifter.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34447-13; Wed, 12 Oct 2005 21:51:44 +0200 (CEST) Received: from [192.168.0.94] (h4n2fls31o270.telia.com [217.208.199.4]) by mx1.h3q.net (Postfix) with ESMTP id CB36C1A956; Wed, 12 Oct 2005 21:51:44 +0200 (CEST) Message-ID: <434D6959.2060108@shapeshifter.se> Date: Wed, 12 Oct 2005 21:51:53 +0200 From: Fredrik Lindberg User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050928) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Tobias_Mohrl=FCder?= References: <434D47F9.5000103@web.de> In-Reply-To: <434D47F9.5000103@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: at mail.hamnpolare.net Cc: freebsd-current@freebsd.org Subject: Re: 6.0-RC1: Boot panic - Update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 19:52:02 -0000 Tobias Mohrlüder wrote: > Hello, > > I was able to get kgdb working - I did not run 'make installworld' of > course and the old kgdb version couldn't get along with the 6.0 kernel > (I suppose). After installing the libraries needed by the new kgdb > binary by hand, I can give you some additional info: > > > Unread portion of the kernel message buffer: > <118> rtc > WARNING: Device driver " [...] > current process = 490 (kldload) > trap number = 12 > panic: page fault You are loading the rtc (emulators/rtc) module compiled for 5-stable (as stated in your previous mail, you upgraded 5->6.0). Disable loading of the module and you should be fine, if i'm not mistaken, it's loaded from a rc.d-script in /usr/X11R6/etc/rc.d Fredrik From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 20:28:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6475E16A41F; Wed, 12 Oct 2005 20:28:19 +0000 (GMT) (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 E506F43D45; Wed, 12 Oct 2005 20:28:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9CKSH7N087094; Wed, 12 Oct 2005 16:28:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CKSHiV087458; Wed, 12 Oct 2005 16:28:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9D64F7302F; Wed, 12 Oct 2005 16:28:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051012202817.9D64F7302F@freebsd-current.sentex.ca> Date: Wed, 12 Oct 2005 16:28:17 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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, 12 Oct 2005 20:28:19 -0000 TB --- 2005-10-12 18:50:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-12 18:50:34 - starting HEAD tinderbox run for i386/i386 TB --- 2005-10-12 18:50:34 - cleaning the object tree TB --- 2005-10-12 18:51:00 - checking out the source tree TB --- 2005-10-12 18:51:00 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-10-12 18:51:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-12 18:57:30 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-12 18:57:30 - cd /src TB --- 2005-10-12 18:57:30 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-12 20:01:20 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-12 20:01:20 - cd /src TB --- 2005-10-12 20:01:20 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Oct 12 20:01:20 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Wed Oct 12 20:19:03 UTC 2005 TB --- 2005-10-12 20:19:03 - generating LINT kernel config TB --- 2005-10-12 20:19:03 - cd /src/sys/i386/conf TB --- 2005-10-12 20:19:03 - /usr/bin/make -B LINT TB --- 2005-10-12 20:19:03 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-12 20:19:03 - cd /src TB --- 2005-10-12 20:19:03 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 12 20:19:03 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_sem.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_socket.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_socket2.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/vfs_aio.c /src/sys/kern/vfs_aio.c: In function `lio_listio': /src/sys/kern/vfs_aio.c:1990: warning: 's' might be used uninitialized in this function *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-12 20:28:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-12 20:28:17 - ERROR: failed to build lint kernel TB --- 2005-10-12 20:28:17 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 20:38:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED09416A41F; Wed, 12 Oct 2005 20:38:12 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 196C543D46; Wed, 12 Oct 2005 20:38:11 +0000 (GMT) (envelope-from lofi@freebsd.org) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 7AA9394FF1; Wed, 12 Oct 2005 22:38:10 +0200 (CEST) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 6A2321BE0A8; Wed, 12 Oct 2005 22:38:10 +0200 (CEST) Received: from lofi.dyndns.org (dslb-084-061-142-061.pools.arcor-ip.net [84.61.142.61]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id A40BA6100E; Wed, 12 Oct 2005 22:38:09 +0200 (CEST) Received: from kiste.my.domain (root@kiste.my.domain [192.168.8.4]) by lofi.dyndns.org (8.13.4/8.13.3) with ESMTP id j9CKc8Mv001644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 22:38:09 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from kiste.my.domain (lofi@localhost [127.0.0.1]) by kiste.my.domain (8.13.4/8.13.1) with ESMTP id j9CKc44a005083; Wed, 12 Oct 2005 22:38:04 +0200 (CEST) (envelope-from lofi@freebsd.org) Received: from localhost (localhost [[UNIX: localhost]]) by kiste.my.domain (8.13.4/8.13.1/Submit) id j9CKc3mt005082; Wed, 12 Oct 2005 22:38:03 +0200 (CEST) (envelope-from lofi@freebsd.org) X-Authentication-Warning: kiste.my.domain: lofi set sender to lofi@freebsd.org using -f From: Michael Nottebrock To: Robert Watson Date: Wed, 12 Oct 2005 22:37:56 +0200 User-Agent: KMail/1.8.2 References: <200509220113.06667.lofi@freebsd.org> <200510120041.03079.lofi@freebsd.org> <20051012150600.O48006@fledge.watson.org> In-Reply-To: <20051012150600.O48006@fledge.watson.org> X-Face: =Ym$`&q\+S2X$4`X%x%6"L4>Y,$]<":'L%c9"#7#`2tb&E&wsN31on!N\)3BD[g<=?utf-8?q?=2EjnfV=5B=0A=093=23?=>XchLK,o; >bD>c:]^; :>0>vyZ.X[,63GW`&M>}nYnr]-Fp``,[[@lJ!QL|sfW!s)=?utf-8?q?A2!*=0A=09vNkB/=7CL-?=>&QdSbQg X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org, csjp@freebsd.org Subject: Re: UFS_EXTATTR(_AUTOSTART) broken on 6.0-BETA5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 20:38:13 -0000 --nextPart2805657.nH6eVR1rhX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 12. October 2005 16:21, Robert Watson wrote: > Could you try the attached patch? It appears to work for me here, and > I've committed it as ufs_extattr.c:1.82 in HEAD due to a high confidence > it's the right fix. I will MFC it for 6.x if it also works for you. Works fine now, many thanks! > Given that extended attributes seem to be getting little testing with UFS1 > at this point, I'd appreciate it if you could exercise them as much as > possible in testing so we can try to catch any other bugs that may have > crept in as the infrastructure around this code changed. I'll pipe up if I notice anything. Thanks again, =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2805657.nH6eVR1rhX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTXQrXhc68WspdLARAsRyAJ9q7yAIGc5akKIl9b/pf1SB4NexjQCfe3YJ vfMvrQ6sb9x3PhozRmVdUZY= =Wkgd -----END PGP SIGNATURE----- --nextPart2805657.nH6eVR1rhX-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 21:41:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65CFE16A41F for ; Wed, 12 Oct 2005 21:41:33 +0000 (GMT) (envelope-from fbsd@lurkie.xs4all.nl) Received: from lurkie.xs4all.nl (lurkie.xs4all.nl [194.109.236.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id C56FC43D46 for ; Wed, 12 Oct 2005 21:41:32 +0000 (GMT) (envelope-from fbsd@lurkie.xs4all.nl) Received: from lurkie.xs4all.nl (localhost [127.0.0.1]) by lurkie.xs4all.nl (8.12.9/8.12.9) with ESMTP id j9CLY9cq028238 for ; Wed, 12 Oct 2005 23:34:09 +0200 (CEST) (envelope-from fbsd@lurkie.xs4all.nl) Received: (from fbsd@localhost) by lurkie.xs4all.nl (8.12.9/8.12.9/Submit) id j9CLY8FX028237 for freebsd-current@freebsd.org; Wed, 12 Oct 2005 23:34:08 +0200 (CEST) Date: Wed, 12 Oct 2005 23:34:08 +0200 From: Marc Veldman To: freebsd-current@freebsd.org Message-ID: <20051012213408.GA28187@lurkie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: NO_TOOLCHAIN broken in -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, 12 Oct 2005 21:41:33 -0000 Hello, is the NO_TOOLCHAIN option broken in -current ? without NO_TOOLCHAIN in make.conf buildworld runs just fine, with it it fails as below: -current cvsupped today. -removed /usr/obj/ -time synced. Below the relevant error messages and my make.conf: make.conf: CFLAGS= -O -pipe COPTFLAGS= -O -pipe KERNCONF= KWETAL NO_TOOLCHAIN=YES I ran into this when building a nanobsd image. Same error message. Building nanobsd image runs after removing NO_TOOLCHAIN. Any ideas ? error message: mkdep -f .depend -a -DCRT_BEGIN -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/usr/src/gnu /lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /usr/src/gnu/lib/csu/../.. /../contrib/gcc/crtstuff.c In file included from /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:62: /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:44:20: stddef.h: No such fil e or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:45:19: float.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:76:20: stdarg.h: No such fil e or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:79:19: stdio.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:85:19: errno.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:92:20: string.h: No such fil e or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:93:20: stdlib.h: No such fil e or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:94:20: unistd.h: No such fil e or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:97:20: limits.h: No such fil e or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:100:18: time.h: No such file or directory mkdep: compile failed *** Error code 1 Cheers, Marc Veldman. From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 21:48:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3355A16A41F for ; Wed, 12 Oct 2005 21:48:34 +0000 (GMT) (envelope-from dan@langille.org) Received: from m21.unixathome.org (m21.unixathome.org [205.150.199.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id A75C843D46 for ; Wed, 12 Oct 2005 21:48:33 +0000 (GMT) (envelope-from dan@langille.org) Received: from localhost (localhost [205.150.199.217]) by m21.unixathome.org (Postfix) with ESMTP id 28292BFB6 for ; Wed, 12 Oct 2005 17:48:33 -0400 (EDT) Received: from m21.unixathome.org ([205.150.199.217]) by localhost (m21.unixathome.org [205.150.199.217]) (amavisd-new, port 10024) with ESMTP id 11224-05 for ; Wed, 12 Oct 2005 17:48:32 -0400 (EDT) Received: from bast.unixathome.org (bast.unixathome.org [70.26.229.230]) by m21.unixathome.org (Postfix) with ESMTP id 48D5FBFB0 for ; Wed, 12 Oct 2005 17:48:32 -0400 (EDT) Received: from wocker (wocker.unixathome.org [10.55.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 1176C3D3B for ; Wed, 12 Oct 2005 17:48:32 -0400 (EDT) From: "Dan Langille" To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2005 17:48:31 -0400 MIME-Version: 1.0 Message-ID: <434D4C6F.13645.7C3DD17D@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at unixathome.org Subject: ad0 errors on 6.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: Wed, 12 Oct 2005 21:48:34 -0000 I'm seeing these errors but I do not know if it's an HDD problem or an OS problem. Clues please? The following was also posted at http://pastebin.com/391670 Oct 11 03:40:00 mtwenty kernel: ad0: FAILURE - READ_DMA status=7f error=7f LBA=802719 Oct 11 03:40:00 mtwenty kernel: g_vfs_done():ad0s1a[READ(offset=410959872, length=16384)]error = 5 Oct 11 03:40:06 mtwenty kernel: ad0: FAILURE - READ_DMA status=7f error=7f LBA=802175 Oct 11 03:40:06 mtwenty kernel: g_vfs_done():ad0s1a[READ(offset=410681344, length=8192)]error = 5 Oct 11 03:40:06 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=4857391 Oct 11 03:40:01 mtwenty cron[82160]: login_getclass: retrieving class information: Input/output error Oct 11 03:44:49 mtwenty kernel: ad0: FAILURE - READ_DMA status=7f error=7f LBA=151787983 Oct 11 03:44:49 mtwenty kernel: g_vfs_done():ad0s1f[READ(offset=74097885184, length=14336)]error = 5 Oct 11 03:44:56 mtwenty kernel: ad0: FAILURE - WRITE_DMA status=7f error=7f LBA=4857391 Oct 11 03:44:56 mtwenty kernel: g_vfs_done():ad0s1d[WRITE(offset=969719808, length=10240)]error = 5 Oct 11 03:44:56 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=92997387 Oct 11 03:55:07 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=4092687 Oct 11 13:04:08 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=4092687 Oct 11 13:52:08 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=4092687 Oct 11 13:55:07 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=4092687 Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command Oct 11 13:55:33 mtwenty kernel: g_vfs_done():ad0s1f[WRITE(offset=42777804800, length=16384)]error = 5 Oct 11 13:55:33 mtwenty kernel: g_vfs_done():ad0s1f[WRITE(offset=43163189248, length=16384)]error = 5 Oct 11 13:55:33 mtwenty kernel: g_vfs_done():ad0s1a[WRITE(offset=131072, length=16384)]error = 5 Oct 11 13:55:33 mtwenty kernel: g_vfs_done():ad0s1a[WRITE(offset=147456, length=16384)]error = 5 Oct 11 13:55:38 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=786815 Oct 11 15:44:31 mtwenty shutdown: reboot by dan: Oct 11 16:13:03 mtwenty su: dan to root on /dev/ttyp1 Oct 11 19:51:04 mtwenty kernel: ad0: timeout waiting to issue command Oct 11 19:51:09 mtwenty kernel: ad0: error issueing WRITE_DMA command Oct 11 19:51:09 mtwenty kernel: ad0: timeout waiting to issue command Oct 11 19:51:09 mtwenty kernel: ad0: error issueing WRITE_DMA command Oct 11 19:51:09 mtwenty kernel: g_vfs_done():ad0s1f[WRITE(offset=49576368128, length=2048)]error = 5 Oct 11 19:51:09 mtwenty kernel: g_vfs_done():ad0s1f[WRITE(offset=49767104512, length=16384)]error = 5 Oct 11 19:51:09 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=104266895 Oct 11 20:17:45 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=319 Oct 12 17:23:37 mtwenty syslogd: kernel boot file is /boot/kernel/kernel Oct 12 17:23:37 mtwenty kernel: g_vfs_done():ad0s1d[WRITE(offset=969867264, length=8192)]error = 6 Oct 12 17:23:37 mtwenty kernel: g_vfs_done():ad0s1d[WRITE(offset=963559424, length=16384)]error = 6 Oct 12 17:23:37 mtwenty kernel: unknown: TIMEOUT - READ_DMA retrying (0 retries left) LBA=153118463 Oct 12 17:23:37 mtwenty kernel: unknown: FAILURE - READ_DMA timed out LBA=153118463 Oct 12 17:23:37 mtwenty kernel: g_vfs_done():ad0s1f[READ(offset=74779090944, length=2048)]error = 5 Oct 12 17:23:37 mtwenty kernel: g_vfs_done():ad0s1f[READ(offset=74779097088, length=2048)]error = 6 Oct 12 17:23:37 mtwenty kernel: g_vfs_done():ad0s1f[READ(offset=74202345472, length=2048)]error = 6 Oct 12 17:23:37 mtwenty kernel: g_vfs_done():ad0s1f[READ(offset=75589498880, length=2048)]error = 6 Thanks -- Dan Langille : http://www.langille.org/ BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 21:57:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE5616A420 for ; Wed, 12 Oct 2005 21:57:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47DD843D48 for ; Wed, 12 Oct 2005 21:57:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1BAFC1A3C29; Wed, 12 Oct 2005 14:57:16 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2F1AC511FE; Wed, 12 Oct 2005 17:57:13 -0400 (EDT) Date: Wed, 12 Oct 2005 17:57:12 -0400 From: Kris Kennaway To: Marc Veldman Message-ID: <20051012215712.GA93539@xor.obsecurity.org> References: <20051012213408.GA28187@lurkie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20051012213408.GA28187@lurkie.xs4all.nl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: NO_TOOLCHAIN broken in -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, 12 Oct 2005 21:57:16 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2005 at 11:34:08PM +0200, Marc Veldman wrote: > Hello, >=20 > is the NO_TOOLCHAIN option broken in -current ? Someone else complained previously, so probably yes. Kris --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDTYa4Wry0BWjoQKURAtHcAKCZ+V6Cxi7HgbBdgBVd2IyH5Bf2twCeI78O qgBTpZMuTbO4/2BaVyQRrYU= =J3Oo -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 22:02:02 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3174016A41F; Wed, 12 Oct 2005 22:02:02 +0000 (GMT) (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 B3D0C43D45; Wed, 12 Oct 2005 22:02:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CM20Nr045534; Wed, 12 Oct 2005 18:02:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CM20bb094703; Wed, 12 Oct 2005 18:02:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A5AE67302F; Wed, 12 Oct 2005 18:02:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051012220200.A5AE67302F@freebsd-current.sentex.ca> Date: Wed, 12 Oct 2005 18:02:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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, 12 Oct 2005 22:02:02 -0000 TB --- 2005-10-12 20:28:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-12 20:28:17 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-10-12 20:28:17 - cleaning the object tree TB --- 2005-10-12 20:28:41 - checking out the source tree TB --- 2005-10-12 20:28:41 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-10-12 20:28:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-12 20:35:08 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-12 20:35:08 - cd /src TB --- 2005-10-12 20:35:08 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-12 21:39:15 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-12 21:39:15 - cd /src TB --- 2005-10-12 21:39:15 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Oct 12 21:39:16 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Wed Oct 12 21:54:19 UTC 2005 TB --- 2005-10-12 21:54:19 - generating LINT kernel config TB --- 2005-10-12 21:54:19 - cd /src/sys/pc98/conf TB --- 2005-10-12 21:54:19 - /usr/bin/make -B LINT TB --- 2005-10-12 21:54:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-12 21:54:19 - cd /src TB --- 2005-10-12 21:54:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 12 21:54:19 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_sem.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_socket.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_socket2.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/uipc_usrreq.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/kern/vfs_aio.c /src/sys/kern/vfs_aio.c: In function `lio_listio': /src/sys/kern/vfs_aio.c:1990: warning: 's' might be used uninitialized in this function *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-12 22:02:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-12 22:02:00 - ERROR: failed to build lint kernel TB --- 2005-10-12 22:02:00 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 23:02:30 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFE0016A41F; Wed, 12 Oct 2005 23:02:30 +0000 (GMT) (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 68C5043D45; Wed, 12 Oct 2005 23:02:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CN2TVk048986; Wed, 12 Oct 2005 19:02:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CN2TOB041168; Wed, 12 Oct 2005 19:02:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D879E7302F; Wed, 12 Oct 2005 19:02:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051012230228.D879E7302F@freebsd-current.sentex.ca> Date: Wed, 12 Oct 2005 19:02:28 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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, 12 Oct 2005 23:02:31 -0000 TB --- 2005-10-12 22:02:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-12 22:02:00 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-10-12 22:02:00 - cleaning the object tree TB --- 2005-10-12 22:02:26 - checking out the source tree TB --- 2005-10-12 22:02:26 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-10-12 22:02:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-12 22:09:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-12 22:09:29 - cd /src TB --- 2005-10-12 22:09:29 - /usr/bin/make -B buildworld >>> 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 [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -o savecore savecore.o -lz gzip -cn /src/sbin/savecore/savecore.8 > savecore.8.gz ===> sbin/setkey (all) cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/setkey/setkey.c cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c parse.c /src/sbin/setkey/parse.y: In function `setkeymsg_add': /src/sbin/setkey/parse.y:1023: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/sbin/setkey/parse.y:1039: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/sbin/setkey. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-12 23:02:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-12 23:02:28 - ERROR: failed to build world TB --- 2005-10-12 23:02:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 23:42:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D3616A41F for ; Wed, 12 Oct 2005 23:42:06 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A54643D45 for ; Wed, 12 Oct 2005 23:42:03 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 12 Oct 2005 23:42:02 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp031) with SMTP; 13 Oct 2005 01:42:02 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 01:41:50 +0200 User-Agent: KMail/1.8.1 References: <17229.22291.792602.879249@grasshopper.cs.duke.edu> In-Reply-To: <17229.22291.792602.879249@grasshopper.cs.duke.edu> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1164855.E4XSHjdKjO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510130142.01000@harrymail> X-Y-GMX-Trusted: 0 Cc: Andrew Gallatin Subject: Re: Ugly BETA5 crashes, VM fault (with trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 23:42:06 -0000 --nextPart1164855.E4XSHjdKjO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Mittwoch, 12. Oktober 2005 20:33 CEST schrieb Andrew Gallatin: > Can you start gdb on your kernel.debug, and > show the output of: "list *vm_page_cowsetup+0x2e" > > Thanks, Thank you for the hint, unfortunately I rebuilt my kernel (very_late=20 BETA5->RC1) and forgot that kernel.debug won't be in /boot/kernel.old. But from the new kernel.debug I get something (to me) senseful: builder_cale:usr/src/sys/CALE#11: gdb kernel.debug 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=20 are welcome to change it and/or distribute copies of it under certain=20 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"... (gdb) list *vm_page_cowsetup+0x2e 0xc06fd7be is in vm_page_cowsetup (/usr/src/sys/vm/vm_page.c:1699). 1694 void 1695 vm_page_cowsetup(vm_page_t m) 1696 { 1697 1698 mtx_assert(&vm_page_queue_mtx, MA_OWNED); 1699 m->cow++; 1700 pmap_page_protect(m, VM_PROT_READ); 1701 } 1702 1703 #include "opt_ddb.h" (gdb) =20 Thanks! And Robert Watson's assumption is correct: I'm using=20 zero_copy_sockets. My HW is really underdimensioned/oldfashioned so I tried to squeeze out the= =20 last thing possible ;) =2DHarry --nextPart1164855.E4XSHjdKjO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD4DBQBDTZ9IBylq0S4AzzwRApHfAJ0deewYbw/jS3LyHFxYYzs+2swXNwCY8wG+ BIZbIXGPXHIuBkytuHqzcA== =MZgH -----END PGP SIGNATURE----- --nextPart1164855.E4XSHjdKjO-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 23:48:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2028C16A41F for ; Wed, 12 Oct 2005 23:48:18 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E67243D48 for ; Wed, 12 Oct 2005 23:48:16 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 12 Oct 2005 23:48:15 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp007) with SMTP; 13 Oct 2005 01:48:15 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 01:48:09 +0200 User-Agent: KMail/1.8.1 References: <200510121250.20515@harrymail> <20051012153407.W48006@fledge.watson.org> In-Reply-To: <20051012153407.W48006@fledge.watson.org> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200510130148.14383@harrymail> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Robert Watson Subject: Re: Ugly BETA5 crashes, VM fault (with trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2005 23:48:18 -0000 Am Mittwoch, 12. Oktober 2005 16:34 CEST schrieb Robert Watson: > On Wed, 12 Oct 2005, Emanuel Strobl wrote: > > my desktop box crashed for severla weeks every few days and since > > beta5 was withoug kdb I had to rebuild a debugging kernel to get this > > recorded (no dump was written, so nothing in /var/crash) Like > > mentioned, I see the crash every view days, I think when having > > simultaniously NFS and local disk load. Please tell me if I can > > provide more info! > > I take it you have zero-copy sockets enabled? Do the panics happen if > you don't have it enabled? Yes, you are right, I have zero-copy sockets enabled (I don't have decent HW so I tried to gain as much as possible options I don't really understand... :() I'll rebuild a debug kernel without zero_copy_sockets and see if it happens again, but as I wrote the crash happens only every few days, possibly not within the next whole week... But I'll remove it and keep you informed... Thanks, -Harry > > Robert N M Watson > > > -Harry > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x5a > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc06ec5a9 > > stack pointer = 0x28:0xdad2c99c > > frame pointer = 0x28:0xdad2ca88 > > 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 = 741 (kdeinit) > > [thread pid 741 tid 100102 ] > > Stopped at vm_fault+0x239: cmpw $0,0x5a(%eax) > > db> trace > > Tracing pid 741 tid 100102 td 0xc2470a80 > > vm_fault(c1443000,c144f000,2,0,c2470a80) at vm_fault+0x239 > > trap_pfault(dad2cb14,0,c144fff4,dad2cae8,c144fff4) at > > trap_pfault+0x156 trap(c0790008,28,c0850028,dad2ccb4,2000) at > > trap+0x38e > > calltrap() at calltrap+0x5 > > --- trap 0xc, eip = 0xc06fd0ce, esp = 0xdad2cb54, ebp = 0xdad2cb68 --- > > vm_page_cowsetup(c144ffb8,0,c079615b,82,dad2cbf4) at > > vm_page_cowsetup+0x2e socow_setup(c1ef2300,dad2ccb4,2,2c4,1) at > > socow_setup+0x98 > > sosend(c29f4858,0,dad2ccb4,0,0) at sosend+0x56b > > soo_write(c284d090,dad2ccb4,c26f5980,0,c2470a80) at soo_write+0x87 > > dofilewrite(c2470a80,f,c284d090,dad2ccb4,ffffffff) at dofilewrite+0x85 > > kern_writev(c2470a80,f,dad2ccb4,8100ff4,de10) at kern_writev+0x65 > > write(c2470a80,dad2cd04,c,422,3) at write+0x4f > > syscall(805003b,3b,bfbf003b,805c000,f) at syscall+0x2c0 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (4, FreeBSD ELF32, write), eip = 0x293791ab, esp = > > 0xbfbfe15c, ebp = > > 0xbfbfe178 --- > > db> > From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 23:58:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA47116A41F for ; Wed, 12 Oct 2005 23:58:30 +0000 (GMT) (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 31E4343D49 for ; Wed, 12 Oct 2005 23:58:30 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CNwTZd052279 for ; Wed, 12 Oct 2005 19:58:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.4/8.13.4) with ESMTP id j9CNwT0P081912; Wed, 12 Oct 2005 19:58:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j9CNwQHZ094197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 19:58:27 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20051012195634.09089d78@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 12 Oct 2005 19:58:43 -0400 To: "Dan Langille" , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <434D4C6F.13645.7C3DD17D@localhost> References: <434D4C6F.13645.7C3DD17D@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.53 on 64.7.153.21 Cc: Subject: Re: ad0 errors on 6.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: Wed, 12 Oct 2005 23:58:30 -0000 At 05:48 PM 12/10/2005, Dan Langille wrote: >I'm seeing these errors but I do not know if it's an HDD problem >or an OS problem. Clues please? They look like hard errors, but I have seen similar problems with bad drive trays. smartmontools out of the ports will help you narrow it down. (eg check the output of smartctl -a /dev/ad0). ---Mike >The following was also posted at http://pastebin.com/391670 > >Oct 11 03:40:00 mtwenty kernel: ad0: FAILURE - READ_DMA >status=7f >error=7f,ILLEGAL_LENGTH> LBA=802719 >Oct 11 03:40:00 mtwenty kernel: >g_vfs_done():ad0s1a[READ(offset=410959872, length=16384)]error = 5 >Oct 11 03:40:06 mtwenty kernel: ad0: FAILURE - READ_DMA >status=7f >error=7f,ILLEGAL_LENGTH> LBA=802175 >Oct 11 03:40:06 mtwenty kernel: >g_vfs_done():ad0s1a[READ(offset=410681344, length=8192)]error = 5 >Oct 11 03:40:06 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=4857391 >Oct 11 03:40:01 mtwenty cron[82160]: login_getclass: retrieving >class information: Input/output error >Oct 11 03:44:49 mtwenty kernel: ad0: FAILURE - READ_DMA >status=7f >error=7f,ILLEGAL_LENGTH> LBA=151787983 >Oct 11 03:44:49 mtwenty kernel: >g_vfs_done():ad0s1f[READ(offset=74097885184, length=14336)]error = 5 >Oct 11 03:44:56 mtwenty kernel: ad0: FAILURE - WRITE_DMA >status=7f >error=7fA,ILLEGAL_LENGTH> LBA=4857391 >Oct 11 03:44:56 mtwenty kernel: >g_vfs_done():ad0s1d[WRITE(offset=969719808, length=10240)]error = 5 >Oct 11 03:44:56 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=92997387 >Oct 11 03:55:07 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=4092687 >Oct 11 13:04:08 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=4092687 >Oct 11 13:52:08 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=4092687 >Oct 11 13:55:07 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=4092687 >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command >Oct 11 13:55:33 mtwenty kernel: >g_vfs_done():ad0s1f[WRITE(offset=42777804800, length=16384)]error = 5 >Oct 11 13:55:33 mtwenty kernel: >g_vfs_done():ad0s1f[WRITE(offset=43163189248, length=16384)]error = 5 >Oct 11 13:55:33 mtwenty kernel: >g_vfs_done():ad0s1a[WRITE(offset=131072, length=16384)]error = 5 >Oct 11 13:55:33 mtwenty kernel: >g_vfs_done():ad0s1a[WRITE(offset=147456, length=16384)]error = 5 >Oct 11 13:55:38 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=786815 >Oct 11 15:44:31 mtwenty shutdown: reboot by dan: > >Oct 11 16:13:03 mtwenty su: dan to root on /dev/ttyp1 >Oct 11 19:51:04 mtwenty kernel: ad0: timeout waiting to issue command >Oct 11 19:51:09 mtwenty kernel: ad0: error issueing WRITE_DMA command >Oct 11 19:51:09 mtwenty kernel: ad0: timeout waiting to issue command >Oct 11 19:51:09 mtwenty kernel: ad0: error issueing WRITE_DMA command >Oct 11 19:51:09 mtwenty kernel: >g_vfs_done():ad0s1f[WRITE(offset=49576368128, length=2048)]error = 5 >Oct 11 19:51:09 mtwenty kernel: >g_vfs_done():ad0s1f[WRITE(offset=49767104512, length=16384)]error = 5 >Oct 11 19:51:09 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=104266895 >Oct 11 20:17:45 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 >retry left) LBA=319 >Oct 12 17:23:37 mtwenty syslogd: kernel boot file is /boot/kernel/kernel >Oct 12 17:23:37 mtwenty kernel: >g_vfs_done():ad0s1d[WRITE(offset=969867264, length=8192)]error = 6 >Oct 12 17:23:37 mtwenty kernel: >g_vfs_done():ad0s1d[WRITE(offset=963559424, length=16384)]error = 6 >Oct 12 17:23:37 mtwenty kernel: unknown: TIMEOUT - READ_DMA retrying >(0 retries left) LBA=153118463 >Oct 12 17:23:37 mtwenty kernel: unknown: FAILURE - READ_DMA timed >out LBA=153118463 >Oct 12 17:23:37 mtwenty kernel: >g_vfs_done():ad0s1f[READ(offset=74779090944, length=2048)]error = 5 >Oct 12 17:23:37 mtwenty kernel: >g_vfs_done():ad0s1f[READ(offset=74779097088, length=2048)]error = 6 >Oct 12 17:23:37 mtwenty kernel: >g_vfs_done():ad0s1f[READ(offset=74202345472, length=2048)]error = 6 >Oct 12 17:23:37 mtwenty kernel: >g_vfs_done():ad0s1f[READ(offset=75589498880, length=2048)]error = 6 > >Thanks >-- >Dan Langille : http://www.langille.org/ >BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ > > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 01:12:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90DD516A41F for ; Thu, 13 Oct 2005 01:12:59 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from mail24.syd.optusnet.com.au (mail24.syd.optusnet.com.au [211.29.133.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07E0F43D45 for ; Thu, 13 Oct 2005 01:12:58 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from [127.0.0.1] (c220-237-120-88.thorn1.nsw.optusnet.com.au [220.237.120.88]) by mail24.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9D1Cdx8009030 for ; Thu, 13 Oct 2005 11:12:57 +1000 Message-ID: <434DB49C.8030006@mawer.org> Date: Thu, 13 Oct 2005 11:13:00 +1000 From: Antony Mawer User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: unable to debug - corrupt stack? - locking issue on 6.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, 13 Oct 2005 01:12:59 -0000 Hi All, Have been trying to track down the cause of what seems to be a locking problem with 6.0 (present on beta3/4/5 and rc1) with IPX... it manifested itself as flakey Netware connectivity, but appears to be a problem in the IPX locking. We were seeing calls to vn_lock() that got wedged and never returned, and enabling WITNESS resulted in this panic: > [root@davegproxy] /usr/obj/usr/src/sys/GPROXY6$ kgdb kernel.debug /var/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 "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > Sleeping in "ef_output" with the following non-sleepable locks held: > exclusive sleep mutex ipx_mtx r = 0 (0xc186744c) locked @ /usr/src/sys/netipx/ipx_usrreq.c:595 > Sleeping in "ef_output" with the following non-sleepable locks held: > exclusive sleep mutex ipx_mtx r = 0 (0xc186744c) locked @ /usr/src/sys/netipx/ipx_usrreq.c:595 > panic: userret: Returning with 1 locks held. > Uptime: 58s > Dumping 255 MB (3 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 254MB (65008 pages) 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok > chunk 2: 1MB (256 pages) > > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); Trying to get a stack trace from it yields: > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc05d6e34 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xc05d70b2 in panic (fmt=0xc07c3174 "userret: Returning with %d locks held.") at /usr/src/sys/kern/kern_shutdown.c:555 > #3 0xc05f619b in userret (td=0xc1a0f480, frame=0xd142dd38, oticks=25) at /usr/src/sys/kern/subr_trap.c:136 > #4 0xc0767c2d in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 4, tf_esi = 673886912, tf_ebp = -1077942104, tf_isp = -784147100, tf_ebx = 673809636, tf_edx = 0, tf_ecx = 0, tf_eax = 3, tf_trapno = 12, tf_err = 2, tf_eip = 673286039, tf_cs = 51, tf_eflags = 66054, tf_esp = -1077942148, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1026 > #5 0xc07574bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 > #6 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) Can anyone recommend where we go from here? The panic is trivially reproducable simply by enabling IPX with these lines in rc.conf: # Ethernet 802.2 ifconfig_lnc0f2_ipx="ipx 0x2" ipxrouted_enable="YES" building a kernel with WITNESS enabled, and then booting. During bootup the system then panics... if you add WITNESS_SKIPSPIN then the problem doesn't appear to manifest itself until a Netware volume is mounted. Any help on how to get a more useful stack trace or tackling the "Sleeping with non-sleepable locks held" errors would be greatly appreciated!! Cheers Antony From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 01:54:43 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8E6416A41F for ; Thu, 13 Oct 2005 01:54:43 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD2143D45 for ; Thu, 13 Oct 2005 01:54:43 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9D1sYr6049978; Wed, 12 Oct 2005 18:54:38 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510130154.j9D1sYr6049978@gw.catspoiler.org> Date: Wed, 12 Oct 2005 18:54:34 -0700 (PDT) From: Don Lewis To: fbsd-current@mawer.org In-Reply-To: <434DB49C.8030006@mawer.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: unable to debug - corrupt stack? - locking issue on 6.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, 13 Oct 2005 01:54:44 -0000 On 13 Oct, Antony Mawer wrote: > Hi All, > > Have been trying to track down the cause of what seems to be a locking > problem with 6.0 (present on beta3/4/5 and rc1) with IPX... it > manifested itself as flakey Netware connectivity, but appears to be a > problem in the IPX locking. We were seeing calls to vn_lock() that got > wedged and never returned, and enabling WITNESS resulted in this panic: > >> [root@davegproxy] /usr/obj/usr/src/sys/GPROXY6$ kgdb kernel.debug /var/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 "i386-marcel-freebsd". >> >> Unread portion of the kernel message buffer: >> Sleeping in "ef_output" with the following non-sleepable locks held: >> exclusive sleep mutex ipx_mtx r = 0 (0xc186744c) locked @ /usr/src/sys/netipx/ipx_usrreq.c:595 >> Sleeping in "ef_output" with the following non-sleepable locks held: >> exclusive sleep mutex ipx_mtx r = 0 (0xc186744c) locked @ /usr/src/sys/netipx/ipx_usrreq.c:595 >> panic: userret: Returning with 1 locks held. >> Uptime: 58s >> Dumping 255 MB (3 chunks) >> chunk 0: 1MB (159 pages) ... ok >> chunk 1: 254MB (65008 pages) 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok >> chunk 2: 1MB (256 pages) >> >> #0 doadump () at pcpu.h:165 >> 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > Trying to get a stack trace from it yields: > >> (kgdb) bt >> #0 doadump () at pcpu.h:165 >> #1 0xc05d6e34 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 >> #2 0xc05d70b2 in panic (fmt=0xc07c3174 "userret: Returning with %d locks held.") at /usr/src/sys/kern/kern_shutdown.c:555 >> #3 0xc05f619b in userret (td=0xc1a0f480, frame=0xd142dd38, oticks=25) at /usr/src/sys/kern/subr_trap.c:136 >> #4 0xc0767c2d in syscall (frame= >> {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 4, tf_esi = 673886912, tf_ebp = -1077942104, tf_isp = -784147100, tf_ebx = 673809636, tf_edx = 0, tf_ecx = 0, tf_eax = 3, tf_trapno = 12, tf_err = 2, tf_eip = 673286039, tf_cs = 51, tf_eflags = 66054, tf_esp = -1077942148, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1026 >> #5 0xc07574bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 >> #6 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) > > Can anyone recommend where we go from here? The panic is trivially > reproducable simply by enabling IPX with these lines in rc.conf: > > # Ethernet 802.2 > ifconfig_lnc0f2_ipx="ipx 0x2" > ipxrouted_enable="YES" > > building a kernel with WITNESS enabled, and then booting. During bootup > the system then panics... if you add WITNESS_SKIPSPIN then the problem > doesn't appear to manifest itself until a Netware volume is mounted. > > Any help on how to get a more useful stack trace or tackling the > "Sleeping with non-sleepable locks held" errors would be greatly > appreciated!! Lucky you! I've been trying to reproduce the vnode locking problem for several days without success. There has been one other report of this problem, but IPX does not seem to be involved, so you are probably experiencing two different problems. The panic is caused by INVARIANTS detecting the leaked vnode lock. Can you add the DEBUG_LOCKS and DEBUG_VFS_LOCKS kernel options to see if that catches the problem sooner? The DEBUG_LOCKS option will store in the vnode the location in the code where the vnode was last locked. What sort of hardware is involved, SMP/UP, amount of memory, disks? Any unusual system tuneables or sysctls set? What is running on the system when this panic occurs. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 02:55:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F41C16A41F for ; Thu, 13 Oct 2005 02:55:26 +0000 (GMT) (envelope-from dan@langille.org) Received: from m21.unixathome.org (m21.unixathome.org [205.150.199.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id E233D43D46 for ; Thu, 13 Oct 2005 02:55:25 +0000 (GMT) (envelope-from dan@langille.org) Received: from localhost (localhost [205.150.199.217]) by m21.unixathome.org (Postfix) with ESMTP id D3C4DBFB6; Wed, 12 Oct 2005 22:55:24 -0400 (EDT) Received: from m21.unixathome.org ([205.150.199.217]) by localhost (m21.unixathome.org [205.150.199.217]) (amavisd-new, port 10024) with ESMTP id 24888-03; Wed, 12 Oct 2005 22:55:23 -0400 (EDT) Received: from bast.unixathome.org (bast.unixathome.org [70.26.229.230]) by m21.unixathome.org (Postfix) with ESMTP id 2AF1DBFB0; Wed, 12 Oct 2005 22:55:22 -0400 (EDT) Received: from wocker (wocker.unixathome.org [10.55.0.99]) by bast.unixathome.org (Postfix) with ESMTP id CE9673D3B; Wed, 12 Oct 2005 22:55:22 -0400 (EDT) From: "Dan Langille" To: Mike Tancsa Date: Wed, 12 Oct 2005 22:55:22 -0400 MIME-Version: 1.0 Message-ID: <434D945A.11685.7D56BDCF@localhost> Priority: normal In-reply-to: <6.2.3.4.0.20051012195634.09089d78@64.7.153.2> References: <434D4C6F.13645.7C3DD17D@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at unixathome.org Cc: freebsd-current@freebsd.org Subject: Re: ad0 errors on 6.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: Thu, 13 Oct 2005 02:55:26 -0000 On 12 Oct 2005 at 19:58, Mike Tancsa wrote: > At 05:48 PM 12/10/2005, Dan Langille wrote: > >I'm seeing these errors but I do not know if it's an HDD problem > >or an OS problem. Clues please? > > They look like hard errors, but I have seen similar problems with bad > drive trays. smartmontools out of the ports will help you narrow it > down. (eg check the output of smartctl -a /dev/ad0). We did that yesterday. I don't know enough about the output to judge, but it seems ok. Also posted to http://pastebin.com/391872 [root@mtwenty:/usr/ports/sysutils/smartmontools] # smartctl -a /dev/ad0 smartctl version 5.33 [i386-portbld-freebsd6.0] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: Maxtor 6Y080L0 Serial Number: Y3KLWA7E Firmware Version: YAR41BW0 User Capacity: 81,964,302,336 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0 Local Time is: Tue Oct 11 08:45:22 2005 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x80) Offline data collection activity was never started. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 182) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. No General Purpose Logging support. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 40) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 3 Spin_Up_Time 0x0027 200 200 063 Pre-fail Always - 16714 4 Start_Stop_Count 0x0032 253 253 000 Old_age Always - 77 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0 6 Read_Channel_Margin 0x0001 253 253 100 Pre-fail Offline - 0 7 Seek_Error_Rate 0x000a 253 252 000 Old_age Always - 0 8 Seek_Time_Performance 0x0027 251 247 187 Pre-fail Always - 36405 9 Power_On_Minutes 0x0032 243 243 000 Old_age Always - 317h+56m 10 Spin_Retry_Count 0x002b 253 252 157 Pre-fail Always - 0 11 Calibration_Retry_Count 0x002b 253 252 223 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 253 253 000 Old_age Always - 84 192 Power-Off_Retract_Count 0x0032 253 253 000 Old_age Always - 0 193 Load_Cycle_Count 0x0032 253 253 000 Old_age Always - 0 194 Temperature_Celsius 0x0032 253 253 000 Old_age Always - 36 195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 3036 196 Reallocated_Event_Count 0x0008 253 253 000 Old_age Offline - 0 197 Current_Pending_Sector 0x0008 253 253 000 Old_age Offline - 0 198 Offline_Uncorrectable 0x0008 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0008 198 196 000 Old_age Offline - 4 200 Multi_Zone_Error_Rate 0x000a 253 252 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 4 202 TA_Increase_Count 0x000a 253 252 000 Old_age Always - 0 203 Run_Out_Cancel 0x000b 253 252 180 Pre-fail Always - 0 204 Shock_Count_Write_Opern 0x000a 253 252 000 Old_age Always - 0 205 Shock_Rate_Write_Opern 0x000a 253 252 000 Old_age Always - 0 207 Spin_High_Current 0x002a 253 252 000 Old_age Always - 0 208 Spin_Buzz 0x002a 253 252 000 Old_age Always - 0 209 Offline_Seek_Performnce 0x0024 198 198 000 Old_age Offline - 0 99 Unknown_Attribute 0x0004 253 253 000 Old_age Offline - 0 100 Unknown_Attribute 0x0004 253 253 000 Old_age Offline - 0 101 Unknown_Attribute 0x0004 253 253 000 Old_age Offline - 0 SMART Error Log Version: 1 ATA Error Count: 4 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 4 occurred at disk power-on lifetime: 3332 hours (138 days + 20 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 38 1f a2 e0 Error: ICRC, ABRT at LBA = 0x00a21f38 = 10624824 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 37 38 1f a2 e0 08 00:06:15.120 READ DMA c8 00 09 2f 1f a2 e0 08 00:06:15.120 READ DMA c8 00 36 f9 1e a2 e0 08 00:06:15.120 READ DMA c8 00 0a ef 1e a2 e0 08 00:06:15.120 READ DMA c8 00 35 ba 1e a2 e0 08 00:06:15.120 READ DMA Error 3 occurred at disk power-on lifetime: 3332 hours (138 days + 20 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 ba 1e a2 e0 Error: ICRC, ABRT at LBA = 0x00a21eba = 10624698 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 35 ba 1e a2 e0 08 00:06:15.056 READ DMA c8 00 0b af 1e a2 e0 08 00:06:15.056 READ DMA c8 00 34 7b 1e a2 e0 08 00:06:15.056 READ DMA c8 00 0c 6f 1e a2 e0 08 00:06:15.056 READ DMA c8 00 02 6f 1e a2 e0 08 00:06:15.056 READ DMA Error 2 occurred at disk power-on lifetime: 3332 hours (138 days + 20 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 c1 aa a2 e0 Error: ICRC, ABRT at LBA = 0x00a2aac1 = 10660545 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 3e c1 aa a2 e0 08 00:06:14.880 READ DMA c8 00 02 bf aa a2 e0 08 00:06:14.880 READ DMA c8 00 34 0b 3b 53 e0 08 00:06:14.880 READ DMA c8 00 0c ff 3a 53 e0 08 00:06:14.880 READ DMA c8 00 01 7e 00 00 e0 08 00:06:14.880 READ DMA Error 1 occurred at disk power-on lifetime: 3332 hours (138 days + 20 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 79 96 0e e0 Error: ICRC, ABRT at LBA = 0x000e9679 = 956025 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 16 79 96 0e e0 08 00:06:14.736 READ DMA c8 00 2a 4f 96 0e e0 08 00:06:14.736 READ DMA c8 00 02 33 54 53 e0 08 00:06:14.736 READ DMA c8 00 08 f7 aa a2 e0 08 00:06:14.736 READ DMA c8 00 08 f7 aa a2 e0 08 00:06:14.736 READ DMA SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 3370 - # 2 Short offline Completed without error 00% 7 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. [root@mtwenty:/usr/ports/sysutils/smartmontools] # > > ---Mike > > > >The following was also posted at http://pastebin.com/391670 > > > >Oct 11 03:40:00 mtwenty kernel: ad0: FAILURE - READ_DMA > >status=7f > >error=7f >,ILLEGAL_LENGTH> LBA=802719 > >Oct 11 03:40:00 mtwenty kernel: > >g_vfs_done():ad0s1a[READ(offset=410959872, length=16384)]error = 5 > >Oct 11 03:40:06 mtwenty kernel: ad0: FAILURE - READ_DMA > >status=7f > >error=7f >,ILLEGAL_LENGTH> LBA=802175 > >Oct 11 03:40:06 mtwenty kernel: > >g_vfs_done():ad0s1a[READ(offset=410681344, length=8192)]error = 5 > >Oct 11 03:40:06 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=4857391 > >Oct 11 03:40:01 mtwenty cron[82160]: login_getclass: retrieving > >class information: Input/output error > >Oct 11 03:44:49 mtwenty kernel: ad0: FAILURE - READ_DMA > >status=7f > >error=7f >,ILLEGAL_LENGTH> LBA=151787983 > >Oct 11 03:44:49 mtwenty kernel: > >g_vfs_done():ad0s1f[READ(offset=74097885184, length=14336)]error = 5 > >Oct 11 03:44:56 mtwenty kernel: ad0: FAILURE - WRITE_DMA > >status=7f > >error=7f >A,ILLEGAL_LENGTH> LBA=4857391 > >Oct 11 03:44:56 mtwenty kernel: > >g_vfs_done():ad0s1d[WRITE(offset=969719808, length=10240)]error = 5 > >Oct 11 03:44:56 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=92997387 > >Oct 11 03:55:07 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=4092687 > >Oct 11 13:04:08 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=4092687 > >Oct 11 13:52:08 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=4092687 > >Oct 11 13:55:07 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=4092687 > >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command > >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command > >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command > >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command > >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command > >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command > >Oct 11 13:55:33 mtwenty kernel: ad0: timeout waiting to issue command > >Oct 11 13:55:33 mtwenty kernel: ad0: error issueing WRITE_DMA command > >Oct 11 13:55:33 mtwenty kernel: > >g_vfs_done():ad0s1f[WRITE(offset=42777804800, length=16384)]error = 5 > >Oct 11 13:55:33 mtwenty kernel: > >g_vfs_done():ad0s1f[WRITE(offset=43163189248, length=16384)]error = 5 > >Oct 11 13:55:33 mtwenty kernel: > >g_vfs_done():ad0s1a[WRITE(offset=131072, length=16384)]error = 5 > >Oct 11 13:55:33 mtwenty kernel: > >g_vfs_done():ad0s1a[WRITE(offset=147456, length=16384)]error = 5 > >Oct 11 13:55:38 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=786815 > >Oct 11 15:44:31 mtwenty shutdown: reboot by dan: > > > >Oct 11 16:13:03 mtwenty su: dan to root on /dev/ttyp1 > >Oct 11 19:51:04 mtwenty kernel: ad0: timeout waiting to issue command > >Oct 11 19:51:09 mtwenty kernel: ad0: error issueing WRITE_DMA command > >Oct 11 19:51:09 mtwenty kernel: ad0: timeout waiting to issue command > >Oct 11 19:51:09 mtwenty kernel: ad0: error issueing WRITE_DMA command > >Oct 11 19:51:09 mtwenty kernel: > >g_vfs_done():ad0s1f[WRITE(offset=49576368128, length=2048)]error = 5 > >Oct 11 19:51:09 mtwenty kernel: > >g_vfs_done():ad0s1f[WRITE(offset=49767104512, length=16384)]error = 5 > >Oct 11 19:51:09 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=104266895 > >Oct 11 20:17:45 mtwenty kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 > >retry left) LBA=319 > >Oct 12 17:23:37 mtwenty syslogd: kernel boot file is /boot/kernel/kernel > >Oct 12 17:23:37 mtwenty kernel: > >g_vfs_done():ad0s1d[WRITE(offset=969867264, length=8192)]error = 6 > >Oct 12 17:23:37 mtwenty kernel: > >g_vfs_done():ad0s1d[WRITE(offset=963559424, length=16384)]error = 6 > >Oct 12 17:23:37 mtwenty kernel: unknown: TIMEOUT - READ_DMA retrying > >(0 retries left) LBA=153118463 > >Oct 12 17:23:37 mtwenty kernel: unknown: FAILURE - READ_DMA timed > >out LBA=153118463 > >Oct 12 17:23:37 mtwenty kernel: > >g_vfs_done():ad0s1f[READ(offset=74779090944, length=2048)]error = 5 > >Oct 12 17:23:37 mtwenty kernel: > >g_vfs_done():ad0s1f[READ(offset=74779097088, length=2048)]error = 6 > >Oct 12 17:23:37 mtwenty kernel: > >g_vfs_done():ad0s1f[READ(offset=74202345472, length=2048)]error = 6 > >Oct 12 17:23:37 mtwenty kernel: > >g_vfs_done():ad0s1f[READ(offset=75589498880, length=2048)]error = 6 > > > >Thanks > >-- > >Dan Langille : http://www.langille.org/ > >BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ > > > > > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Dan Langille : http://www.langille.org/ BSDCan - The Technical BSD Conference - http://www.bsdcan.org/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 03:09:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46F6C16A41F for ; Thu, 13 Oct 2005 03:09:33 +0000 (GMT) (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 99BA843D45 for ; Thu, 13 Oct 2005 03:09:32 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9D39Vkq062068 for ; Wed, 12 Oct 2005 23:09:31 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.4/8.13.4) with ESMTP id j9D39VI8053364; Wed, 12 Oct 2005 23:09:31 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j9D39Rh0094628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 23:09:29 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20051012230329.06fd61b8@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 12 Oct 2005 23:09:46 -0400 To: "Dan Langille" From: Mike Tancsa In-Reply-To: <434D945A.11685.7D56BDCF@localhost> References: <434D4C6F.13645.7C3DD17D@localhost> <434D945A.11685.7D56BDCF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.53 on 64.7.153.26 Cc: freebsd-current@freebsd.org Subject: Re: ad0 errors on 6.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: Thu, 13 Oct 2005 03:09:33 -0000 At 10:55 PM 12/10/2005, Dan Langille wrote: >We did that yesterday. I don't know enough about the output to >judge, but it seems ok. Also posted to http://pastebin.com/391872 > > Commands leading to the command that caused the error were: > CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name > -- -- -- -- -- -- -- -- ---------------- -------------------- > c8 00 37 38 1f a2 e0 08 00:06:15.120 READ DMA > c8 00 09 2f 1f a2 e0 08 00:06:15.120 READ DMA > c8 00 36 f9 1e a2 e0 08 00:06:15.120 READ DMA > c8 00 0a ef 1e a2 e0 08 00:06:15.120 READ DMA > c8 00 35 ba 1e a2 e0 08 00:06:15.120 READ DMA > >Error 3 occurred at disk power-on lifetime: 3332 hours (138 days + 20 >hours) > When the command that caused the error occurred, the device was in >an unknown state. > > After command completion occurred, registers were: > ER ST SC SN CL CH DH > -- -- -- -- -- -- -- > 84 51 00 ba 1e a2 e0 Error: ICRC, ABRT at LBA = 0x00a21eba = >10624698 > > Commands leading to the command that caused the error were: > CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name > -- -- -- -- -- -- -- -- ---------------- -------------------- > c8 00 35 ba 1e a2 e0 08 00:06:15.056 READ DMA > c8 00 0b af 1e a2 e0 08 00:06:15.056 READ DMA > c8 00 34 7b 1e a2 e0 08 00:06:15.056 READ DMA > c8 00 0c 6f 1e a2 e0 08 00:06:15.056 READ DMA > c8 00 02 6f 1e a2 e0 08 00:06:15.056 READ DMA I think the drive itself is seeing the errors as well. Watch some of the counters and see how they increment over time. Run smartd, and it will record it in real time as well and log it for you. ---Mike From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 06:25:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6715416A41F for ; Thu, 13 Oct 2005 06:25:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E018E43D49 for ; Thu, 13 Oct 2005 06:25:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 653091FFACD; Thu, 13 Oct 2005 08:25:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id DD7991FF9AF; Thu, 13 Oct 2005 08:25:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 2949F158C4; Thu, 13 Oct 2005 06:20:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 27013158B8; Thu, 13 Oct 2005 06:20:24 +0000 (UTC) Date: Thu, 13 Oct 2005 06:20:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Marc Veldman In-Reply-To: <20051012215712.GA93539@xor.obsecurity.org> Message-ID: References: <20051012213408.GA28187@lurkie.xs4all.nl> <20051012215712.GA93539@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: NO_TOOLCHAIN broken in -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: Thu, 13 Oct 2005 06:25:10 -0000 On Wed, 12 Oct 2005, Kris Kennaway wrote: > On Wed, Oct 12, 2005 at 11:34:08PM +0200, Marc Veldman wrote: > > Hello, > > > > is the NO_TOOLCHAIN option broken in -current ? > > Someone else complained previously, so probably yes. It's broken for buildworld but it should be ok for installworld. For now that would mean to edit make.conf or change make arguments between build and install targets. I got told that there are people already working on this. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 06:36:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CA4016A41F for ; Thu, 13 Oct 2005 06:36:20 +0000 (GMT) (envelope-from martin@gneto.com) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FA443D46 for ; Thu, 13 Oct 2005 06:36:18 +0000 (GMT) (envelope-from martin@gneto.com) Received: from ua-83-227-181-30.cust.bredbandsbolaget.se ([83.227.181.30] [83.227.181.30]) by mxfep01.bredband.com with ESMTP id <20051013063616.ZSIR9934.mxfep01.bredband.com@ua-83-227-181-30.cust.bredbandsbolaget.se> for ; Thu, 13 Oct 2005 08:36:16 +0200 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by ua-83-227-181-30.cust.bredbandsbolaget.se (Postfix) with ESMTP id 5720B678DC for ; Thu, 13 Oct 2005 08:36:11 +0200 (CEST) Message-ID: <434E005B.70408@gneto.com> Date: Thu, 13 Oct 2005 08:36:11 +0200 From: Martin Nilsson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Adaptec Serial ATA II RAID 1420SA Support (Marvell chip) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 06:36:20 -0000 Adaptec have a new moderateley priced SATA-II 4-port PCI-X fakeraid adapter available. Unfortunateley driver support for decent operating systems is very limited, only binary drivers for a few rather old linux distributions. The chip on the adapter is called AIC-8130 and is also marked Marvell 88SX6541-BCZ, the adaptec Linux driver is called aar81xx. Is there someone here with contacts inside Marvell or Adaptec so that we can get specifications for this chip? I can donate a card and a SATA-II drive to any interested developer if we can obtain specifications. /Martin Nilsson From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 06:56:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01B0D16A41F for ; Thu, 13 Oct 2005 06:56:22 +0000 (GMT) (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 896B743D46 for ; Thu, 13 Oct 2005 06:56:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9D6uK61053365; Thu, 13 Oct 2005 00:56:20 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434E0511.7000704@samsco.org> Date: Thu, 13 Oct 2005 00:56:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Nilsson References: <434E005B.70408@gneto.com> In-Reply-To: <434E005B.70408@gneto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Adaptec Serial ATA II RAID 1420SA Support (Marvell chip) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 06:56:22 -0000 Martin Nilsson wrote: > Adaptec have a new moderateley priced SATA-II 4-port PCI-X fakeraid > adapter available. > > Unfortunateley driver support for decent operating systems is very > limited, only binary drivers for a few rather old linux distributions. > > The chip on the adapter is called AIC-8130 and is also marked Marvell > 88SX6541-BCZ, the adaptec Linux driver is called aar81xx. > > Is there someone here with contacts inside Marvell or Adaptec so that we > can get specifications for this chip? I can donate a card and a SATA-II > drive to any interested developer if we can obtain specifications. > > /Martin Nilsson There are no longer any FreeBSD people doing work for Adaptec. Occasionally I fiddle with aac stuff for them, but I no longer have anything to do with the 'fakeraid' as you call it =-) Getting specs out of Marvell is impossible; it's been tried many times for their previous SATA and network chips, and the result is almost always nothing but frustration. Scott From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 07:38:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F67116A41F for ; Thu, 13 Oct 2005 07:38:53 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4383543D46 for ; Thu, 13 Oct 2005 07:38:53 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=lapdance.yazzy.net) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EPxfJ-0003Pg-W3 for current@freebsd.org; Thu, 13 Oct 2005 09:38:14 +0200 Date: Thu, 13 Oct 2005 07:38:19 +0000 From: Marcin Jessa To: FreeBSD-Current Message-Id: <20051013073819.743b499b.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.2 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: Subject: Strange behaviour of 'w' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 07:38:53 -0000 Hi. I noticed w does not show loged in users. I just cvsuped and recompiled it but it just does not do its intended job. Running as root: :/usr/obj/usr/src/usr.bin/w]# ./w 7:31AM up 7 mins, 0 users, load averages: 0.00, 0.13, 0.10 USER TTY FROM LOGIN@ IDLE WHAT I am not sure why this happens since w seems to be working on my other boxes. System: FreeBSD 6.0-RC1 #12: Wed Oct 12 09:06:40 UTC 2005 /etc/make.conf: CPUTYPE?=pentiumpro CFLAGS= -O -pipe -march=pentiumpro CXXFLAGS+= -O -pipe -march=pentiumpro COPTFLAGS= -O -pipe -march=pentiumpro Cheers, Marcin. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 09:58:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BC0216A41F for ; Thu, 13 Oct 2005 09:58:50 +0000 (GMT) (envelope-from fbsd@lurkie.xs4all.nl) Received: from lurkie.xs4all.nl (lurkie.xs4all.nl [194.109.236.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A89243D46 for ; Thu, 13 Oct 2005 09:58:49 +0000 (GMT) (envelope-from fbsd@lurkie.xs4all.nl) Received: from lurkie.xs4all.nl (localhost [127.0.0.1]) by lurkie.xs4all.nl (8.12.9/8.12.9) with ESMTP id j9D9pOcq033126; Thu, 13 Oct 2005 11:51:24 +0200 (CEST) (envelope-from fbsd@lurkie.xs4all.nl) Received: (from fbsd@localhost) by lurkie.xs4all.nl (8.12.9/8.12.9/Submit) id j9D9pNU6033125; Thu, 13 Oct 2005 11:51:23 +0200 (CEST) Date: Thu, 13 Oct 2005 11:51:22 +0200 From: Marc Veldman To: "Bjoern A. Zeeb" Message-ID: <20051013095122.GA33105@lurkie.xs4all.nl> References: <20051012213408.GA28187@lurkie.xs4all.nl> <20051012215712.GA93539@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: freebsd-current@freebsd.org Subject: Re: NO_TOOLCHAIN broken in -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: Thu, 13 Oct 2005 09:58:50 -0000 On Thu, Oct 13, 2005 at 06:20:24AM +0000, Bjoern A. Zeeb wrote: > > > is the NO_TOOLCHAIN option broken in -current ? > > > > Someone else complained previously, so probably yes. > > It's broken for buildworld but it should be ok for installworld. > For now that would mean to edit make.conf or change make arguments > between build and install targets. > > I got told that there are people already working on this. To follow up on myself: It seems that the following files are the culprits: src/share/mk/bsd.incs.mk Rev. 1.5 src/share/mk/bsd.lib.mk Rev. 1.169 src/secure/lib/libssl/Makefile Rev. 1.23 Reverting to the previous versions of these files fixes the build. Cheers, Marc. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 10:58:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 286AF16A41F for ; Thu, 13 Oct 2005 10:58:44 +0000 (GMT) (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 0FA5743D45 for ; Thu, 13 Oct 2005 10:58:40 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp224-200.lns2.adl4.internode.on.net [203.122.224.200]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9DAwY9g006584 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Oct 2005 20:28:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 20:28:31 +0930 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Message-Id: <200510132028.32070.doconnor@gsoft.com.au> Content-Type: multipart/signed; boundary="nextPart3900826.dgomFnTkAc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Patches for ports to install KLD source X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 10:58:44 -0000 --nextPart3900826.dgomFnTkAc Content-Type: multipart/mixed; boundary="Boundary-01=_X3jTDLokmzkKzcW" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_X3jTDLokmzkKzcW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is a sent of patches for 2 ports (x11/nvidia-server and palm/uppc-kmod= )=20 that have them install the KLD source and gets the KLD's rebuilt with the=20 kernel. Apply the attached patches and do.. mkdir /usr/local/kld /usr/X11R6/kld Then copy the attached Makefile to /usr/local/kld and /usr/X11R6/kld. Unfortunately I don't know a nice way of discovering PREFIX and/or X11BASE= =20 except, say.. make -f /usr/ports/Mk/bsd.port.mk -V PREFIX make -f /usr/ports/Mk/bsd.port.mk -V X11BASE which seems a bit gross.. =46or the nvidia port - I've only tried it on -current so I don't know if i= t=20 will work OK with the other versions it installs on different=20 systems/configurations. =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 --Boundary-01=_X3jTDLokmzkKzcW Content-Type: text/x-diff; charset="us-ascii"; name="nvidia-driver-kld.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="nvidia-driver-kld.diff" diff -Nur /usr/ports/x11/nvidia-driver/Makefile nvidia-driver/Makefile =2D-- /usr/ports/x11/nvidia-driver/Makefile Mon Sep 12 23:14:28 2005 +++ nvidia-driver/Makefile Wed Oct 12 15:36:46 2005 @@ -7,7 +7,7 @@ =20 PORTNAME=3D nvidia-driver PORTVERSION=3D 1.0.${NVVERSION} =2DCATEGORIES=3D x11 +CATEGORIES=3D x11-servers MASTER_SITES=3D http://download.nvidia.com/freebsd/1.0-${NVVERSION}/ \ ftp://download.nvidia.com/freebsd/1.0-${NVVERSION}/ \ http://download1.nvidia.com/freebsd/1.0-${NVVERSION}/ \ @@ -98,6 +98,13 @@ XSERVVERSION!=3D /usr/sbin/pkg_info -O x11-servers/XFree86-4-Server 2>/dev= /null | ${GREP} Server- || /usr/sbin/pkg_info -O x11-servers/xorg-server 2>= /dev/null | ${GREP} server- || true XLIBVERSION!=3D /usr/sbin/pkg_info -O x11/XFree86-4-libraries 2>/dev/null = | ${GREP} libraries- || /usr/sbin/pkg_info -O x11/xorg-libraries 2>/dev/nul= l | ${GREP} libraries- || true =20 +.if !exists(${PREFIX}/kld) +PLIST_SUB+=3D KLD=3D"@comment " +.else +PLIST_SUB+=3D KLD=3D"" +INSTALLKLD=3D +.endif + PLIST_SUB+=3D XSERVVERSION=3D${XSERVVERSION} XLIBVERSION=3D${XLIBVERSION} \ LINUXBASE=3D${LINUXBASE} NVVERSION=3D${NVVERSION} =20 @@ -143,8 +150,18 @@ ${REINPLACE_CMD} 's/define NV_SUPPORT_LINUX_COMPAT/undef NV_SUPPORT_LINUX= _COMPAT/' \ ${WRKSRC}/src/nv-freebsd.h .endif + uuencode -o ${WRKSRC}/src/nv-kernel.o.uu ${WRKSRC}/src/nv-kernel.o nv-ker= nel.o + ${RM} ${WRKSRC}/src/nv-kernel.o =20 post-install: +.if defined(INSTALLKLD) + ${MKDIR} -p ${PREFIX}/kld/nvidia/src + ${CP} ${FILESDIR}/kld-Makefile ${PREFIX}/kld/nvidia/Makefile + ${CP} ${WRKSRC}/src/*.[ch] ${PREFIX}/kld/nvidia/src + ${CP} ${WRKSRC}/src/Makefile ${PREFIX}/kld/nvidia/src + ${CP} ${WRKSRC}/src/nv-kernel.o.uu ${PREFIX}/kld/nvidia/src +.endif + ${LN} -sf libXvMCNVIDIA.so.1 ${PREFIX}/lib/libXvMCNVIDIA_dynamic.so.1 .if ${OSVERSION} < 500000 .for dev in 0 1 2 3 diff -Nur /usr/ports/x11/nvidia-driver/files/kld-Makefile nvidia-driver/fil= es/kld-Makefile =2D-- /usr/ports/x11/nvidia-driver/files/kld-Makefile Thu Jan 1 09:30:00 1= 970 +++ nvidia-driver/files/kld-Makefile Tue Oct 11 14:23:40 2005 @@ -0,0 +1,4 @@ +SUBDIR=3D src + +.include + diff -Nur /usr/ports/x11/nvidia-driver/files/patch-src::Makefile nvidia-dri= ver/files/patch-src::Makefile =2D-- /usr/ports/x11/nvidia-driver/files/patch-src::Makefile Thu Jan 1 09:= 30:00 1970 +++ nvidia-driver/files/patch-src::Makefile Wed Oct 12 15:18:53 2005 @@ -0,0 +1,32 @@ +--- src/Makefile.orig Sat Jul 30 06:38:44 2005 ++++ src/Makefile Tue Oct 11 14:48:48 2005 +@@ -5,25 +5,17 @@ + KMOD=3D nvidia + RMOBJ=3D nv-kernel.o +=20 +-BSDVER!=3D /sbin/sysctl -n kern.osreldate +-.if ${BSDVER} >=3D 500011 +-KMODDIR?=3D /boot/modules +-.endif +- ++NVIDIA_ROOT=3D ${.CURDIR}/.. + SRCS=3D nvidia_ctl.c nvidia_dev.c nvidia_linux.c nvidia_os.c nvidia_os_p= ci.c nvidia_os_registry.c nvidia_pci.c nvidia_subr.c nvidia_sysctl.c=20 + SRCS+=3D device_if.h bus_if.h pci_if.h vnode_if.h + CFLAGS+=3D -I${NVIDIA_ROOT}/src -DNV_MAJOR_VERSION=3D1 -DNV_MINOR_VERSION= =3D0 -DNV_PATCHLEVEL=3D7676=20 + CFLAGS+=3D -D__KERNEL__ -UDEBUG -U_DEBUG -DNDEBUG -O -fno-common -fno-uni= t-at-a-time -minline-all-stringops +=20 + OBJS+=3D ${RMOBJ} ++NO_OBJ=3D true + NOOBJ=3D true +=20 +-beforeinstall: ${KMOD}.ko +- +-${OSOBJ}: ${KMOD}.ko +- ld -r -o $@ ${OBJS:S/${RMOBJ}//} +- +-clean: +- rm -f ${CLEANFILES:S/${RMOBJ}//} ++nv-kernel.o: nv-kernel.o.uu ++ uudecode -o ${.TARGET} ${.ALLSRC} +=20 + .include diff -Nur /usr/ports/x11/nvidia-driver/files/patch-x11::Makefile nvidia-dri= ver/files/patch-x11::Makefile =2D-- /usr/ports/x11/nvidia-driver/files/patch-x11::Makefile Thu Jan 1 09:= 30:00 1970 +++ nvidia-driver/files/patch-x11::Makefile Wed Oct 12 11:53:09 2005 @@ -0,0 +1,9 @@ +--- x11/Makefile.orig Wed Oct 12 11:52:41 2005 ++++ x11/Makefile Wed Oct 12 11:52:48 2005 +@@ -1,5 +1,4 @@ + SUBDIR=3D driver \ +- extension \ +- bin ++ extension +=20 + .include diff -Nur /usr/ports/x11/nvidia-driver/pkg-plist nvidia-driver/pkg-plist =2D-- /usr/ports/x11/nvidia-driver/pkg-plist Wed May 25 01:27:37 2005 +++ nvidia-driver/pkg-plist Wed Oct 12 15:45:25 2005 @@ -44,8 +44,30 @@ %%DIFFS%%%%PORTDOCS%%share/doc/NVIDIA_GLX-1.0/vm_object.c_5.2.diff %%DIFFS%%%%PORTDOCS%%share/doc/NVIDIA_GLX-1.0/device_pager.c_5.2.diff %%PORTDOCS%%@dirrm share/doc/NVIDIA_GLX-1.0 +%%KLD%%@unexec (cd %D/kld/nvidia ; make clean) +%%KLD%%kld/nvidia/src/os-interface.h +%%KLD%%kld/nvidia/src/nvtypes.h +%%KLD%%kld/nvidia/src/nvidia_sysctl.c +%%KLD%%kld/nvidia/src/nvidia_subr.c +%%KLD%%kld/nvidia/src/nvidia_pci.c +%%KLD%%kld/nvidia/src/nvidia_os_registry.c +%%KLD%%kld/nvidia/src/nvidia_os_pci.c +%%KLD%%kld/nvidia/src/nvidia_os.c +%%KLD%%kld/nvidia/src/nvidia_linux.c +%%KLD%%kld/nvidia/src/nvidia_dev.c +%%KLD%%kld/nvidia/src/nvidia_ctl.c +%%KLD%%kld/nvidia/src/nv.h +%%KLD%%kld/nvidia/src/nv-misc.h +%%KLD%%kld/nvidia/src/nv-freebsd.h +%%KLD%%kld/nvidia/src/cpuopsys.h +%%KLD%%kld/nvidia/src/rmretval.h +%%KLD%%kld/nvidia/src/Makefile +%%KLD%%kld/nvidia/src/nv-kernel.o.uu +%%KLD%%kld/nvidia/Makefile +%%KLD%%@dirrm kld/nvidia/src +%%KLD%%@dirrm kld/nvidia %%FREEBSD4%%@cwd /modules =2D%%FREEBSD5%%@cwd /boot/modules +%%FREEBSD5%%@cwd /boot/kernel nvidia.ko %%FREEBSD5%%@unexec kldxref %D %%FREEBSD4%%@cwd /dev --Boundary-01=_X3jTDLokmzkKzcW Content-Type: text/x-diff; charset="us-ascii"; name="sys-modules-kld.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sys-modules-kld.diff" Index: sys/modules/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/CVS-Repository/src/sys/modules/Makefile,v retrieving revision 1.458 diff -u -r1.458 Makefile =2D-- sys/modules/Makefile 3 Oct 2005 07:05:34 -0000 1.458 +++ sys/modules/Makefile 13 Oct 2005 03:02:06 -0000 @@ -181,6 +181,7 @@ ${_pf} \ plip \ ${_pmc} \ + ${_ports} \ portalfs \ ppbus \ ppi \ @@ -498,6 +499,13 @@ _sound=3D sound .endif =20 +PORTPREFIXES?=3D /usr/local /usr/X11R6 +.for d in ${PORTPREFIXES} +.if exists(${d}/kld) +_ports+=3D ../../../../${d}/kld +.endif +.endfor + .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES) SUBDIR=3D${MODULES_OVERRIDE} .endif --Boundary-01=_X3jTDLokmzkKzcW Content-Type: text/x-diff; charset="us-ascii"; name="uppc-kmod-kld.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="uppc-kmod-kld.diff" diff -Nur /usr/ports/palm/uppc-kmod/Makefile uppc-kmod/Makefile =2D-- /usr/ports/palm/uppc-kmod/Makefile Sun Oct 9 12:46:59 2005 +++ uppc-kmod/Makefile Wed Oct 12 15:42:07 2005 @@ -24,6 +24,13 @@ =20 .include =20 +.if !exists(${PREFIX}/kld) +PLIST_SUB+=3D KLD=3D"@comment " +.else +PLIST_SUB+=3D KLD=3D"" +INSTALLKLD=3D +.endif + .if ${OSVERSION} < 500000 BROKEN=3D "Does not build on FreeBSD 4.x" .endif @@ -32,12 +39,13 @@ @${REINPLACE_CMD} -e 's|%%INITIAL_INSTALLDIR%%|${PREFIX}/lib|g' ${BUILD_W= RKSRC}/uppcsetup @${REINPLACE_CMD} -e 's|%%INITIAL_MODDIR%%|${KMODDIR}|g' ${WRKSRC}/uppcse= tup =20 =2Ddo-install: =2D ${INSTALL_PROGRAM} ${WRKSRC}/uppc.ko ${PREFIX}/lib +post-install: ${INSTALL_SCRIPT} ${WRKSRC}/uppcsetup ${PREFIX}/sbin cd ${WRKSRC} && ${INSTALL_MAN} ${MAN4} ${MANPREFIX}/man/man4 =2D =2Dpost-install: +.if defined(INSTALLKLD) + ${MKDIR} ${PREFIX}/kld/uppc + ${CP} ${WRKSRC}/uppc.c ${WRKSRC}/Makefile ${PREFIX}/kld/uppc/ +.endif @${ECHO_CMD} " ****************************************************= ************" @${ECHO_CMD} " * You can run 'uppcsetup' to help configure the devi= ce driver *" @${ECHO_CMD} " * and set up a connection. = *" diff -Nur /usr/ports/palm/uppc-kmod/files/patch-Makefile uppc-kmod/files/pa= tch-Makefile =2D-- /usr/ports/palm/uppc-kmod/files/patch-Makefile Thu Jan 1 09:30:00 19= 70 +++ uppc-kmod/files/patch-Makefile Sun Oct 9 12:55:23 2005 @@ -0,0 +1,10 @@ +--- Makefile.orig Sun Oct 9 12:55:05 2005 ++++ Makefile Sun Oct 9 12:55:11 2005 +@@ -13,6 +13,6 @@ +=20 + CWARNFLAGS=3D -Wall +=20 +-NOMAN=3D ++NO_MAN=3D +=20 + .include diff -Nur /usr/ports/palm/uppc-kmod/pkg-plist uppc-kmod/pkg-plist =2D-- /usr/ports/palm/uppc-kmod/pkg-plist Tue Dec 30 03:03:02 2003 +++ uppc-kmod/pkg-plist Wed Oct 12 15:42:52 2005 @@ -1,2 +1,7 @@ =2Dlib/uppc.ko sbin/uppcsetup +%%KLD%%@unexec (cd %D/kld/uppc ; make clean) +%%KLD%%kld/uppc/uppc.c +%%KLD%%kld/uppc/Makefile +%%KLD%%@dirrm kld/uppc +@cwd /boot/kernel +uppc.ko --Boundary-01=_X3jTDLokmzkKzcW-- --nextPart3900826.dgomFnTkAc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD4DBQBDTj3Y5ZPcIHs/zowRAmcSAJjXZg912VtV4h6souIkXW0RbTcFAJ0aH6vv EPJsXyqle/fQ6OkFpN3ATg== =x/fW -----END PGP SIGNATURE----- --nextPart3900826.dgomFnTkAc-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 11:31:43 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E826C16A41F for ; Thu, 13 Oct 2005 11:31:43 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8851543D45 for ; Thu, 13 Oct 2005 11:31:43 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp3-g19.free.fr (Postfix) with ESMTP id 5F54337528 for ; Thu, 13 Oct 2005 13:31:42 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9DBVaQI012633 for ; Thu, 13 Oct 2005 13:31:40 +0200 (CEST) From: Thierry Herbelot To: current@freebsd.org Date: Thu, 13 Oct 2005 13:31:25 +0200 User-Agent: KMail/1.8.2 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510131331.27906.thierry@herbelot.com> Cc: Subject: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 13 Oct 2005 11:31:44 -0000 Hello, I have booted the latest RC1 boot only iso image from qemu, and it seems we have lost the attachment to ed(4) : % qemu -boot d -cdrom 6.0-RC1-i386-bootonly.iso -serial stdio 6.0-RC1.img OK boot -v SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=01 base=0000000000100000 len=0000000007f00000 Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e69000. Preloaded mfs_root "/boot/mfsroot" at 0xc0e69108. Calibrating clock(s) ... i8254 clock: 1113136 Hz 1113136 Hz differs from default of 1193182 Hz by more than 1% [SNIP more device probing] pci0: at device 2.0 (no driver attached) ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 device_attach: ed0 attach returned 6 ex_isa_identify() [SNIP end of probing] the ed device is correctly detected and attached in the same conditions from the BETA5 boot-only image : .... pci0: at device 2.0 (no driver attached) ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 ed0: [MPSAFE] ed0: bpf attached ed0: Ethernet address: 52:54:00:12:34:56 ed0: type NE2000 (16 bit) ata: ata0 already exists; skipping it .... Cheers TfH PS : qemu is uptodate % pkg_info | grep qemu qemu-0.7.2s.20050909_2 QEMU CPU Emulator From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 11:36:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B3D116A41F for ; Thu, 13 Oct 2005 11:36:55 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B155943D48 for ; Thu, 13 Oct 2005 11:36:54 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j9DBarqH059271 for ; Thu, 13 Oct 2005 06:36:53 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434E46C0.7060903@centtech.com> Date: Thu, 13 Oct 2005 06:36:32 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1131/Wed Oct 12 15:35:32 2005 on mh2.centtech.com X-Virus-Status: Clean Subject: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 11:36:55 -0000 [resend to -current for broader test audience] I've just finished the first version of ufsstat, a tool to show local filesystem statistics much like nfsstat does for NFS. The patch and tool is against 6.0, but it will probably apply and work fine under -CURRENT and possibly 5.x as well. I'm looking for bug reports, comments/suggestions on style(9), and anything else, since this is my first C project, and of course first real FreeBSD contribution. :) To use it, do this: cd /tmp fetch http://www.googlebit.com/software/ufsstat/ufsstat-20051011.tar.gz cd /usr tar xvzf /tmp/ufsstat-20051011.tar.gz patch <./ufsstats.patch add: OPTIONS UFS_STAT to your kernel. Rebuild and install world/kernel. Now, you can use ufsstat to show you statistics from your local filesystems, like this: # ufsstat Create Remove Link Symlink Mkdir Rmdir Rename 289048 794043 4361 12558 25796 117739 0 GetAttr SetAttr Open Close ReadDir ReadLink VInit 64868230 759824 10701553 9891642 5042948 0 45315645 Chmod Chown Whiteout Strategy Access Mknod NewInode 409782 79612 0 4020035 0 3 0 Fsync SyncVnode LockVnode RdVnode WrVNode 0 0 0 0 0 ExtRead Extwrite FndExtAtt RdExtAttr OpnExtAtt ClseExtAt ExtStrtgy 0 0 0 0 0 0 0 or watch over time with the -w switch. I have not done any performance testing yet to see if it impacts filesystem performance by any measurable amount, so if someone does do this testing before I do, please post your results! Thanks in advance! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:01:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 194D116A421 for ; Thu, 13 Oct 2005 12:01:39 +0000 (GMT) (envelope-from tobias.m81@web.de) Received: from smtp08.web.de (smtp08.web.de [217.72.192.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 417AA43D62 for ; Thu, 13 Oct 2005 12:01:37 +0000 (GMT) (envelope-from tobias.m81@web.de) Received: from [217.247.132.64] (helo=[192.168.0.102]) by smtp08.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.105 #317) id 1EQ1mB-00043F-00 for freebsd-current@freebsd.org; Thu, 13 Oct 2005 14:01:35 +0200 Message-ID: <434E68EA.7040304@web.de> Date: Thu, 13 Oct 2005 14:02:18 +0000 From: =?ISO-8859-1?Q?Tobias_Mohrl=FCder?= User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: tobias.m81@web.de X-Sender: tobias.m81@web.de Subject: Re: 6.0-RC1: Boot panic - Update - solved X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 12:01:39 -0000 > You are loading the rtc (emulators/rtc) module compiled for > 5-stable (as stated in your previous mail, you upgraded 5->6.0). > Disable loading of the module and you should be fine, if i'm > not mistaken, it's loaded from a rc.d-script in /usr/X11R6/etc/rc.d Argh. Yes, you are right. I've deinstalled the whole package (since I couldn't find the place where the module is loaded) and everything runs fine. Really frustrating, I thought I did not make such a silly mistake :-/ .. Thanks for your help and sorry for stealing your time. Bye, Tobias *should-use-SuSE* Mohrlüder From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:10:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07C9916A41F; Thu, 13 Oct 2005 12:10:53 +0000 (GMT) (envelope-from martin@gneto.com) Received: from av6-2-sn3.vrr.skanova.net (av6-2-sn3.vrr.skanova.net [81.228.9.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8595D43D49; Thu, 13 Oct 2005 12:10:52 +0000 (GMT) (envelope-from martin@gneto.com) Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id A3FCD3814A; Thu, 13 Oct 2005 14:10:48 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8B41F37ED9; Thu, 13 Oct 2005 14:10:48 +0200 (CEST) Received: from [192.168.2.30] (h99n2fls34o985.telia.com [213.66.202.99]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 1DB0537E48; Thu, 13 Oct 2005 14:10:43 +0200 (CEST) Message-ID: <434E4EBC.5040505@gneto.com> Date: Thu, 13 Oct 2005 14:10:36 +0200 From: Martin Nilsson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Scott Long References: <434E005B.70408@gneto.com> <434E0511.7000704@samsco.org> In-Reply-To: <434E0511.7000704@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Adaptec Serial ATA II RAID 1420SA Support (Marvell chip) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 12:10:53 -0000 Scott Long wrote: > Martin Nilsson wrote: >> The chip on the adapter is called AIC-8130 and is also marked Marvell >> 88SX6541-BCZ, the adaptec Linux driver is called aar81xx. > > Getting specs out of Marvell is impossible; > it's been tried many times for their previous SATA > and network chips, and the result is almost always > nothing but frustration. I was under the impression that Søren had at least some kind of documentation for the previous generation of Marvell SATA chips. /Martin From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:11:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF71116A41F for ; Thu, 13 Oct 2005 12:11:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1838143D49 for ; Thu, 13 Oct 2005 12:11:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3D61C.dip.t-dialin.net [84.163.214.28] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1EQ1ve1IUm-00026X; Thu, 13 Oct 2005 14:11:22 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 14:12:11 +0200 User-Agent: KMail/1.8.2 References: <434E46C0.7060903@centtech.com> In-Reply-To: <434E46C0.7060903@centtech.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10456337.dubLW3Ud8u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510131412.23525.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Eric Anderson Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 12:11:27 -0000 --nextPart10456337.dubLW3Ud8u Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 October 2005 13:36, Eric Anderson wrote: > [resend to -current for broader test audience] > > I've just finished the first version of ufsstat, a tool to show local > filesystem statistics much like nfsstat does for NFS. The patch and > tool is against 6.0, but it will probably apply and work fine under > -CURRENT and possibly 5.x as well. > > I'm looking for bug reports, comments/suggestions on style(9), and > anything else, since this is my first C project, and of course first > real FreeBSD contribution. :) The patch contains some jitter in the first three or four files due to olde= r=20 versions in src-patched. As all the statistic gathering is #ifdef'ed it=20 should not hurt performance in the disabled case. It will look nicer if yo= u=20 define a macro to update statistics like: #ifdef UFS_STATS #define UFS_STATS_UPDATE(field) ufsstats.field++ #else #define UFS_STATS_UPDATE(field) #end This will in turn only use one line per update point and you don't have to = do=20 the ugly: #ifdef UFS_STATS ufsstats.fsync++; #endif Also, make sure to declare "extern struct ufsstats ufsstats" in ufsstats.h= =20 under _KERNEL and define it in just one place. As is, you don't record the= =20 updates from ffs_vnops.c into the right structure. Finally, you should=20 consider 64 bit counter for some, if not all, fields as they will overflow= =20 quickly. > To use it, do this: > cd /tmp > fetch http://www.googlebit.com/software/ufsstat/ufsstat-20051011.tar.gz > cd /usr > tar xvzf /tmp/ufsstat-20051011.tar.gz > patch <./ufsstats.patch > > add: > OPTIONS UFS_STAT > to your kernel. > > Rebuild and install world/kernel. > > Now, you can use ufsstat to show you statistics from your local > filesystems, like this: > > # ufsstat > Create Remove Link Symlink Mkdir Rmdir Rename > 289048 794043 4361 12558 25796 117739 0 > GetAttr SetAttr Open Close ReadDir ReadLink VInit > 64868230 759824 10701553 9891642 5042948 0 45315645 > Chmod Chown Whiteout Strategy Access Mknod NewInode > 409782 79612 0 4020035 0 3 0 > Fsync SyncVnode LockVnode RdVnode WrVNode > 0 0 0 0 0 > ExtRead Extwrite FndExtAtt RdExtAttr OpnExtAtt ClseExtAt ExtStrtgy > 0 0 0 0 0 0 0 > > or watch over time with the -w switch. > > I have not done any performance testing yet to see if it impacts > filesystem performance by any measurable amount, so if someone does do > this testing before I do, please post your results! I don't think you can measure one single interger (or 64bit) increase in fa= ce=20 of a operation that has to access backing store. Even if there is a=20 performance hit, you don't have to build your kernel with the option enable= d. It might be (more) interesting to have these stats on a per-mountpoint basi= s. =20 Not sure if you have enough state available to record all of the above, but= =20 since you asked for input - this might be worth investigating. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart10456337.dubLW3Ud8u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTk8nXyyEoT62BG0RAt82AJ4oNwBQizLFy/mjd0TRzO39b+lWYgCeJqc+ nvQ2r8DEzdGGCeALeewVY2A= =hhfi -----END PGP SIGNATURE----- --nextPart10456337.dubLW3Ud8u-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:23:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 035CD16A41F for ; Thu, 13 Oct 2005 12:23:45 +0000 (GMT) (envelope-from jens.rehsack.ext@siemensvdo.com) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C0443D46 for ; Thu, 13 Oct 2005 12:23:44 +0000 (GMT) (envelope-from jens.rehsack.ext@siemensvdo.com) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j9DCNZRd014507; Thu, 13 Oct 2005 14:23:35 +0200 Received: from sbas063a.ww011.siemens.net (sbas063a.sbas.ww011.siemens.net [158.92.186.172]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9DCNXMj002624; Thu, 13 Oct 2005 14:23:34 +0200 Received: from krbdf7ma.ww011.siemens.net ([158.92.210.82]) by sbas063a.ww011.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 14:23:33 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5CFF0.EB30E2F8" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 13 Oct 2005 14:23:28 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Problems with Acer Travelmate & PC-Card interface Thread-Index: AcXLYg9viiPr0HiwSX+w1gwYhzYxDAEjeSCA From: "Rehsack Jens \(ext\)" To: "M. Warner Losh" X-OriginalArrivalTime: 13 Oct 2005 12:23:33.0495 (UTC) FILETIME=[ED945870:01C5CFF0] Cc: rehsack@liwing.de, current@freebsd.org Subject: RE: Problems with Acer Travelmate & PC-Card interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 12:23:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CFF0.EB30E2F8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: M. Warner Losh [mailto:imp@bsdimp.com]=20 Sent: Friday, October 07, 2005 7:08 PM To: Rehsack Jens (ext) Cc: rehsack@liwing.de; jon@freebsd.org; current@freebsd.org Subject: Re: Problems with Acer Travelmate & PC-Card interface > : > > : Is there a way for me to support you with data or traces to figure > : it > : > > : out? Or do I simply have to wait ... > : > >=20 > : > > If you had the debugging level like I suggested, then I think so. > : You > : > > did run it with hw.cardbus.cis_debug=3D1, right? > : >=20 > : > Yes, I did. And it adds exactly the 4 lines you've additional in the > : log. > : >=20 > : > > Warner > :=20 > : Any news, Warner? >=20 > No. Hi Warner, but I have. I attach a (stripped) /var/log/messages where I've inserted 2 similar cards. 1st is a UMTS-Card including WLAN-Module and is designed as cardbus card (of course), 2nd is a simple UMTS modem which is a "normal" PC-Card. I hope this will help you make any progress, because it would just be fine when I can start using my hardware without switching to windows ;) Best regards, Jens ------_=_NextPart_001_01C5CFF0.EB30E2F8 Content-Type: application/octet-stream; name="messages" Content-Transfer-Encoding: base64 Content-Description: messages Content-Disposition: attachment; filename="messages" T2N0IDEzIDExOjU0OjA2IGtlcm1pdCBrZXJuZWw6IFN0YXR1cyBpcyAweDMwMDAwODIwCk9jdCAx MyAxMTo1NDowNiBrZXJtaXQga2VybmVsOiBjYmIwOiBjYXJkIGluc2VydGVkOiBldmVudD0weDAw MDAwMDAwLCBzdGF0ZT0zMDAwMDgyMApPY3QgMTMgMTE6NTQ6MDYga2VybWl0IGtlcm5lbDogY2Ji MDogY2JiX3Bvd2VyOiAzVgpPY3QgMTMgMTE6NTQ6MDYga2VybWl0IGtlcm5lbDogY2JiMDogY2Ji X3Bvd2VyOiAwVgoKT2N0IDEzIDExOjU0OjQ1IGtlcm1pdCBrZXJuZWw6IFN0YXR1cyBpcyAweDMw MDAwMDI2Ck9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBTdGF0dXMgaXMgMHgzMDAwMDQx MQpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogY2JiMDogY2FyZCBpbnNlcnRlZDogZXZl bnQ9MHgwMDAwMDAwMCwgc3RhdGU9MzAwMDA0MTEKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJu ZWw6IHBjY2FyZDA6IGNoaXBfc29ja2V0X2VuYWJsZQpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtl cm5lbDogY2JiX3BjaWNfc29ja2V0X2VuYWJsZToKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJu ZWw6IGNiYjA6IGNiYl9wb3dlcjogNVYKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBj Y2FyZDA6IHJlYWRfY2lzCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBjaXMgbWVtIG1h cCAweGMwMjEwMDAwIChyZXNvdXJjZTogMHhjMDIxMDAwMCkKT2N0IDEzIDExOjU1OjExIGtlcm1p dCBrZXJuZWw6IHBjY2FyZDA6IENJUyB0dXBsZSBjaGFpbjoKT2N0IDEzIDExOjU1OjExIGtlcm1p dCBrZXJuZWw6IENJU1RQTF9ERVZJQ0UgdHlwZT1udWxsIHNwZWVkPW51bGwKT2N0IDEzIDExOjU1 OjExIGtlcm1pdCBrZXJuZWw6IDAxIDAzIDAwIDAwIGZmCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQg a2VybmVsOiBDSVNUUExfREVWSUNFX0EgdHlwZT1udWxsIHNwZWVkPW51bGwKT2N0IDEzIDExOjU1 OjExIGtlcm1pdCBrZXJuZWw6IDE3IDAzIDAwIDAwIGZmCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQg a2VybmVsOiBDSVNUUExfTE9OR0xJTktfTUZDIDIgYXR0cjo0YyBhdHRyOmNiCk9jdCAxMyAxMTo1 NToxMSBrZXJtaXQga2VybmVsOiAwNiAwYiAwMiAwMCA0YyAwMCAwMCAwMCAwMCBjYiAwMCAwMCAw MApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogQ0lTVFBMX01BTkZJRApPY3QgMTMgMTE6 NTU6MTEga2VybWl0IGtlcm5lbDogMjAgMDQgYTQgMDAgNzYgMDIKT2N0IDEzIDExOjU1OjExIGtl cm1pdCBrZXJuZWw6IENJU1RQTF9WRVJTXzEKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6 IDE1IDJjIDA2IDAxIDRlIDZmIDc2IDYxIDc0IDY1IDZjIDIwIDU3IDY5IDcyIDY1Ck9jdCAxMyAx MTo1NToxMSBrZXJtaXQga2VybmVsOiA2YyA2NSA3MyA3MyAwMCA0ZCA2NSA3MiA2YyA2OSA2ZSAy MCA1NSA0ZCA1NCA1MwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogMjAgNGQgNmYgNjQg NjUgNmQgMDAgNTUgMzYgMzMgMzAgMDAgMDAgZmYKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJu ZWw6IENJU1RQTF9FTkQKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IGZmCk9jdCAxMyAx MTo1NToxMSBrZXJtaXQga2VybmVsOiBjaXMgbWVtIG1hcCBjMDIxMDAwMApPY3QgMTMgMTE6NTU6 MTEga2VybWl0IGtlcm5lbDogQ0lTVFBMX0xJTktUQVJHRVQgZXhwZWN0ZWQsIGNvZGUgZmYgb2Jz ZXJ2ZWQKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IGNpcyBtZW0gbWFwIGMwMjEwMDAw Ck9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBDSVNUUExfRlVOQ0lECk9jdCAxMyAxMTo1 NToxMSBrZXJtaXQga2VybmVsOiAyMSAwMiAwMiAwMQpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtl cm5lbDogQ0lTVFBMX0ZVTkNFCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAyMiAwNCAw MCAwMiAwZiA3ZgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogQ0lTVFBMX0NPTkZJRwpP Y3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogMWEgMDYgMDUgMDUgMDAgMDQgNjMgMDIKT2N0 IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAx MTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAxOSBjNyAwMSA5OSA2OSA1NSAxZCBmNiAzMiAyZCBh MyA2MCBmOCAwMyAwNwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogNTAgZmYgZmYgNDgg YzEgMDUgNDMgNGYgNGQgMzEgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IENJU1RQ TF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAxMiAwZiA5 OCBhMyA2MCBmOCAwMiAwNyA1MCBmZiBmZiA0OCBjMSAwNSA0MwpPY3QgMTMgMTE6NTU6MTEga2Vy bWl0IGtlcm5lbDogNGYgNGQgMzIgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IENJ U1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAxMiAx NyA5OCBhMyA2MCBlOCAwMyAwNyA1MCBmZiBmZiA0OCBjMSAwNSA0MwpPY3QgMTMgMTE6NTU6MTEg a2VybWl0IGtlcm5lbDogNGYgNGQgMzMgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6 IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAx MiAxZiA5OCBhMyA2MCBlOCAwMiAwNyA1MCBmZiBmZiA0OCBjMSAwNSA0MwpPY3QgMTMgMTE6NTU6 MTEga2VybWl0IGtlcm5lbDogNGYgNGQgMzQgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJu ZWw6IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAx YiAwZSAyNyA5OCAyMyA1MCBmZiBmZiA0OCBjMSAwNSA0MyA0ZiA0ZCA3OCAwMApPY3QgMTMgMTE6 NTU6MTEga2VybWl0IGtlcm5lbDogQ0lTVFBMX0VORApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtl cm5lbDogZmYKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IGNpcyBtZW0gbWFwIGMwMjEw MDAwCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBDSVNUUExfRlVOQ0lECk9jdCAxMyAx MTo1NToxMSBrZXJtaXQga2VybmVsOiAyMSAwMiAwMiAwMQpPY3QgMTMgMTE6NTU6MTEga2VybWl0 IGtlcm5lbDogQ0lTVFBMX0ZVTkNFCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAyMiAw NCAwMCAwMiAwZiA3ZgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogQ0lTVFBMX0NPTkZJ RwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogMWEgMDYgMDUgMGEgMjAgMDQgNjMgMDIK T2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAx MyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAxOSBjNyAwMSA5OSA2OSA1NSAxZCBmNiAzMiAy ZCBhMyA2MCBmOCAwMiAwNwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogNTAgZmYgZmYg NDggYzEgMDUgNDMgNGYgNGQgMzYgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IENJ U1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAxMiAw ZiA5OCBhMyA2MCBmOCAwMyAwNyA1MCBmZiBmZiA0OCBjMSAwNSA0MwpPY3QgMTMgMTE6NTU6MTEg a2VybWl0IGtlcm5lbDogNGYgNGQgMzcgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6 IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAxYiAx MiAxNyA5OCBhMyA2MCBlOCAwMiAwNyA1MCBmZiBmZiA0OCBjMSAwNSA0MwpPY3QgMTMgMTE6NTU6 MTEga2VybWl0IGtlcm5lbDogNGYgNGQgMzggMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJu ZWw6IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiAx YiAxMiAxZiA5OCBhMyA2MCBlOCAwMyAwNyA1MCBmZiBmZiA0OCBjMSAwNSA0MwpPY3QgMTMgMTE6 NTU6MTEga2VybWl0IGtlcm5lbDogNGYgNGQgMzkgMDAKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBr ZXJuZWw6IENJU1RQTF9DRlRBQkxFX0VOVFJZCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVs OiAxYiAwZSAyNyA5OCAyMyA1MCBmZiBmZiA0OCBjMSAwNSA0MyA0ZiA0ZCA3OSAwMApPY3QgMTMg MTE6NTU6MTEga2VybWl0IGtlcm5lbDogQ0lTVFBMX0VORApPY3QgMTMgMTE6NTU6MTEga2VybWl0 IGtlcm5lbDogZmYKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IGNoZWNr X2Npc19xdWlya3MKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IENJUyB2 ZXJzaW9uIFBDIENhcmQgU3RhbmRhcmQgNi4xCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVs OiBwY2NhcmQwOiBDSVMgaW5mbzogTm92YXRlbCBXaXJlbGVzcywgTWVybGluIFVNVFMgTW9kZW0s IFU2MzAsIApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJkMDogTWFudWZhY3R1 cmVyIGNvZGUgMHhhNCwgcHJvZHVjdCAweDI3NgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5l bDogcGNjYXJkMDogZnVuY3Rpb24gMDogc2VyaWFsIHBvcnQsIGNjciBhZGRyIDQwMCBtYXNrIDI2 MwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJkMDogZnVuY3Rpb24gMCwgY29u ZmlnIHRhYmxlIGVudHJ5IDc6IEkvTyBjYXJkOyBpcnEgbWFzayBmZmZmOyBpb21hc2sgMywgaW9z cGFjZSAzZjgtM2ZmOyBpbzggaXJxcHVsc2UgYXVkaW8KT2N0IDEzIDExOjU1OjExIGtlcm1pdCBr ZXJuZWw6IHBjY2FyZDA6IGZ1bmN0aW9uIDAsIGNvbmZpZyB0YWJsZSBlbnRyeSAxNTogSS9PIGNh cmQ7IGlycSBtYXNrIGZmZmY7IGlvbWFzayAzLCBpb3NwYWNlIDJmOC0yZmY7IGlvOCBpcnFwdWxz ZSBhdWRpbwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJkMDogZnVuY3Rpb24g MCwgY29uZmlnIHRhYmxlIGVudHJ5IDIzOiBJL08gY2FyZDsgaXJxIG1hc2sgZmZmZjsgaW9tYXNr IDMsIGlvc3BhY2UgM2U4LTNlZjsgaW84IGlycXB1bHNlIGF1ZGlvCk9jdCAxMyAxMTo1NToxMSBr ZXJtaXQga2VybmVsOiBwY2NhcmQwOiBmdW5jdGlvbiAwLCBjb25maWcgdGFibGUgZW50cnkgMzE6 IEkvTyBjYXJkOyBpcnEgbWFzayBmZmZmOyBpb21hc2sgMywgaW9zcGFjZSAyZTgtMmVmOyBpbzgg aXJxcHVsc2UgYXVkaW8KT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IGZ1 bmN0aW9uIDAsIGNvbmZpZyB0YWJsZSBlbnRyeSAzOTogSS9PIGNhcmQ7IGlycSBtYXNrIGZmZmY7 IGlvbWFzayAzLCBpb3NwYWNlIDAtNzsgaW84IGlycXB1bHNlIGF1ZGlvCk9jdCAxMyAxMTo1NTox MSBrZXJtaXQga2VybmVsOiBwY2NhcmQwOiBmdW5jdGlvbiAxOiBzZXJpYWwgcG9ydCwgY2NyIGFk ZHIgNDIwIG1hc2sgMjYzCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBwY2NhcmQwOiBm dW5jdGlvbiAxLCBjb25maWcgdGFibGUgZW50cnkgNzogSS9PIGNhcmQ7IGlycSBtYXNrIGZmZmY7 IGlvbWFzayAzLCBpb3NwYWNlIDJmOC0yZmY7IGlvOCBpcnFwdWxzZSBhdWRpbwpPY3QgMTMgMTE6 NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJkMDogZnVuY3Rpb24gMSwgY29uZmlnIHRhYmxlIGVu dHJ5IDE1OiBJL08gY2FyZDsgaXJxIG1hc2sgZmZmZjsgaW9tYXNrIDMsIGlvc3BhY2UgM2Y4LTNm ZjsgaW84IGlycXB1bHNlIGF1ZGlvCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBwY2Nh cmQwOiBmdW5jdGlvbiAxLCBjb25maWcgdGFibGUgZW50cnkgMjM6IEkvTyBjYXJkOyBpcnEgbWFz ayBmZmZmOyBpb21hc2sgMywgaW9zcGFjZSAyZTgtMmVmOyBpbzggaXJxcHVsc2UgYXVkaW8KT2N0 IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IGZ1bmN0aW9uIDEsIGNvbmZpZyB0 YWJsZSBlbnRyeSAzMTogSS9PIGNhcmQ7IGlycSBtYXNrIGZmZmY7IGlvbWFzayAzLCBpb3NwYWNl IDNlOC0zZWY7IGlvOCBpcnFwdWxzZSBhdWRpbwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5l bDogcGNjYXJkMDogZnVuY3Rpb24gMSwgY29uZmlnIHRhYmxlIGVudHJ5IDM5OiBJL08gY2FyZDsg aXJxIG1hc2sgZmZmZjsgaW9tYXNrIDMsIGlvc3BhY2UgMC03OyBpbzggaXJxcHVsc2UgYXVkaW8K T2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IGZ1bmN0aW9ucyBzY2Fubmlu ZwpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJkMDogQ2FyZCBoYXMgMiBmdW5j dGlvbnMuIHBjY2FyZF9tZmMgaXMgMQpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNj YXJkMDogSS9PIHJpZCAwIHN0YXJ0IDNmOCBlbmQgM2ZmCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQg a2VybmVsOiBjYmJfcGNpY19zb2NrZXRfZW5hYmxlOgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtl cm5lbDogY2JiMDogY2JiX3Bvd2VyOiAwVgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDog Y2JiMDogY2JiX3Bvd2VyOiA1VgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJk MDogY2NyX3JlcyA9PSBjMDIwYjAwMC1jMDIwYmZmZiwgYmFzZT00MDAKT2N0IDEzIDExOjU1OjEx IGtlcm1pdCBrZXJuZWw6IHVua25vd246IE1GQzogSS9PIGJhc2UgMCBJT1NJWkUgMHgxCk9jdCAx MyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBwY2NhcmQwOiBmdW5jdGlvbiAwIENDUiBhdCAwIG9m ZnNldCA0MDA6IDQ3IDI4IDAgMCwgMCAwIDAgMCwgMApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtl cm5lbDogcGNjYXJkMDogZnVuY3Rpb24gMSBDQ1IgYXQgMCBvZmZzZXQgMDogMCAwIDAgMCwgMCAw IDAgMCwgMApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogc2lvNDogPE5vdmF0ZWwgV2ly ZWxlc3MgTWVybGluIFVNVFMgTW9kZW0+IGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDIwIGZ1bmN0 aW9uIDAgY29uZmlnIDcgb24gcGNjYXJkMApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDog c2lvNDogTUZDOiBJL08gYmFzZSAweDNmOCBJT1NJWkUgMHg4Ck9jdCAxMyAxMTo1NToxMSBrZXJt aXQga2VybmVsOiBzaW80OiBNRkM6IEkvTyBiYXNlIDB4M2Y4IElPU0laRSAweDgKT2N0IDEzIDEx OjU1OjExIGtlcm1pdCBrZXJuZWw6IHNpbzQ6IHR5cGUgMTY1NTBBCk9jdCAxMyAxMTo1NToxMSBr ZXJtaXQga2VybmVsOiBzaW80OiB1bmFibGUgdG8gYWN0aXZhdGUgaW50ZXJydXB0IGluIGZhc3Qg bW9kZSAtIHVzaW5nIG5vcm1hbCBtb2RlCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBw Y2NhcmQwOiBmdW5jdGlvbiAwIENDUiBhdCAwIG9mZnNldCA0MDAgbWFzayAyNjM6IDQ3IDI4IDAg MCwgZjggMyAwIDAsIDcKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IEkv TyByaWQgMCBzdGFydCAyZjggZW5kIDJmZgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDog cGNjYXJkMDogQWxsb2NhdGlvbiBmYWlsZWQgZm9yIGNmZSA3Ck9jdCAxMyAxMTo1NToxMSBrZXJt aXQga2VybmVsOiBwY2NhcmQwOiBJL08gcmlkIDAgc3RhcnQgM2Y4IGVuZCAzZmYKT2N0IDEzIDEx OjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IEFsbG9jYXRpb24gZmFpbGVkIGZvciBjZmUg MTUKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6IHBjY2FyZDA6IEkvTyByaWQgMCBzdGFy dCAyZTggZW5kIDJlZgpPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDogcGNjYXJkMDogY2Ny X3JlcyA9PSBjMDIwYzAwMC1jMDIwY2ZmZiwgYmFzZT00MjAKT2N0IDEzIDExOjU1OjExIGtlcm1p dCBrZXJuZWw6IHVua25vd246IE1GQzogSS9PIGJhc2UgMCBJT1NJWkUgMHgxCk9jdCAxMyAxMTo1 NToxMSBrZXJtaXQga2VybmVsOiBwY2NhcmQwOiBmdW5jdGlvbiAwIENDUiBhdCAwIG9mZnNldCA0 MDA6IDQ3IDI4IDAgMCwgZjggMyAwIDAsIDcKT2N0IDEzIDExOjU1OjExIGtlcm1pdCBrZXJuZWw6 IHBjY2FyZDA6IGZ1bmN0aW9uIDEgQ0NSIGF0IDAgb2Zmc2V0IDQyMDogNTcgMjggMCAwLCAwIDAg MCAwLCAwCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBzaW81OiA8Tm92YXRlbCBXaXJl bGVzcyBNZXJsaW4gVU1UUyBNb2RlbT4gYXQgcG9ydCAweDJlOC0weDJlZiBpcnEgMjAgZnVuY3Rp b24gMSBjb25maWcgMjMgb24gcGNjYXJkMApPY3QgMTMgMTE6NTU6MTEga2VybWl0IGtlcm5lbDog c2lvNTogTUZDOiBJL08gYmFzZSAweDJlOCBJT1NJWkUgMHg4Ck9jdCAxMyAxMTo1NToxMSBrZXJt aXQga2VybmVsOiBzaW81OiBNRkM6IEkvTyBiYXNlIDB4MmU4IElPU0laRSAweDgKT2N0IDEzIDEx OjU1OjExIGtlcm1pdCBrZXJuZWw6IHNpbzU6IHR5cGUgMTY1NTBBCk9jdCAxMyAxMTo1NToxMSBr ZXJtaXQga2VybmVsOiBzaW81OiB1bmFibGUgdG8gYWN0aXZhdGUgaW50ZXJydXB0IGluIGZhc3Qg bW9kZSAtIHVzaW5nIG5vcm1hbCBtb2RlCk9jdCAxMyAxMTo1NToxMSBrZXJtaXQga2VybmVsOiBw Y2NhcmQwOiBmdW5jdGlvbiAxIENDUiBhdCAwIG9mZnNldCA0MjAgbWFzayAyNjM6IDU3IDI4IDAg MCwgZTggMiAwIDAsIDcKT2N0IDEzIDExOjU1OjE0IGtlcm1pdCBrZXJuZWw6IEFDUEktMDUwMTog KioqIEVycm9yOiBIYW5kbGVyIGZvciBbRW1iZWRkZWRDb250cm9sXSByZXR1cm5lZCBBRV9OT19I QVJEV0FSRV9SRVNQT05TRQpPY3QgMTMgMTE6NTU6MTQga2VybWl0IGtlcm5lbDogQUNQSS0xMzA0 OiAqKiogRXJyb3I6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcX1NCXy5QQ0kwLkxQQzAuRUMw Xy5HQklGXSAoTm9kZSAweGZmZmZmZjAwMDA4ZDkyNDApLCBBRV9OT19IQVJEV0FSRV9SRVNQT05T RQpPY3QgMTMgMTE6NTU6MTQga2VybWl0IGtlcm5lbDogQUNQSS0xMzA0OiAqKiogRXJyb3I6IE1l dGhvZCBleGVjdXRpb24gZmFpbGVkIFtcX1NCXy5QQ0kwLkxQQzAuRUMwXy5CQVQwLl9CSUZdIChO b2RlIDB4ZmZmZmZmMDAwMDhkOGRjMCksIEFFX05PX0hBUkRXQVJFX1JFU1BPTlNFCk9jdCAxMyAx MTo1NToyMCBrZXJtaXQga2VybmVsOiBTdGF0dXMgaXMgMHgzMDAwMDAxNgpPY3QgMTMgMTE6NTU6 MjAga2VybWl0IGtlcm5lbDogQWxsIHRocmVhZHMgcHVyZ2VkIGZyb20gY3VhZDQKT2N0IDEzIDEx OjU1OjIwIGtlcm1pdCBrZXJuZWw6IEFsbCB0aHJlYWRzIHB1cmdlZCBmcm9tIHR0eWQ0Ck9jdCAx MyAxMTo1NToyMCBrZXJtaXQga2VybmVsOiBzaW80OiBkZXRhY2hlZApPY3QgMTMgMTE6NTU6MjAg a2VybWl0IGtlcm5lbDogQWxsIHRocmVhZHMgcHVyZ2VkIGZyb20gY3VhZDUKT2N0IDEzIDExOjU1 OjIwIGtlcm1pdCBrZXJuZWw6IEFsbCB0aHJlYWRzIHB1cmdlZCBmcm9tIHR0eWQ1Ck9jdCAxMyAx MTo1NToyMCBrZXJtaXQga2VybmVsOiBzaW81OiBkZXRhY2hlZApPY3QgMTMgMTE6NTU6MjAga2Vy bWl0IGtlcm5lbDogY2JiX3BjaWNfc29ja2V0X2Rpc2FibGUK ------_=_NextPart_001_01C5CFF0.EB30E2F8-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:31:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A98A216A41F for ; Thu, 13 Oct 2005 12:31:26 +0000 (GMT) (envelope-from freebsd@psam.se) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id C405443D45 for ; Thu, 13 Oct 2005 12:31:25 +0000 (GMT) (envelope-from freebsd@psam.se) Received: from caspian ([85.228.2.87] [85.228.2.87]) by mxfep01.bredband.com with ESMTP id <20051013123124.CDPY9934.mxfep01.bredband.com@caspian> for ; Thu, 13 Oct 2005 14:31:24 +0200 Received: from [127.0.0.1] ([85.228.2.90]) (authenticated user peter@psam.se) by caspian (Kerio MailServer 6.1.0) for freebsd-current@freebsd.org; Thu, 13 Oct 2005 14:31:42 +0200 Message-ID: <434E538F.80000@psam.se> Date: Thu, 13 Oct 2005 14:31:11 +0200 From: Psadi User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0541-2, 2005-10-13), Outbound message X-Antivirus-Status: Clean Subject: Thoshiba Tecra 8000 with 3com 3CXFE575CT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 12:31:26 -0000 Hi I had decided to try FreeBSD 6.0 on my laptop. After I installed it beta4 I recived alot of xl0: watchdog timeout every time I try to use the internet. I then decided for reference install FreeBSD 5.4. With FreeBSD 5.4 I have no problem with watchdog timeout and using internet fropm what I can say is faster, since there isnt any watchdog timeout. Then since the RC1 for 6.0 came out I decided to try and install that but I recive the same watchdog timeout. I tried to google for some information but im lost :) Im using a bought cat6 cable and since it works in 5.4 I dont think I have a hardware problem. At startup I see that I get CARDBUS1: Resource not specified in CIS: id=14, size=80 I added in pccard.conf that it should use IRQ 3,5,10,15 though when I look it still uses 11 I also changed the networkcard from 100baseT to 10baseT What else can I try or do to get more info for those that needs it? With regards Peter Samuelsson From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:47:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CBE316A41F for ; Thu, 13 Oct 2005 12:47:56 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E9043D45 for ; Thu, 13 Oct 2005 12:47:55 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9DCk94O061919; Thu, 13 Oct 2005 14:46:09 +0200 (CEST) (envelope-from sos@freebsd.org) In-Reply-To: <434E4EBC.5040505@gneto.com> References: <434E005B.70408@gneto.com> <434E0511.7000704@samsco.org> <434E4EBC.5040505@gneto.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0402F00C-F5ED-4423-9574-B49C2F009E5A@freebsd.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Thu, 13 Oct 2005 14:47:52 +0200 To: Martin Nilsson X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@freebsd.org Subject: Re: Adaptec Serial ATA II RAID 1420SA Support (Marvell chip) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 12:47:56 -0000 On 13/10/2005, at 14:10, Martin Nilsson wrote: > Scott Long wrote: > >> Martin Nilsson wrote: >> >>> The chip on the adapter is called AIC-8130 and is also marked =20 >>> Marvell 88SX6541-BCZ, the adaptec Linux driver is called aar81xx. >>> > > > > Getting specs out of Marvell is impossible; > > it's been tried many times for their previous SATA > > and network chips, and the result is almost always nothing but =20 > frustration. > > I was under the impression that S=F8ren had at least some kind of =20 > documentation for the previous generation of Marvell SATA chips. I do, but I havn't worked on it for quite some time due to other =20 things getting higher priority. Also the marvell chips are sufficiently different from the rest of =20 the world that they are not an easy fit into the system, but thats =20 been solved long ago. I hope to get back to this soon together with a few other chipsets =20 that I've collected during the last months.. S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:55:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7A7416A41F for ; Wed, 12 Oct 2005 13:55:22 +0000 (GMT) (envelope-from Benjamin.Close@clearchain.com) Received: from mail.clearchain.com (cisfjf.levels.unisa.edu.au [130.220.34.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90AAE43D4C for ; Wed, 12 Oct 2005 13:55:20 +0000 (GMT) (envelope-from Benjamin.Close@clearchain.com) Received: from [192.168.155.60] (ppp236-50.lns2.adl2.internode.on.net [203.122.236.50]) (authenticated bits=0) by mail.clearchain.com (8.12.9p2/8.12.9) with ESMTP id j9CDt76A083066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Oct 2005 23:25:11 +0930 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <434D9B4A.7080909@clearchain.com> Date: Thu, 13 Oct 2005 08:54:58 +0930 From: Benjamin Close User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050625) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (mail.clearchain.com [130.220.34.151]); Wed, 12 Oct 2005 23:25:24 +0930 (CST) X-Mailman-Approved-At: Thu, 13 Oct 2005 12:50:07 +0000 Subject: 6.0-RC1 Panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2005 13:55:22 -0000 Hi All, I can repeatedly get this panic at boot if I have my wi0 (802.11b Lucent / Hermes chipset) card in my laptop. Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc06474fa stack pointer = 0x28:0xd9927c78 frame pointer = 0x28:0xd9927c88 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 = 242 (netstat) trap number = 18 panic: integer divide fault Uptime: 3m32s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130794 pages) 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 Full Details below... Script started on Thu Oct 13 08:26:13 2005 draco# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug vmcore.0^M [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: Copyright (c) 1992-2005 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 6.0-RC1 #0: Tue Oct 11 19:15:17 CST 2005 benjsc@draco.nodomain.yet:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b04000. Preloaded elf module "/boot/kernel/splash_bmp.ko" at 0xc0b0414c. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc0b041fc. Preloaded splash_image_data "/boot/splash.bmp" at 0xc0b042a8. Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc0b042f8. Preloaded elf module "/boot/kernel/sound.ko" at 0xc0b043ac. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b04458. Calibrating clock(s) ... i8254 clock: 1193141 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 548799995 Hz CPU: Intel Pentium III (548.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387f9ff real memory = 536780800 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f6b1fff, 514379776 bytes (125581 pages) avail memory = 515936256 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xc06e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io:
mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 00 01 00 02 00 01 0e 01 00 01 24 01 00 01 29 01 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 VESA: 60 mode(s) found VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc0a37322 (1000022) VESA: ATI MOBILE M4 VESA: ATI Technologies Inc. M4 01.00 null: splash: image@0xc0a38228, size:308278 bmp_start(): splash_mode:257 splash: image decoder found: splash_bmp npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000fac4 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Found $PIR table, 10 entries at 0xc00fbc20 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 A 0x61 5 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 6 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 6 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 15 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 8 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 D 0x62 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 atpic: Programming IRQ9 as level/low pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link1: irq 5 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 5 7 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 5 7 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 pci_link2: on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link3: irq 10 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 5 7 10 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 5 7 10 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 10 11 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 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 pci0: physical bus=0 found-> vendor=0x8086, dev=0x1130, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e4000000, size 26, enabled found-> vendor=0x8086, dev=0x1131, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2448, revid=0x02 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244c, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244a, revid=0x02 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000bfa0, size 4, enabled found-> vendor=0x8086, dev=0x2442, revid=0x02 bus=0, slot=31, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type 4, range 32, base 0000bce0, size 5, enabled pcib0: matched entry for 0.31.INTD (src \_SB_.PCI0.LNKD:0) pcib0: slot 31 INTD routed to irq 10 via \_SB_.PCI0.LNKD agp0: mem 0xe4000000-0xe7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe4000000 agp0: allocating GATT for aperture of size 36M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xe8000000-0xebffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x4d46, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x00a7, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base e8000000, size 26, enabled pcib1: (null) requested memory range 0xe8000000-0xebffffff: good map[14]: type 4, range 32, base 0000cc00, size 8, enabled pcib1: (null) requested I/O range 0xcc00-0xccff: in range map[18]: type 1, range 32, base fcffc000, size 14, enabled pcib1: (null) requested memory range 0xfcffc000-0xfcffffff: good pcib1: matched entry for 1.0.INTA (src \_SB_.PCI0.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \_SB_.PCI0.LNKA pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 16 pcib2: I/O decode 0xd000-0xffff pcib2: memory decode 0xf2000000-0xfbffffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x125d, dev=0x1998, revid=0x10 bus=2, slot=3, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled pcib2: (null) requested I/O range 0xdc00-0xdcff: in range map[14]: type 1, range 32, base f6ffe000, size 13, enabled pcib2: (null) requested memory range 0xf6ffe000-0xf6ffffff: good pcib2: matched entry for 2.3.INTA (src \_SB_.PCI0.LNKB:0) pcib2: slot 3 INTA routed to irq 5 via \_SB_.PCI0.LNKB found-> vendor=0x1668, dev=0x0100, revid=0x11 bus=2, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x104c, dev=0xac42, revid=0x00 bus=2, slot=15, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0xac42, revid=0x00 bus=2, slot=15, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0x8027, revid=0x00 bus=2, slot=15, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base f6ffd800, size 11, enabled pcib2: (null) requested memory range 0xf6ffd800-0xf6ffdfff: good map[14]: type 1, range 32, base f6ff8000, size 14, enabled pcib2: (null) requested memory range 0xf6ff8000-0xf6ffbfff: good pcib2: matched entry for 2.15.INTA (src \_SB_.PCI0.LNKD:0) pcib2: slot 15 INTA routed to irq 10 via \_SB_.PCI0.LNKD pcm0: port 0xdc00-0xdcff mem 0xf6ffe000-0xf6ffffff irq 5 at device 3.0 on pci2 pcm0: rid 0x10 is ioport, requested 3 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 pcm0: [MPSAFE] pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features AMAP pcm0: sndbuf_setmap 7ffe000, 1000; 0xd96dc000 -> 7ffe000 pcm0: sndbuf_setmap 7ffd000, 1000; 0xd96dd000 -> 7ffd000 pcm0: sndbuf_setmap 7ffc000, 1000; 0xd96de000 -> 7ffc000 pcm0: sndbuf_setmap 7ffb000, 1000; 0xd96df000 -> 7ffb000 pcm0: sndbuf_setmap 7ffa000, 1000; 0xd96e0000 -> 7ffa000 pcib3: at device 6.0 on pci2 pcib3: secondary bus 8 pcib3: subordinate bus 8 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xf8000000-0xf9ffffff pcib3: prefetched decode 0xfff00000-0xfffff pci8: on pcib3 pci8: physical bus=8 found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=8, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base f8fff000, size 12, enabled pcib3: (null) requested memory range 0xf8fff000-0xf8ffffff: good pcib2: (null) requested memory range 0xf8fff000-0xf8ffffff: good map[14]: type 4, range 32, base 0000ecc0, size 6, enabled pcib3: (null) requested I/O range 0xecc0-0xecff: in range pcib2: (null) requested I/O range 0xecc0-0xecff: in range map[18]: type 1, range 32, base f8e00000, size 20, enabled pcib3: (null) requested memory range 0xf8e00000-0xf8efffff: good pcib2: (null) requested memory range 0xf8e00000-0xf8efffff: good pcib2: matched entry for 2.6.INTA (src \_SB_.PCI0.LNKD:0) pcib2: slot 6 INTA routed to irq 10 via \_SB_.PCI0.LNKD pcib3: slot 4 INTA is routed to irq 10 found-> vendor=0x11c1, dev=0x0448, revid=0x01 bus=8, slot=8, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0xfc (63000 ns), maxlat=0x0e (3500 ns) intpin=a, irq=10 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base f8ffec00, size 8, enabled pcib3: (null) requested memory range 0xf8ffec00-0xf8ffecff: good pcib2: (null) requested memory range 0xf8ffec00-0xf8ffecff: good map[14]: type 4, range 32, base 0000ecb8, size 3, enabled pcib3: (null) requested I/O range 0xecb8-0xecbf: in range pcib2: (null) requested I/O range 0xecb8-0xecbf: in range map[18]: type 4, range 32, base 0000e800, size 8, enabled pcib3: (null) requested I/O range 0xe800-0xe8ff: in range pcib2: (null) requested I/O range 0xe800-0xe8ff: in range pcib2: matched entry for 2.6.INTA (src \_SB_.PCI0.LNKD:0) pcib2: slot 6 INTA routed to irq 10 via \_SB_.PCI0.LNKD pcib3: slot 8 INTA is routed to irq 10 fxp0: port 0xecc0-0xecff mem 0xf8fff000-0xf8ffffff,0xf8e00000-0xf8efffff irq 10 at device 4.0 on pci 8 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf8fff000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 1668 1100 0008 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:20:e0:64:53:e7 fxp0: [MPSAFE] pci8: at device 8.0 (no driver attached) cbb0: at device 15.0 on pci2 pcib2: cbb0 requested memory range 0xf2000000-0xfbffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf2000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.15.INTA (src \_SB_.PCI0.LNKD:0) pcib2: slot 15 INTA routed to irq 10 via \_SB_.PCI0.LNKD cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac42104c 0x02100007 0x06070000 0x00822008 0x10: 0xf2000000 0x020000a0 0x20040400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010a 0x40: 0x00a41028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x3024d021 0x00000600 0x000f0000 0x05033002 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 15.1 on pci2 pcib2: cbb1 requested memory range 0xf2000000-0xfbffffff: good cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf2001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib2: matched entry for 2.15.INTA (src \_SB_.PCI0.LNKD:0) pcib2: slot 15 INTA routed to irq 10 via \_SB_.PCI0.LNKD cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac42104c 0x02100007 0x06070000 0x00822008 0x10: 0xf2001000 0x020000a0 0x20050500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010a 0x40: 0x00a41028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x3024f021 0x00000600 0x000f0001 0x05033002 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: mem 0xf6ffd800-0xf6ffdfff,0xf6ff8000-0xf6ffbfff irq 10 at device 15.2 on pci2 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xf6ffd800 fwohci0: [MPSAFE] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 42:4f:c0:00:0e:40:8c:38 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 42:4f:c0:40:8c:38 fwe0: bpf attached fwe0: Ethernet address: 42:4f:c0:40:8c:38 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=7f ostat1=7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: reset tp2 stat0=ff stat1=ff devices=0x0 ata1: [MPSAFE] uhci0: port 0xbce0-0xbcff irq 10 at device 31.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbce0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] sio0: irq maps: 0x601 0x611 0x601 0x601 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x601 0x609 0x601 0x601 sio1 port 0x2f8-0x2ff,0x280-0x287 irq 3 drq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 1 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 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 548799995 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached acpi_acad0: acline initialization start battery0: battery initialization start system power profile changed to 'economy' acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times battery1: battery initialization start battery1: battery initialization done, tried 1 times battery0: battery initialization done, tried 1 times pcib2: pccard1 requested memory range 0xf2000000-0xfbffffff: good pccard1: CIS version PC Card Standard 5.0 pccard1: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01, pccard1: Manufacturer code 0x156, product 0x2 pccard1: function 0: network adapter, ccr addr 3e0 mask 1 pccard1: function 0, config table entry 1: I/O card; irq mask ffff; iomask 6, iospace 0-3f; io16 irqpulse irqlevel pcib2: pccard1 requested I/O range 0xd000-0xffff: in range pcib2: pccard1 requested memory range 0xf2000000-0xfbffffff: good wi0: at port 0xd000-0xd03f irq 10 function 0 config 1 on pccard1 wi0: [MPSAFE] wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.10.1) wi0: bpf attached wi0: Ethernet address: 00:60:1d:f1:5a:ce wi0: bpf attached wi0: bpf attached wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ad0: setting PIO4 on Intel ICH2 chip ad0: setting UDMA100 on Intel ICH2 chip ad0: 28615MB at ata0-master UDMA100 ad0: 58605120 sectors [58140C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on Intel ICH2 chip acd0: setting UDMA33 on Intel ICH2 chip acd0: DVDROM drive at ata0 as slave acd0: read 4134KB/s (4134KB/s), 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted start_init: trying /sbin/init <118>Loading configuration files. <118>kernel dumps on /dev/ad0s2b <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. <118>swapon: adding /dev/ad0s2b as swap device <118>Starting file system checks: <118>/dev/ad0s2a: INCORRECT BLOCK COUNT I=19386 (4 should be 0) (CORRECTED) <118>/dev/ad0s2a: INCORRECT BLOCK COUNT I=19845 (4 should be 0) (CORRECTED) <118>/dev/ad0s2a: INCORRECT BLOCK COUNT I=20010 (4 should be 0) (CORRECTED) <118>/dev/ad0s2a: INCORRECT BLOCK COUNT I=20073 (4 should be 0) (CORRECTED) <118>/dev/ad0s2a: UNREF FILE I=19386 OWNER=root MODE=100644 <118>/dev/ad0s2a: SIZE=0 MTIME=Oct 13 08:03 2005 (CLEARED) <118>/dev/ad0s2a: UNREF FILE I=19429 OWNER=root MODE=120755 <118>/dev/ad0s2a: SIZE=0 MTIME=Oct 13 08:03 2005 (CLEARED) <118>/dev/ad0s2a: UNREF FILE I=19845 OWNER=root MODE=100644 <118>/dev/ad0s2a: SIZE=0 MTIME=Oct 13 08:03 2005 (CLEARED) <118>/dev/ad0s2a: UNREF FILE I=20010 OWNER=root MODE=100644 <118>/dev/ad0s2a: SIZE=0 MTIME=Oct 13 08:03 2005 (CLEARED) <118>/dev/ad0s2a: UNREF FILE I=20073 OWNER=root MODE=100644 <118>/dev/ad0s2a: SIZE=0 MTIME=Oct 13 08:03 2005 (CLEARED) <118>/dev/ad0s2a: UNREF FILE I=20288 OWNER=root MODE=140777 <118>/dev/ad0s2a: SIZE=0 MTIME=Oct 12 06:06 2005 (CLEARED) <118>/dev/ad0s2a: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) <118>/dev/ad0s2a: SUMMARY INFORMATION BAD (SALVAGED) <118>/dev/ad0s2a: BLK(S) MISSING IN BIT MAPS (SALVAGED) <118>/dev/ad0s2a: 3128 files, 65124 used, 232339 free (2075 frags, 28783 blocks, 0.7% fragmentation) <118>/dev/ad0s2d: 555694 files, 4042744 used, 4592176 free (80512 frags, 563958 blocks, 0.9% fragmentation) <118>Setting hostname: draco.nodomain.yet. <118>fxp0: no link ... <118>. <118>. <118>. <118>. <118>. <118>. <118>. <118>. <118>. <118>. <118>. <118> giving up <118>lo0: flags=8049 mtu 16384 <118> inet6 ::1 prefixlen 128 <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 <118> inet 127.0.0.1 netmask 0xff000000 <118>fxp0: flags=8843 mtu 1500 <118> options=8 <118> inet6 fe80::220:e0ff:fe64:53e7%fxp0 prefixlen 64 scopeid 0x1 <118> inet 192.168.150.150 netmask 0xffffff00 broadcast 192.168.150.255 <118> ether 00:20:e0:64:53:e7 <118> media: Ethernet autoselect (none) <118> status: no carrier <118>wi0: flags=8843 mtu 1500 <118> inet6 fe80::260:1dff:fef1:5ace%wi0 prefixlen 64 scopeid 0x5 <118> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 <118> ether 00:60:1d:f1:5a:ce <118> media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) <118> status: no carrier <118> ssid "" channel 7 <118> stationname "FreeBSD WaveLAN/IEEE node" <118> authmode OPEN privacy OFF txpowmax 100 bintval 100 Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc06474fa stack pointer = 0x28:0xd9927c78 frame pointer = 0x28:0xd9927c88 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 = 242 (netstat) trap number = 18 panic: integer divide fault Uptime: 3m32s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130794 pages) 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:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0637816 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0637aac in panic (fmt=0xc084d786 "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0806e70 in trap_fatal (frame=0xd9927c38, eva=0) at /usr/src/sys/i386/i386/trap.c:831 #4 0xc080699c in trap (frame= {tf_fs = 8, tf_es = -1063583704, tf_ds = -644743128, tf_edi = -1043227648, tf_esi = -1043227648, tf_ebp = -644711288, tf_isp = -644711324, tf_ebx = -1043227648, tf_edx = 0, tf_ecx = -1044130809, tf_eax = 179808996, tf_trapno = 18, tf_err = 0, tf_eip = -106 7158278, tf_cs = 32, tf_eflags = 66118, tf_esp = -1044130816, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:629 #5 0xc07f601a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc06474fa in link_elf_lookup_symbol (lf=0xc1d19c00, name=0xc1c3d400 "ddpstat", sym=0xd9927cac) at /usr/src/sys/kern/link_elf.c:1024 #7 0xc062a6a9 in kldsym (td=0xc1c20180, uap=0xd9927d04) at linker_if.h:27 #8 0xc0807187 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 3, tf_esi = 134619148, tf_ebp = -1077940760, tf_isp = -644711068, tf_ebx = 6716 86052, tf_edx = -1, tf_ecx = 2, tf_eax = 337, tf_trapno = 12, tf_err = 2, tf_eip = 672047443, tf_cs = 51, tf_eflags = 518, tf_esp = -1077940836, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:976 #9 0xc07f606f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #10 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up 6 #6 0xc06474fa in link_elf_lookup_symbol (lf=0xc1d19c00, name=0xc1c3d400 "ddpstat", sym=0xd9927cac) at /usr/src/sys/kern/link_elf.c:1024 1024 symnum = ef->buckets[hash % ef->nbuckets]; (kgdb) p ef->nbuckets $1 = 0 (kgdb) p *ef $2 = {lf = {ops = 0xc1957800, refs = 1, userrefs = 0, flags = 0, link = {tqe_next = 0x0, tqe_prev = 0xc197aa10}, filename = 0xc1cf39d0 "ipfw.ko", id = 7, address = 0x0, size = 0, ndeps = 0, deps = 0x0, common = {stqh_first = 0x0, stqh_last = 0xc1d19c30}, modules = {tqh_first = 0x0, tqh_last = 0xc1d19c38}, loaded = {tqe_next = 0x0, tqe_prev = 0x0}}, preloaded = 0, address = 0xc1dc7000 "\177ELF\001\001\001\t", dynamic = 0x0, nbuckets = 0, nchains = 0, buckets = 0x0, chains = 0x0, hash = 0x0, strtab = 0x0, strsz = 0, symtab = 0x0, got = 0x0, pltrel = 0x0, pltrelsize = 0, pltrela = 0x0, pltrelasize = 0, rel = 0x0, relsize = 0, rela = 0x0, relasize = 0, modptr = 0x0, ddbsymtab = 0x0, ddbsymcnt = 0, ddbstrtab = 0x0, ddbstrcnt = 0, symbase = 0x0, strbase = 0x0} (kgdb) q draco# ls -l ESCESC[ESCESC[ESC[Ksysctl -a |grep module^M kern.module_path: /boot/kernel;/boot/modules module 371 24K - 372 64,128 draco# ls -l /boot/kernel/kernel /boot/kernel/ipfw.ko^M -r-xr-xr-x 1 root wheel 49481 Oct 12 02:52 ESC[31m/boot/kernel/ipfw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6243399 Oct 11 19:15 ESC[31m/boot/kernel/kernelESC[39;49mESC[m^O draco# ls -l /boot/kerESC[Knel/^M total 20904 -r-xr-xr-x 1 root wheel 13994 Oct 12 02:51 ESC[31m3dfx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 55457 Oct 12 02:51 ESC[31maac.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4427 Oct 12 02:51 ESC[31maac_linux.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3296 Oct 12 02:51 ESC[31maccf_data.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5868 Oct 12 02:51 ESC[31maccf_http.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 354946 Oct 12 02:51 ESC[31macpi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16020 Oct 12 02:51 ESC[31macpi_asus.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11061 Oct 12 02:51 ESC[31macpi_fujitsu.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15271 Oct 12 02:51 ESC[31macpi_ibm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10348 Oct 12 02:51 ESC[31macpi_panasonic.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6599 Oct 12 02:51 ESC[31macpi_sony.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12179 Oct 12 02:51 ESC[31macpi_toshiba.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16673 Oct 12 02:51 ESC[31macpi_video.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 76402 Oct 12 02:51 ESC[31magp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24667 Oct 12 02:51 ESC[31maha.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18367 Oct 12 02:51 ESC[31mahb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 139320 Oct 12 02:51 ESC[31mahc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7787 Oct 12 02:51 ESC[31mahc_eisa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8541 Oct 12 02:51 ESC[31mahc_isa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 35982 Oct 12 02:51 ESC[31mahc_pci.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 210862 Oct 12 02:51 ESC[31mahd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25621 Oct 12 02:51 ESC[31maic.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 33417 Oct 12 02:51 ESC[31maio.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13718 Oct 12 02:52 ESC[31malpm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23085 Oct 12 02:51 ESC[31mamd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12669 Oct 12 02:52 ESC[31mamdpm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 32788 Oct 12 02:51 ESC[31mamr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5910 Oct 12 02:51 ESC[31maout.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 22507 Oct 12 02:51 ESC[31mapm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4233 Oct 12 02:53 ESC[31mapm_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 22379 Oct 12 02:51 ESC[31marcmsr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11594 Oct 12 02:51 ESC[31marcnet.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 27438 Oct 12 02:51 ESC[31masr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 51838 Oct 12 02:51 ESC[31mata.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7065 Oct 12 02:51 ESC[31matacard.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11693 Oct 12 02:51 ESC[31matadisk.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5846 Oct 12 02:51 ESC[31mataisa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 105636 Oct 12 02:51 ESC[31matapci.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16028 Oct 12 02:51 ESC[31matapicam.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 27513 Oct 12 02:51 ESC[31matapicd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11183 Oct 12 02:51 ESC[31matapifd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15336 Oct 12 02:51 ESC[31matapist.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 64243 Oct 12 02:51 ESC[31mataraid.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 160762 Oct 12 02:51 ESC[31math_hal.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8233 Oct 12 02:51 ESC[31math_rate.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 72628 Oct 12 02:51 ESC[31mbktr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4558 Oct 12 02:51 ESC[31mbktr_mem.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3765 Oct 12 02:53 ESC[31mblank_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25015 Oct 12 02:51 ESC[31mbridge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 226459 Oct 12 02:51 ESC[31mcam.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24071 Oct 12 02:51 ESC[31mcardbus.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 44068 Oct 12 02:51 ESC[31mcbb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 34595 Oct 12 02:51 ESC[31mcd9660.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4612 Oct 12 02:51 ESC[31mcd9660_iconv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 39897 Oct 12 02:51 ESC[31mciss.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 60155 Oct 12 02:51 ESC[31mcoda.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 63215 Oct 12 02:51 ESC[31mcoda5.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 36275 Oct 12 02:51 ESC[31mcpufreq.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 139419 Oct 12 02:51 ESC[31mcrypto.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12557 Oct 12 02:51 ESC[31mcryptodev.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9976 Oct 12 02:53 ESC[31mdaemon_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12115 Oct 12 02:52 ESC[31mdcons.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8235 Oct 12 02:52 ESC[31mdcons_crom.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 31352 Oct 12 02:52 ESC[31mdigi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17883 Oct 12 02:52 ESC[31mdigi_CX.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 69647 Oct 12 02:52 ESC[31mdigi_CX_PCI.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 68853 Oct 12 02:52 ESC[31mdigi_EPCX.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 70441 Oct 12 02:52 ESC[31mdigi_EPCX_PCI.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11483 Oct 12 02:52 ESC[31mdigi_Xe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 72938 Oct 12 02:52 ESC[31mdigi_Xem.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 73691 Oct 12 02:52 ESC[31mdigi_Xr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21420 Oct 12 02:52 ESC[31mdpt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6906 Oct 12 02:53 ESC[31mdragon_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 62656 Oct 12 02:52 ESC[31mdrm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 29932 Oct 12 02:52 ESC[31mdummynet.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3370 Oct 12 02:52 ESC[31melink.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9616 Oct 12 02:52 ESC[31mexca.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 61083 Oct 12 02:52 ESC[31mext2fs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4180 Oct 12 02:53 ESC[31mfade_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 40014 Oct 12 02:52 ESC[31mfdc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11679 Oct 12 02:52 ESC[31mfdescfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6793 Oct 12 02:53 ESC[31mfire_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 82029 Oct 12 02:52 ESC[31mfirewire.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21349 Oct 12 02:52 ESC[31mg_md.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6249 Oct 12 02:52 ESC[31mgeom_apple.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23370 Oct 12 02:52 ESC[31mgeom_bde.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11584 Oct 12 02:52 ESC[31mgeom_bsd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11748 Oct 12 02:52 ESC[31mgeom_ccd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20036 Oct 12 02:52 ESC[31mgeom_concat.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 44109 Oct 12 02:52 ESC[31mgeom_eli.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9464 Oct 12 02:52 ESC[31mgeom_fox.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18139 Oct 12 02:52 ESC[31mgeom_gate.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6301 Oct 12 02:52 ESC[31mgeom_gpt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17435 Oct 12 02:52 ESC[31mgeom_label.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11255 Oct 12 02:52 ESC[31mgeom_mbr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 71457 Oct 12 02:52 ESC[31mgeom_mirror.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12308 Oct 12 02:52 ESC[31mgeom_nop.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9793 Oct 12 02:52 ESC[31mgeom_pc98.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 78413 Oct 12 02:52 ESC[31mgeom_raid3.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19823 Oct 12 02:52 ESC[31mgeom_shsec.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24734 Oct 12 02:52 ESC[31mgeom_stripe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8845 Oct 12 02:52 ESC[31mgeom_sunlabel.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11613 Oct 12 02:52 ESC[31mgeom_uzip.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 66764 Oct 12 02:52 ESC[31mgeom_vinum.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5043 Oct 12 02:52 ESC[31mgeom_vol_ffs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5099 Oct 12 02:52 ESC[31mgeom_zero.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3765 Oct 12 02:53 ESC[31mgreen_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25748 Oct 12 02:52 ESC[31mhfa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6672 Oct 12 02:52 ESC[31mhfa_pci.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 38017 Oct 12 02:52 ESC[31mhifn.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 119214 Oct 12 02:52 ESC[31mhptmv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 61710 Oct 12 02:52 ESC[31mhwpmc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 46666 Oct 12 02:52 ESC[31mibcs2.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8254 Oct 12 02:51 ESC[31mibcs2_coff.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15598 Oct 12 02:52 ESC[31michsmb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9133 Oct 12 02:52 ESC[31michwd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17344 Oct 12 02:52 ESC[31mida.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 38589 Oct 12 02:52 ESC[31midt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 48527 Oct 12 02:51 ESC[31mif_an.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21007 Oct 12 02:51 ESC[31mif_ar.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18571 Oct 12 02:51 ESC[31mif_arl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 64688 Oct 12 02:51 ESC[31mif_ath.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18361 Oct 12 02:51 ESC[31mif_aue.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 31336 Oct 12 02:51 ESC[31mif_awi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16561 Oct 12 02:51 ESC[31mif_axe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24450 Oct 12 02:51 ESC[31mif_bfe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 43994 Oct 12 02:51 ESC[31mif_bge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 35928 Oct 12 02:52 ESC[31mif_bridge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13708 Oct 12 02:51 ESC[31mif_cdce.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13670 Oct 12 02:51 ESC[31mif_cm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 207497 Oct 12 02:51 ESC[31mif_cp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20272 Oct 12 02:51 ESC[31mif_cs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 166910 Oct 12 02:51 ESC[31mif_ct.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14389 Oct 12 02:52 ESC[31mif_cue.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 81333 Oct 12 02:52 ESC[31mif_cx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 43530 Oct 12 02:52 ESC[31mif_dc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 47963 Oct 12 02:52 ESC[31mif_de.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7555 Oct 12 02:52 ESC[31mif_disc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 50818 Oct 12 02:52 ESC[31mif_ed.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7721 Oct 12 02:52 ESC[31mif_ef.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11956 Oct 12 02:52 ESC[31mif_el.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 78439 Oct 12 02:52 ESC[31mif_em.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 46678 Oct 12 02:52 ESC[31mif_en.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25125 Oct 12 02:52 ESC[31mif_ep.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21266 Oct 12 02:52 ESC[31mif_ex.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8649 Oct 12 02:52 ESC[31mif_faith.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 74380 Oct 12 02:52 ESC[31mif_fatm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 30960 Oct 12 02:52 ESC[31mif_fe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14469 Oct 12 02:52 ESC[31mif_fwe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24125 Oct 12 02:52 ESC[31mif_fwip.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 37009 Oct 12 02:52 ESC[31mif_fxp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19206 Oct 12 02:52 ESC[31mif_gif.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14616 Oct 12 02:52 ESC[31mif_gre.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10635 Oct 12 02:52 ESC[31mif_harp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 58355 Oct 12 02:52 ESC[31mif_hatm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 26652 Oct 12 02:52 ESC[31mif_hme.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7887 Oct 12 02:52 ESC[31mif_ic.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23872 Oct 12 02:52 ESC[31mif_ie.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 35321 Oct 12 02:52 ESC[31mif_ipw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 38570 Oct 12 02:52 ESC[31mif_iwi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19016 Oct 12 02:52 ESC[31mif_kue.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19586 Oct 12 02:52 ESC[31mif_lge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23088 Oct 12 02:52 ESC[31mif_lnc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23019 Oct 12 02:52 ESC[31mif_my.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 48292 Oct 12 02:52 ESC[31mif_ndis.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 26691 Oct 12 02:53 ESC[31mif_nge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 61517 Oct 12 02:53 ESC[31mif_nve.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 200985 Oct 12 02:53 ESC[31mif_oltr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 85685 Oct 12 02:53 ESC[31mif_patm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20178 Oct 12 02:53 ESC[31mif_pcn.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 72996 Oct 12 02:52 ESC[31mif_ppp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 45000 Oct 12 02:53 ESC[31mif_ral.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 37597 Oct 12 02:53 ESC[31mif_ray.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 28101 Oct 12 02:53 ESC[31mif_re.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24380 Oct 12 02:53 ESC[31mif_rl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18733 Oct 12 02:53 ESC[31mif_rue.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20324 Oct 12 02:53 ESC[31mif_sbni.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13981 Oct 12 02:53 ESC[31mif_sbsh.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20987 Oct 12 02:53 ESC[31mif_sf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 31317 Oct 12 02:53 ESC[31mif_sis.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 37054 Oct 12 02:53 ESC[31mif_sk.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17275 Oct 12 02:52 ESC[31mif_sl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21272 Oct 12 02:53 ESC[31mif_sn.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23031 Oct 12 02:53 ESC[31mif_sr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25304 Oct 12 02:53 ESC[31mif_ste.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11449 Oct 12 02:52 ESC[31mif_stf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16512 Oct 12 02:52 ESC[31mif_tap.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 194135 Oct 12 02:53 ESC[31mif_ti.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25684 Oct 12 02:53 ESC[31mif_tl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17204 Oct 12 02:52 ESC[31mif_tun.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23308 Oct 12 02:53 ESC[31mif_tx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 85680 Oct 12 02:53 ESC[31mif_txp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19725 Oct 12 02:54 ESC[31mif_udav.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 29100 Oct 12 02:54 ESC[31mif_ural.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 27284 Oct 12 02:54 ESC[31mif_vge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14709 Oct 12 02:52 ESC[31mif_vlan.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 22950 Oct 12 02:54 ESC[31mif_vr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18953 Oct 12 02:54 ESC[31mif_vx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24549 Oct 12 02:54 ESC[31mif_wb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 121408 Oct 12 02:54 ESC[31mif_wi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 34039 Oct 12 02:54 ESC[31mif_xe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 40457 Oct 12 02:54 ESC[31mif_xl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8662 Oct 12 02:52 ESC[31miic.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12711 Oct 12 02:52 ESC[31miicbb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10948 Oct 12 02:52 ESC[31miicbus.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10768 Oct 12 02:52 ESC[31miicsmb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 26602 Oct 12 02:52 ESC[31miir.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13425 Oct 12 02:52 ESC[31mintpm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4254 Oct 12 02:52 ESC[31mio.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16430 Oct 12 02:52 ESC[31mip6fw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 33266 Oct 12 02:52 ESC[31mip_mroute.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13263 Oct 12 02:52 ESC[31mipdivert.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 49481 Oct 12 02:52 ESC[31mipfw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 178576 Oct 12 02:52 ESC[31mipl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 33291 Oct 12 02:52 ESC[31mips.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 99996 Oct 12 02:52 ESC[31misp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 474129 Oct 12 02:52 ESC[31mispfw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9466 Oct 12 02:52 ESC[31mjoy.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20310 Oct 12 02:52 ESC[31mkbdmux.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6243399 Oct 11 19:15 ESC[31mkernelESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 39830 Oct 12 02:52 ESC[31mlibalias.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15851 Oct 12 02:52 ESC[31mlibiconv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6320 Oct 12 02:52 ESC[31mlibmbpool.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7196 Oct 12 02:52 ESC[31mlibmchain.koESC[39;49mESC[m^O -rw------- 1 root wheel 36616 Oct 12 02:54 linker.hints -r-xr-xr-x 1 root wheel 22677 Oct 12 02:52 ESC[31mlinprocfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 107149 Oct 12 02:52 ESC[31mlinux.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14260 Oct 12 02:53 ESC[31mlogo_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7778 Oct 12 02:52 ESC[31mlpbb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13053 Oct 12 02:52 ESC[31mlpt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 31146 Oct 12 02:52 ESC[31mmac_biba.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16984 Oct 12 02:52 ESC[31mmac_bsdextended.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9632 Oct 12 02:52 ESC[31mmac_ifoff.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 30892 Oct 12 02:52 ESC[31mmac_lomac.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 28217 Oct 12 02:52 ESC[31mmac_mls.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4506 Oct 12 02:52 ESC[31mmac_none.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8913 Oct 12 02:52 ESC[31mmac_partition.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15039 Oct 12 02:52 ESC[31mmac_portacl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9193 Oct 12 02:52 ESC[31mmac_seeotheruids.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15066 Oct 12 02:52 ESC[31mmac_stub.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 37553 Oct 12 02:52 ESC[31mmac_test.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 61211 Oct 12 02:52 ESC[31mmach64.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20282 Oct 12 02:52 ESC[31mmcd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15451 Oct 12 02:52 ESC[31mmem.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 63772 Oct 12 02:52 ESC[31mmga.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 100309 Oct 12 02:52 ESC[31mmiibus.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 36936 Oct 12 02:52 ESC[31mmlx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 33602 Oct 12 02:52 ESC[31mmly.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 80354 Oct 12 02:52 ESC[31mmpt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 59726 Oct 12 02:52 ESC[31mmsdosfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4636 Oct 12 02:52 ESC[31mmsdosfs_iconv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11578 Oct 12 02:52 ESC[31mmse.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 37010 Oct 12 02:52 ESC[31mncp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19571 Oct 12 02:53 ESC[31mncv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 87487 Oct 12 02:53 ESC[31mndis.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 46968 Oct 12 02:53 ESC[31mnetgraph.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 194015 Oct 12 02:53 ESC[31mnfsclient.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 108673 Oct 12 02:53 ESC[31mnfsserver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5539 Oct 12 02:53 ESC[31mng_UI.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11037 Oct 12 02:53 ESC[31mng_async.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21204 Oct 12 02:53 ESC[31mng_atm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6178 Oct 12 02:53 ESC[31mng_atmllc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16046 Oct 12 02:53 ESC[31mng_atmpif.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8067 Oct 12 02:53 ESC[31mng_bluetooth.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13458 Oct 12 02:53 ESC[31mng_bpf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14032 Oct 12 02:53 ESC[31mng_bridge.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21537 Oct 12 02:53 ESC[31mng_bt3c.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 104396 Oct 12 02:53 ESC[31mng_btsocket.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 78286 Oct 12 02:53 ESC[31mng_ccatm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9559 Oct 12 02:53 ESC[31mng_cisco.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8848 Oct 12 02:53 ESC[31mng_device.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4188 Oct 12 02:53 ESC[31mng_echo.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8600 Oct 12 02:53 ESC[31mng_eiface.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8126 Oct 12 02:53 ESC[31mng_etf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12017 Oct 12 02:53 ESC[31mng_ether.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12357 Oct 12 02:53 ESC[31mng_fec.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7539 Oct 12 02:53 ESC[31mng_frame_relay.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9058 Oct 12 02:53 ESC[31mng_gif.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6821 Oct 12 02:53 ESC[31mng_gif_demux.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14517 Oct 12 02:53 ESC[31mng_h4.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 49189 Oct 12 02:53 ESC[31mng_hci.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5577 Oct 12 02:53 ESC[31mng_hole.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4296 Oct 12 02:53 ESC[31mng_hub.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10766 Oct 12 02:53 ESC[31mng_iface.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3789 Oct 12 02:53 ESC[31mng_ip_input.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6740 Oct 12 02:53 ESC[31mng_ipfw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16909 Oct 12 02:53 ESC[31mng_ksocket.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 60061 Oct 12 02:53 ESC[31mng_l2cap.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17148 Oct 12 02:53 ESC[31mng_l2tp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12481 Oct 12 02:53 ESC[31mng_lmi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12381 Oct 12 02:53 ESC[31mng_mppc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6891 Oct 12 02:53 ESC[31mng_nat.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17666 Oct 12 02:53 ESC[31mng_netflow.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9019 Oct 12 02:53 ESC[31mng_one2many.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21628 Oct 12 02:53 ESC[31mng_ppp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18418 Oct 12 02:53 ESC[31mng_pppoe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12872 Oct 12 02:53 ESC[31mng_pptpgre.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8320 Oct 12 02:53 ESC[31mng_rfc1490.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15742 Oct 12 02:53 ESC[31mng_socket.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10148 Oct 12 02:53 ESC[31mng_source.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4847 Oct 12 02:53 ESC[31mng_split.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9000 Oct 12 02:53 ESC[31mng_sppp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14813 Oct 12 02:53 ESC[31mng_sscfu.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 75212 Oct 12 02:53 ESC[31mng_sscop.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24507 Oct 12 02:53 ESC[31mng_sync_ar.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 27235 Oct 12 02:53 ESC[31mng_sync_sr.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7188 Oct 12 02:53 ESC[31mng_tcpmss.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7391 Oct 12 02:53 ESC[31mng_tee.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11356 Oct 12 02:53 ESC[31mng_tty.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 27443 Oct 12 02:53 ESC[31mng_ubt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 125023 Oct 12 02:53 ESC[31mng_uni.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13351 Oct 12 02:53 ESC[31mng_vjc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8737 Oct 12 02:53 ESC[31mng_vlan.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 167518 Oct 12 02:53 ESC[31mngatmbase.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8828 Oct 12 02:53 ESC[31mnmdm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23519 Oct 12 02:53 ESC[31mnsp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 44163 Oct 12 02:53 ESC[31mntfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4556 Oct 12 02:53 ESC[31mntfs_iconv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15452 Oct 12 02:53 ESC[31mnullfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 40754 Oct 12 02:53 ESC[31mnwfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8637 Oct 12 02:53 ESC[31mpadlock.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 54043 Oct 12 02:53 ESC[31mpccard.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8869 Oct 12 02:52 ESC[31mpcf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7714 Oct 12 02:53 ESC[31mpcfclock.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9266 Oct 12 02:53 ESC[31mpecoff.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 188030 Oct 12 02:53 ESC[31mpf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20237 Oct 12 02:53 ESC[31mplip.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11673 Oct 12 02:53 ESC[31mportalfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23588 Oct 12 02:53 ESC[31mppbus.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15123 Oct 12 02:53 ESC[31mppi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10323 Oct 12 02:53 ESC[31mpps.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21118 Oct 12 02:53 ESC[31mprocfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24518 Oct 12 02:53 ESC[31mpseudofs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18417 Oct 12 02:53 ESC[31mpst.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 65557 Oct 12 02:53 ESC[31mpuc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 51047 Oct 12 02:52 ESC[31mr128.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 100667 Oct 12 02:52 ESC[31mradeon.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5434 Oct 12 02:53 ESC[31mrain_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 45197 Oct 12 02:53 ESC[31mrandom.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19300 Oct 12 02:53 ESC[31mrc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3530 Oct 12 02:53 ESC[31mrc4.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 37811 Oct 12 02:53 ESC[31mreiserfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 30523 Oct 12 02:53 ESC[31mrp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8816 Oct 12 02:53 ESC[31ms3.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 31987 Oct 12 02:53 ESC[31msafe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 39921 Oct 12 02:52 ESC[31msbp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25952 Oct 12 02:52 ESC[31msbp_targ.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16823 Oct 12 02:53 ESC[31mscd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 34420 Oct 12 02:53 ESC[31mscsi_low.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 35771 Oct 12 02:53 ESC[31msio.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12322 Oct 12 02:52 ESC[31msis.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8046 Oct 12 02:51 ESC[31msmapi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9121 Oct 12 02:52 ESC[31msmb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 132360 Oct 12 02:53 ESC[31msmbfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6612 Oct 12 02:51 ESC[31msmbios.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10807 Oct 12 02:52 ESC[31msmbus.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 5712 Oct 12 02:53 ESC[31msnake_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16822 Oct 12 02:53 ESC[31msnd_ad1816.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 16507 Oct 12 02:53 ESC[31msnd_als4000.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17529 Oct 12 02:53 ESC[31msnd_cmi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18722 Oct 12 02:53 ESC[31msnd_cs4281.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 30814 Oct 12 02:53 ESC[31msnd_csa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9814 Oct 12 02:53 ESC[31msnd_driver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 45835 Oct 12 02:53 ESC[31msnd_ds1.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 27423 Oct 12 02:53 ESC[31msnd_emu10k1.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 22121 Oct 12 02:53 ESC[31msnd_es137x.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21384 Oct 12 02:53 ESC[31msnd_ess.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15796 Oct 12 02:53 ESC[31msnd_fm801.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19285 Oct 12 02:53 ESC[31msnd_ich.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 43367 Oct 12 02:53 ESC[31msnd_maestro.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 38786 Oct 12 02:53 ESC[31msnd_maestro3.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 46976 Oct 12 02:53 ESC[31msnd_mss.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 68790 Oct 12 02:53 ESC[31msnd_neomagic.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17230 Oct 12 02:53 ESC[31msnd_sb16.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15738 Oct 12 02:53 ESC[31msnd_sb8.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 15549 Oct 12 02:53 ESC[31msnd_sbc.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18621 Oct 12 02:53 ESC[31msnd_solo.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18757 Oct 12 02:53 ESC[31msnd_t4dwave.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 34470 Oct 12 02:53 ESC[31msnd_uaudio.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19170 Oct 12 02:53 ESC[31msnd_via8233.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 14769 Oct 12 02:53 ESC[31msnd_via82c686.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 18836 Oct 12 02:53 ESC[31msnd_vibes.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10306 Oct 12 02:53 ESC[31msnp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 114300 Oct 12 02:53 ESC[31msound.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11786 Oct 12 02:53 ESC[31mspeaker.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8136 Oct 12 02:53 ESC[31msplash_bmp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 6184 Oct 12 02:53 ESC[31msplash_pcx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 60709 Oct 12 02:53 ESC[31msppp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4870 Oct 12 02:53 ESC[31mstar_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23329 Oct 12 02:53 ESC[31mstg.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9299 Oct 12 02:53 ESC[31mstreams.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 68127 Oct 12 02:53 ESC[31msym.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17982 Oct 12 02:53 ESC[31msysvmsg.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 21080 Oct 12 02:53 ESC[31msysvsem.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17986 Oct 12 02:53 ESC[31msysvshm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4785 Oct 12 02:52 ESC[31mtdfx.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 28293 Oct 12 02:53 ESC[31mtrm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 56257 Oct 12 02:53 ESC[31mtwa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 34999 Oct 12 02:53 ESC[31mtwe.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 52248 Oct 12 02:53 ESC[31muart.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10142 Oct 12 02:53 ESC[31mubsa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 39361 Oct 12 02:53 ESC[31mubsec.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12765 Oct 12 02:53 ESC[31mubser.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9235 Oct 12 02:53 ESC[31mubtbcmfw.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9794 Oct 12 02:53 ESC[31mucom.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10449 Oct 12 02:54 ESC[31mucycom.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12959 Oct 12 02:54 ESC[31mudbp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 25201 Oct 12 02:54 ESC[31mudf.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 4536 Oct 12 02:54 ESC[31mudf_iconv.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7449 Oct 12 02:54 ESC[31mufm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9116 Oct 12 02:54 ESC[31muftdi.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 19504 Oct 12 02:54 ESC[31mugen.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11137 Oct 12 02:54 ESC[31muhid.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 22255 Oct 12 02:54 ESC[31mukbd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 11430 Oct 12 02:54 ESC[31mulpt.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 26437 Oct 12 02:54 ESC[31mumass.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9618 Oct 12 02:54 ESC[31mumct.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10589 Oct 12 02:54 ESC[31mumodem.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12659 Oct 12 02:54 ESC[31mums.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 42380 Oct 12 02:54 ESC[31munionfs.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13090 Oct 12 02:54 ESC[31muplcom.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8869 Oct 12 02:54 ESC[31murio.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 128976 Oct 12 02:54 ESC[31musb.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 10398 Oct 12 02:54 ESC[31muscanner.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17393 Oct 12 02:54 ESC[31mutopia.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8192 Oct 12 02:54 ESC[31muvisor.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 12514 Oct 12 02:54 ESC[31muvscom.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17324 Oct 12 02:54 ESC[31mvesa.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 17320 Oct 12 02:52 ESC[31mviapm.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 23948 Oct 12 02:54 ESC[31mvkbd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 9979 Oct 12 02:51 ESC[31mvpd.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 20255 Oct 12 02:54 ESC[31mvpo.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 7481 Oct 12 02:53 ESC[31mwarp_saver.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 118073 Oct 12 02:54 ESC[31mwlan.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8401 Oct 12 02:54 ESC[31mwlan_acl.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 24940 Oct 12 02:54 ESC[31mwlan_ccmp.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 13073 Oct 12 02:54 ESC[31mwlan_tkip.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 8249 Oct 12 02:54 ESC[31mwlan_wep.koESC[39;49mESC[m^O -r-xr-xr-x 1 root wheel 3881 Oct 12 02:54 ESC[31mwlan_xauth.koESC[39;49mESC[m^O draco# uname -a^M FreeBSD draco.nodomain.yet 6.0-RC1 FreeBSD 6.0-RC1 #0: Tue Oct 11 19:15:17 CST 2005 benjsc@draco.nodomain.yet:/usr/obj/usr/src/ sys/GENERIC i386 draco# exit^M exit Script done on Thu Oct 13 08:29:28 2005 From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 15:04:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A176B16A41F for ; Wed, 12 Oct 2005 15:04:47 +0000 (GMT) (envelope-from stanley.jobson@gmx.ch) Received: from sigma.informatik.hu-berlin.de (sigma.informatik.hu-berlin.de [141.20.20.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF97E43D45 for ; Wed, 12 Oct 2005 15:04:46 +0000 (GMT) (envelope-from stanley.jobson@gmx.ch) Received: from tyrael.linnet (p54BCF7B0.dip.t-dialin.net [84.188.247.176]) (authenticated bits=0) by sigma.informatik.hu-berlin.de (8.13.4+Sun/8.13.4/INF-2.0-MA-SOLARIS-2.10) with ESMTP id j9CF4L03020928 for ; Wed, 12 Oct 2005 17:04:42 +0200 (CEST) Date: Wed, 12 Oct 2005 17:02:58 +0200 From: stanley jobson To: freebsd-current@freebsd.org Message-Id: <20051012170258.669d4f45.stanley.jobson@gmx.ch> In-Reply-To: <434BCDF6.3090303@samsco.org> References: <434BCDF6.3090303@samsco.org> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Status: No (sigma) X-Spam-Status: No, score=1.8 required=5.0 tests=FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on rabe X-Mailman-Approved-At: Thu, 13 Oct 2005 12:50:07 +0000 Subject: Re: FreeBSD 6.0-RC1 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: Wed, 12 Oct 2005 15:04:47 -0000 hi, > - The QEMU and VMWare packages are known to expose problems in the > IDE CDROM driver during OS install. will this be corrected for 6-stable? what about vmware 4 and vmware 5 having in the ports? anybody working on that? what are the probs? anybody using vmware3 on [56]-stable? i tried a year ago and had different probs with system stability :( ... thx regards, stan From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 03:54:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8CAD16A41F; Thu, 13 Oct 2005 03:54:21 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FF0E43D45; Thu, 13 Oct 2005 03:54:21 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from [192.168.168.135] (unknown [211.96.21.221]) by gddsn.org.cn (Postfix) with ESMTP id 979D838CB4D; Thu, 13 Oct 2005 11:54:15 +0800 (CST) Message-ID: <434DDA4A.2060701@gddsn.org.cn> Date: Thu, 13 Oct 2005 11:53:46 +0800 From: Suken Woo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.7.7) Gecko/20050424 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: mobile@freebsd.org, hardware@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Oct 2005 12:50:07 +0000 Cc: Subject: Netgear WG511 drivers help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 03:54:21 -0000 lists: the Netgear WG511 dosen't support on freebsd and ndis wrapper doesn't work either anybody could give any help?? From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:19:40 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F3316A420; Thu, 13 Oct 2005 13:19:40 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E76543D46; Thu, 13 Oct 2005 13:19:40 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 7665A2C43D; Thu, 13 Oct 2005 15:19:39 +0200 (CEST) Date: Thu, 13 Oct 2005 15:19:39 +0200 From: Thomas Quinot To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051013131939.GA46990@melusine.cuivre.fr.eu.org> References: <20051009200141.GA85570@melusine.cuivre.fr.eu.org> <09BF04FC-B401-4EFF-9FE1-CA20D58D651B@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09BF04FC-B401-4EFF-9FE1-CA20D58D651B@FreeBSD.org> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.8i Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-BETA5: Sees only first ATA RAID volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 13:19:41 -0000 * Søren Schmidt, 2005-10-10 : > /* > * update our knowledge about the array config based on generation > * we only grap the first volume description (yet) since the > * BIOS'n I have access to puts crap into the following ones > */ > > There's your explanation :) Thanks Søren! > When/If I get my hands on HW that supports this I'll add the support > to the ataraid driver.. The set up of this machine is far from finished here, so if you want me to do some experiments please let me know. Thomas. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:21:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 307BB16A41F for ; Thu, 13 Oct 2005 13:21:40 +0000 (GMT) (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 87EFA43D6D for ; Thu, 13 Oct 2005 13:21:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp224-200.lns2.adl4.internode.on.net [203.122.224.200]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9DDLPgI007676 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Oct 2005 22:51:25 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 22:51:10 +0930 User-Agent: KMail/1.8.2 References: <434DDA4A.2060701@gddsn.org.cn> In-Reply-To: <434DDA4A.2060701@gddsn.org.cn> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1359376.jSpaN8C57v"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510132251.18650.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Suken Woo Subject: Re: Netgear WG511 drivers help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 13:21:40 -0000 --nextPart1359376.jSpaN8C57v Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 13 Oct 2005 13:23, Suken Woo wrote: > the Netgear WG511 dosen't support on freebsd and ndis wrapper doesn't > work either > anybody could give any help?? "ndis wrapper doesn't work" is a worthless bug report. What version of FreeBSD? What driver? What are the results? =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 --nextPart1359376.jSpaN8C57v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTl9O5ZPcIHs/zowRAmpwAJ9hb7pbztPXlxNpbUmXA8OW580ikwCdH/id OYoVjf7rx3tswyhWcLsqEMM= =zpf1 -----END PGP SIGNATURE----- --nextPart1359376.jSpaN8C57v-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:28:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346D816A41F for ; Thu, 13 Oct 2005 13:28:13 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD6F443D48 for ; Thu, 13 Oct 2005 13:28:12 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j9DDSB9i080698; Thu, 13 Oct 2005 08:28:11 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434E60D6.3030402@centtech.com> Date: Thu, 13 Oct 2005 08:27:50 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> In-Reply-To: <200510131412.23525.max@love2party.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1131/Wed Oct 12 15:35:32 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 13:28:13 -0000 Max Laier wrote: > On Thursday 13 October 2005 13:36, Eric Anderson wrote: > >>[resend to -current for broader test audience] >> >>I've just finished the first version of ufsstat, a tool to show local >>filesystem statistics much like nfsstat does for NFS. The patch and >>tool is against 6.0, but it will probably apply and work fine under >>-CURRENT and possibly 5.x as well. >> >>I'm looking for bug reports, comments/suggestions on style(9), and >>anything else, since this is my first C project, and of course first >>real FreeBSD contribution. :) > > > The patch contains some jitter in the first three or four files due to older > versions in src-patched. As all the statistic gathering is #ifdef'ed it > should not hurt performance in the disabled case. It will look nicer if you > define a macro to update statistics like: > > #ifdef UFS_STATS > #define UFS_STATS_UPDATE(field) ufsstats.field++ > #else > #define UFS_STATS_UPDATE(field) > #end > > This will in turn only use one line per update point and you don't have to do > the ugly: > #ifdef UFS_STATS > ufsstats.fsync++; > #endif Thanks - great suggestion! I'll do that. Any ideas how to remove the FBSDID line jitter from the patches? I mean a 'correct' way - I could easily do it with some hacks/scripts/etc, but maybe there is a better way to do this. > Also, make sure to declare "extern struct ufsstats ufsstats" in ufsstats.h > under _KERNEL and define it in just one place. As is, you don't record the > updates from ffs_vnops.c into the right structure. Finally, you should > consider 64 bit counter for some, if not all, fields as they will overflow > quickly. Ok - I'm looking at that now. For the 64bit counters, I can only guess at most of the ones that will be used a lot, so is the correct way to do this to be very conservative and set most to type int, and the ones I think will be large, to int64_t, or just set them all to 64bit and be done with it? >>To use it, do this: >>cd /tmp >>fetch http://www.googlebit.com/software/ufsstat/ufsstat-20051011.tar.gz >>cd /usr >>tar xvzf /tmp/ufsstat-20051011.tar.gz >>patch <./ufsstats.patch >> >>add: >>OPTIONS UFS_STAT >>to your kernel. >> >>Rebuild and install world/kernel. >> >>Now, you can use ufsstat to show you statistics from your local >>filesystems, like this: >> >># ufsstat >> Create Remove Link Symlink Mkdir Rmdir Rename >> 289048 794043 4361 12558 25796 117739 0 >> GetAttr SetAttr Open Close ReadDir ReadLink VInit >> 64868230 759824 10701553 9891642 5042948 0 45315645 >> Chmod Chown Whiteout Strategy Access Mknod NewInode >> 409782 79612 0 4020035 0 3 0 >> Fsync SyncVnode LockVnode RdVnode WrVNode >> 0 0 0 0 0 >> ExtRead Extwrite FndExtAtt RdExtAttr OpnExtAtt ClseExtAt ExtStrtgy >> 0 0 0 0 0 0 0 >> >>or watch over time with the -w switch. >> >>I have not done any performance testing yet to see if it impacts >>filesystem performance by any measurable amount, so if someone does do >>this testing before I do, please post your results! > > > I don't think you can measure one single interger (or 64bit) increase in face > of a operation that has to access backing store. Even if there is a > performance hit, you don't have to build your kernel with the option enabled. I was thinking of doing some accumulative tests - say 10000 various operations without, then those same ops (in the same order, on the same disk, freshly newfs'ed again) with it enabled. > It might be (more) interesting to have these stats on a per-mountpoint basis. > Not sure if you have enough state available to record all of the above, but > since you asked for input - this might be worth investigating. I agree, and have thought about that. I expected this would be the first feature someone ask about. :) I'm not sure if it would be best to store all filesystems someone in one sysctl area, or have a sysctl for each mounted filesystem, or something else. Remember, I'm *very new* to this, so any hints or poking in the right direction is very helpful! Thanks for the input so far! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:43:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53BED16A41F for ; Thu, 13 Oct 2005 13:43:40 +0000 (GMT) (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 D980543D46 for ; Thu, 13 Oct 2005 13:43:39 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EQ3JL-0004ka-H3 for freebsd-current@freebsd.org; Thu, 13 Oct 2005 15:39:55 +0200 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Oct 2005 15:39:55 +0200 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Oct 2005 15:39:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Joshua Coombs" Date: Thu, 13 Oct 2005 09:38:13 -0400 Lines: 9 Message-ID: References: <200510131331.27906.thierry@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: news Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 13:43:40 -0000 Welp, while I have no real help, I can point out this was reported by another user on the stable list, QEMU + RC1 == no ed I'm kinda dreading upgrading my 386... I'll pull down the generic kernel and do a test boot to see if it's a QEMU thing or a reguression in RC1 Joshua Coombs From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:48:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 107C616A41F for ; Thu, 13 Oct 2005 13:48:44 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 603E043D48 for ; Thu, 13 Oct 2005 13:48:44 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so402943nzk for ; Thu, 13 Oct 2005 06:48:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=m7GeMy7FGEjvhdCeflRjasG6aMGFiF43ycnI72ROltaegyb9GbrcoSLU562GN+CUvFWIbdWnUqM4aUXHej26DPCSvtFFEGcrZAEzAOhGfstjYl4CorLkua7fx51kyqanuniRsdktnSpHpsyefsg7vSf/el+yHnoXrK/H8gcwcH4= Received: by 10.36.47.8 with SMTP id u8mr2221043nzu; Thu, 13 Oct 2005 06:48:43 -0700 (PDT) Received: by 10.36.134.19 with HTTP; Thu, 13 Oct 2005 06:48:43 -0700 (PDT) Message-ID: <621b657f0510130648m57487570s508b16e729a351c4@mail.gmail.com> Date: Thu, 13 Oct 2005 10:48:43 -0300 From: Felipe openglx Sender: felipegrazziotin@gmail.com To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: 6.0-RC1: reboot when trying to load X.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 13:48:45 -0000 Hi all, this is my first post, and I'm quite new to FreeBSD. Don't push me too hard= :) Last night I've upgraded a (well) running FreeBSD-5.4 install to 6.0-RC1 and had it running without problems. Well, mind you, ALMOST without problems. When trying to start X.org server (using GDM, using "startx" command line, or even using "X" command line), my machine freezes for a few seconds before rebooting instantly. My first thought was that the X.org port wasn't compiled for 6.0-RC1, so I recompiled it. Nope, it still crashes. So I ran X with verbose level 9, and got this (if this isn't the right place to paste large text blocks, SORRY! Just tell me where should I read the mailing-lists etiquete): openglx@volahia:~$ X -verbose 9 -logverbose 9 tty08 :0 X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: FreeBSD 6.0 i386 [ELF] Current Operating System: FreeBSD volahia.starbyte.net 6.0-RC1 FreeBSD 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 =20 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 13 October 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (=3D=3D) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 13 10:32:08 2005 (=3D=3D) Using config file: "/usr/X11R6/lib/X11/xorg.conf" (=3D=3D) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist. Entry deleted from font path. (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/li= b/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts= /100dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" (**) Option "DontZap" (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 ABI class: X.Org Video Driver, version 0.7 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages =3D 0x03, oldVal1 =3D 0x00000000, mode1Res1 =3D 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1039,0630 card 0000,0000 rev 21 class 06,00,00 hdr = 80 (II) PCI: 00:00:1: chip 1039,5513 card 1039,5513 rev d0 class 01,01,8a hdr = 80 (II) PCI: 00:01:0: chip 1039,0008 card 0000,0000 rev 00 class 06,01,00 hdr = 80 (II) PCI: 00:01:1: chip 1039,0900 card 1039,0900 rev 83 class 02,00,00 hdr = 00 (II) PCI: 00:01:4: chip 1039,7018 card 1039,7018 rev 02 class 04,01,00 hdr = 00 (II) PCI: 00:02:0: chip 1039,0001 card 0000,0000 rev 00 class 06,04,00 hdr = 01 (II) PCI: 01:00:0: chip 1039,6300 card 1039,6300 rev 21 class 03,00,00 hdr = 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:1:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:2:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x0000c000 - 0x0000cfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xefe00000 - 0xefefffff (0x100000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xdfc00000 - 0xefcfffff (0x10100000) MX[B] (--) PCI:*(1:0:0) Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D rev 33, Mem @ 0xe0000000/27, 0xefee0000/17, I/O @ 0xcc80/7 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xf4000000 from 0xf7ffffff to 0xf3ffffff (II) Active PCI resource ranges: [0] -1 0 0xf3fff000 - 0xf3ffffff (0x1000) MX[B]E [1] -1 0 0xf3ffe000 - 0xf3ffffff (0x2000) MX[B]E [2] -1 0 0xf4000000 - 0xf3ffffff (0x0) MX[B]EO [3] -1 0 0xefee0000 - 0xefefffff (0x20000) MX[B](B) [4] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [5] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E [6] -1 0 0x0000dc00 - 0x0000dcff (0x100)(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "dri" (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a (II) Module drm: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension RECORD (II) LoadModule: "xtrap" (II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a (II) Module xtrap: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DEC-XTRAP (II) LoadModule: "freetype" (II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so (II) Module freetype: vendor=3D"X.Org Foundation & the After X-TT Project" compiled for 6.8.2, module version =3D 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font FreeType (II) LoadModule: "type1" (II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a (II) Module type1: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Type1 (II) Loading font CID (II) LoadModule: "sis" (II) Loading /usr/X11R6/lib/modules/drivers/sis_drv.o (II) Module sis: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 0.7.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) LoadModule: "kbd" (II) Loading /usr/X11R6/lib/modules/input/kbd_drv.o (II) Module kbd: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620, SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, SIS315H, SIS315PRO, SIS550, SIS650/M650/651/740, SIS330(Xabre), SIS660/661FX/M661FX/M661MX/741/741GX/M741/760/M760, SIS340 (II) Primary Device is: PCI 01:00:0 (**) Chipset override: SIS630/730 (**) Chipset SIS630/730 found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xf3fff000 - 0xf3ffffff (0x1000) MX[B]E [6] -1 0 0xf3ffe000 - 0xf3ffefff (0x1000) MX[B]E [7] -1 0 0xf4000000 - 0xf3ffffff (0x0) MX[B]EO [8] -1 0 0xefee0000 - 0xefefffff (0x20000) MX[B](B) [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E [13] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B]E [14] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [15] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [16] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [17] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [18] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [19] -1 0 0x0000cc80 - 0x0000ccff (0x80) IX[B](B) (II) resource ranges after probing: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xf3fff000 - 0xf3ffffff (0x1000) MX[B]E [6] -1 0 0xf3ffe000 - 0xf3ffefff (0x1000) MX[B]E [7] -1 0 0xf4000000 - 0xf3ffffff (0x0) MX[B]EO [8] -1 0 0xefee0000 - 0xefefffff (0x20000) MX[B](B) [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E [16] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B]E [17] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E [18] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [19] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [20] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [21] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [22] -1 0 0x0000cc80 - 0x0000ccff (0x80) IX[B](B) [23] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [24] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor=3D"X.Org Foundation" compiled for 6.8.2, module version =3D 0.1.0 ABI class: X.Org Video Driver, version 0.7 (II) SIS(0): SiS driver (2004/08/20-1) (II) SIS(0): Copyright (C) 2001-2004 Thomas Winischhofer and others (II) SIS(0): Compiled for X.org version 6.8.2.0 (II) SIS(0): See http://www.winischhofer.net/linuxsisvga.shtml for documentation and updates (--) SIS(0): This adapter is primary display adapter (=3D=3D) SIS(0): Write-combining range (0xa0000,0x10000) was already clear (II) SIS(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0xc90= 0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor=3D"X.Org Foundation" compiled for 6.8.2 [and stops there. At this point the machine starts to reboot itself. I've managed to get that information connecting from a remote host using SSH.]. volahia is the machine name, as you may wonder. It's a Pentium III 1GHz, 512MB RAM, with three IDE devices (two HDs and one CD-ROM). It has everything "on-board", where: * SiS900 ethernet card (working perfectly) * Sis7018 sound card (have a few problems recording sound, but it isn't the matter now) * SiS630 video card (looks like there's some driver problem, are you sure that "ramdac" should be loaded for on-board video cards?) The dmesg output for me: openglx@volahia:~$ dmesg Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1002.28-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 Features=3D0x387f9ff real memory =3D 520028160 (495 MB) avail memory =3D 499531776 (476 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 0 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 0 on acpi0 pci_link4: irq 0 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf4000000-0xf7ffffff at device 0.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 0.1 on pci0 ata0: on atapci0 ata1: on atapci0 isab0: at device 1.0 on pci0 isa0: on isab0 sis0: port 0xdc00-0xdcff mem 0xf3ffe000-0xf3ffefff irq 11 at device 1.1 on pci0 miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:07:95:c4:65:80 pcm0: port 0xde00-0xdeff mem 0xf3fff000-0xf3ffffff irq 10 at device 1.4 on pci0 pcm0: pcm0: [GIANT-LOCKED] pcib1: at device 2.0 on pci0 pci1: on pcib1 drm0: port 0xcc80-0xccff mem 0xe0000000-0xe7ffffff,0xefee0000-0xefefffff at device 0.0 on pci1 info: [drm] AGP at 0xf4000000 64MB info: [drm] Initialized sis 1.1.0 20030826 on minor 0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A 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/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xd3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> 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 1002277240 Hz quality 800 Timecounters tick every 1.000 msec ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: 39083MB at ata0-master UDMA33 ad1: DMA limited to UDMA33, controller found non-ATA66 cable ad1: 114498MB at ata0-slave UDMA33 acd0: CDRW at ata1-slave UDMA33 Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: /media/ad1s1d was not properly dismounted WARNING: /media/ad1s4d was not properly dismounted sis0: link state changed to UP no matching session [Ignore the "no matching session" error, it is related to PPPoE sessioning]= . I had to disable GDM auto-start, otherwise the machine would be rebooting itself everytime. Any idea on how we should work on that X.org problem? Note that the machine was working perfectly on FreeBSD-5.4, FreeBSD-5.2.1, Linux (Debian 3.0 and 3.1, Slackware 9, 9.1, 10), Windows (XP, 98), and FreeeDOS. If more information if needed, I can provide. Thanks in advance. -- openglx@StarByte.net From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:49:43 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAD516A41F; Thu, 13 Oct 2005 13:49:43 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D56043D58; Thu, 13 Oct 2005 13:49:40 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9DDlokN062640; Thu, 13 Oct 2005 15:47:50 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <20051013131939.GA46990@melusine.cuivre.fr.eu.org> References: <20051009200141.GA85570@melusine.cuivre.fr.eu.org> <09BF04FC-B401-4EFF-9FE1-CA20D58D651B@FreeBSD.org> <20051013131939.GA46990@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Thu, 13 Oct 2005 15:49:34 +0200 To: Thomas Quinot X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-BETA5: Sees only first ATA RAID volume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 13:49:44 -0000 On 13/10/2005, at 15:19, Thomas Quinot wrote: > * S=F8ren Schmidt, 2005-10-10 : >> /* >> * update our knowledge about the array config based on =20 >> generation >> * we only grap the first volume description (yet) since the >> * BIOS'n I have access to puts crap into the following ones >> */ >> >> There's your explanation :) >> > Thanks S=F8ren! > >> When/If I get my hands on HW that supports this I'll add the support >> to the ataraid driver.. >> > The set up of this machine is far from finished here, so if you =20 > want me > to do some experiments please let me know. Hmm, dumps of the metadata (last 2 sectors on the disks) from various =20= RAID setups that uses more than 1 volume with description of the =20 exact layout setup in the BIOS would be helpfull... S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:05:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0517516A41F for ; Thu, 13 Oct 2005 14:05:40 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF5D43D4C for ; Thu, 13 Oct 2005 14:05:39 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-112-178.hsd1.ma.comcast.net ([66.30.112.178]) by comcast.net (rwcrmhc12) with ESMTP id <2005101314053801400l5n1te>; Thu, 13 Oct 2005 14:05:38 +0000 Received: from c-66-30-112-178.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j9DE5axK010330; Thu, 13 Oct 2005 10:05:36 -0400 (EDT) (envelope-from rodrigc@c-66-30-112-178.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-112-178.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j9DE5aOM010329; Thu, 13 Oct 2005 10:05:36 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 13 Oct 2005 10:05:36 -0400 From: Craig Rodrigues To: Eric Anderson Message-ID: <20051013140536.GA10247@crodrigues.org> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <434E60D6.3030402@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434E60D6.3030402@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 14:05:40 -0000 On Thu, Oct 13, 2005 at 08:27:50AM -0500, Eric Anderson wrote: > Thanks - great suggestion! I'll do that. Any ideas how to remove the > FBSDID line jitter from the patches? When you check out the files from CVS, do not expand the CVS keywords by doing: cvs co -kk -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:21:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CED2A16A41F for ; Thu, 13 Oct 2005 14:21:28 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A8C443D48 for ; Thu, 13 Oct 2005 14:21:28 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 7712B3FDE7 for ; Thu, 13 Oct 2005 16:21:27 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9DELEHl021680; Thu, 13 Oct 2005 16:21:17 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 16:21:05 +0200 User-Agent: KMail/1.8.2 References: <200510131331.27906.thierry@herbelot.com> In-Reply-To: X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510131621.07299.thierry@herbelot.com> Cc: Joshua Coombs Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 13 Oct 2005 14:21:28 -0000 Le Thursday 13 October 2005 15:38, Joshua Coombs a écrit : > Welp, while I have no real help, I can point out this was reported by > another user on the stable list, QEMU + RC1 == no ed well, I should have looked there before posting here ;-) (sorry for the excellent Michel talon at lpthe.jussieu.fr : I should have seeen your post) > I'm kinda dreading upgrading my 386... I'll pull down the generic > kernel and do a test boot to see if it's a QEMU thing or a reguression > in RC1 for me, it's definitely a qemu thing : I have two other machines upgraded to 6.0 post-RC1, and both are working *fine* ; moreover one is a notebook with a pcmcia ed(4), and this NIC works perfectly (the issue is therefore seen only on qemu) TfH From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:26:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A15F16A41F for ; Thu, 13 Oct 2005 14:26:40 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from smtp206.mail.sc5.yahoo.com (smtp206.mail.sc5.yahoo.com [216.136.129.96]) by mx1.FreeBSD.org (Postfix) with SMTP id 04CCD43D46 for ; Thu, 13 Oct 2005 14:26:39 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: (qmail 19589 invoked from network); 13 Oct 2005 14:02:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Received:Subject:From:To:In-Reply-To:References:Content-Type:Date:Message-Id:Mime-Version:X-Mailer:Content-Transfer-Encoding; b=OyNJ5Yx9yNHOrfYSt6Kf2NnruDdTHh7AyfDdI8aTDHQIVirxTTwHZxg0DgttEnPtMh5hYh2dKdCeeccWgcv0zlHd5SySDORf7PDRy/Vd4+2yApGQPGNJkRWe/Sy9otRV9TltfUBnMCBb9bCRygTz9BdedOeJwFQGyppHDz58xtE= ; Received: from unknown (HELO 201-1-112-194.dsl.telesp.net.br) (ricardo?bsd@201.1.112.194 with plain) by smtp206.mail.sc5.yahoo.com with SMTP; 13 Oct 2005 14:02:50 -0000 From: "Ricardo A. Reis" To: current@freebsd.org In-Reply-To: <434BCDF6.3090303@samsco.org> References: <434BCDF6.3090303@samsco.org> Content-Type: text/plain; charset=iso8859-1 Date: Thu, 13 Oct 2005 08:02:30 -0300 Message-Id: <1129201350.13257.9.camel@myfreebsd.homeunix.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 14:26:40 -0000 Hi All, I'm very happy with this rc, exist a possibility to import patch of pr 57641 before final RELEASE? I use this patch in RELENG_5 for jail storage with MFS. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/57641 Em Ter, 2005-10-11 às 08:36 -0600, Scott Long escreveu: > Announcement > ------------ > > The release engineering team is proud to announce the availability of > FreeBSD 6.0. > > We encourage everyone to help with testing so any final bugs can be > identified and worked out. Availability of ISO images is given below. > If you have an older system you want to update using the normal > CVS/cvsup source based upgrade the branch tag to use is RELENG_6_0 > Problem reports can be submitted using the send-pr(1) command. This > will likely be the last release candidate before the final release > of FreeBSD 6.0. Ricardo A. Reis UNIFESP - DIS Unix and Network Admin _______________________________________________________ Promoção Yahoo! Acesso Grátis: a cada hora navegada você acumula cupons e concorre a mais de 500 prêmios! Participe! http://yahoo.fbiz.com.br/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:50:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46E9A16A41F for ; Thu, 13 Oct 2005 14:50:52 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A895B43D45 for ; Thu, 13 Oct 2005 14:50:51 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EQ4PH-0003h7-OH; Thu, 13 Oct 2005 16:50:13 +0200 Date: Thu, 13 Oct 2005 16:50:43 +0200 From: Marcin Jessa To: Felipe openglx Message-Id: <20051013165043.57db7a99.lists@yazzy.org> In-Reply-To: <621b657f0510130648m57487570s508b16e729a351c4@mail.gmail.com> References: <621b657f0510130648m57487570s508b16e729a351c4@mail.gmail.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: current@freebsd.org Subject: Re: 6.0-RC1: reboot when trying to load X.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 14:50:52 -0000 On Thu, 13 Oct 2005 10:48:43 -0300 Felipe openglx wrote: > Hi all, > > this is my first post, and I'm quite new to FreeBSD. Don't push me > too hard :) > > Last night I've upgraded a (well) running FreeBSD-5.4 install to > 6.0-RC1 and had it running without problems. Well, mind you, ALMOST > without problems. > > When trying to start X.org server (using GDM, using "startx" command > line, or even using "X" command line), my machine freezes for a few > seconds before rebooting instantly. My first thought was that the > X.org port wasn't compiled for 6.0-RC1, so I recompiled it. Nope, it > still crashes. So I ran X with verbose level 9, and got this (if this > isn't the right place to paste large text blocks, SORRY! Just tell me > where should I read the mailing-lists etiquete): Just a thought but did you compile your kernel with: options COMPAT_FREEBSD5 ? > openglx@volahia:~$ X -verbose 9 -logverbose 9 tty08 :0 > > X Window System Version 6.8.2 > Release Date: 9 February 2005 > X Protocol Version 11, Revision 0, Release 6.8.2 > Build Operating System: FreeBSD 6.0 i386 [ELF] > Current Operating System: FreeBSD volahia.starbyte.net 6.0-RC1 FreeBSD > 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 > root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 > Build Date: 13 October 2005 > Before reporting problems, check http://wiki.X.Org > to make sure that you have the latest version. > Module Loader present > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 13 10:32:08 2005 > (==) Using config file: "/usr/X11R6/lib/X11/xorg.conf" > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Card0" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist. > Entry deleted from font path. > (**) FontPath set to > "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" > (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" > (**) ModulePath set to "/usr/X11R6/lib/modules" > (**) Option "DontZap" > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.2 > X.Org Video Driver: 0.7 > X.Org XInput driver : 0.4 > X.Org Server Extension : 0.2 > X.Org Font Renderer : 0.4 > (II) Loader running on freebsd > (II) LoadModule: "bitmap" > (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a > (II) Module bitmap: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > Module class: X.Org Font Renderer > ABI class: X.Org Font Renderer, version 0.4 > (II) Loading font Bitmap > (II) LoadModule: "pcidata" > (II) Loading /usr/X11R6/lib/modules/libpcidata.a > (II) Module pcidata: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > ABI class: X.Org Video Driver, version 0.7 > (--) Using syscons driver with X support (version 2.0) > (--) using VT number 9 > > (II) PCI: Probing config type using method 1 > (II) PCI: Config type is 1 > (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 > (II) PCI: PCI scan (all values are in hex) > (II) PCI: 00:00:0: chip 1039,0630 card 0000,0000 rev 21 class > 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 1039,5513 card 1039,5513 rev > d0 class 01,01,8a hdr 80 (II) PCI: 00:01:0: chip 1039,0008 card > 0000,0000 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:01:1: chip > 1039,0900 card 1039,0900 rev 83 class 02,00,00 hdr 00 (II) PCI: > 00:01:4: chip 1039,7018 card 1039,7018 rev 02 class 04,01,00 hdr 00 > (II) PCI: 00:02:0: chip 1039,0001 card 0000,0000 rev 00 class > 06,04,00 hdr 01 (II) PCI: 01:00:0: chip 1039,6300 card 1039,6300 rev > 21 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI > bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 > (VGA_EN is set) (II) Bus 0 I/O range: > [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] > (II) Bus 0 non-prefetchable memory range: > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] > (II) Bus 0 prefetchable memory range: > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] > (II) PCI-to-ISA bridge: > (II) Bus -1: bridge is at (0:1:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN > is set) (II) PCI-to-PCI bridge: > (II) Bus 1: bridge is at (0:2:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is > set) (II) Bus 1 I/O range: > [0] -1 0 0x0000c000 - 0x0000cfff (0x1000) IX[B] > (II) Bus 1 non-prefetchable memory range: > [0] -1 0 0xefe00000 - 0xefefffff (0x100000) MX[B] > (II) Bus 1 prefetchable memory range: > [0] -1 0 0xdfc00000 - 0xefcfffff (0x10100000) MX[B] > (--) PCI:*(1:0:0) Silicon Integrated Systems [SiS] SiS630 GUI > Accelerator+3D rev 33, Mem @ 0xe0000000/27, 0xefee0000/17, I/O @ > 0xcc80/7 > (II) Addressable bus resource ranges are > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] > [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] > (II) OS-reported resource ranges: > [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) > [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) PCI Memory resource overlap reduced 0xf4000000 from 0xf7ffffff to > 0xf3ffffff > (II) Active PCI resource ranges: > [0] -1 0 0xf3fff000 - 0xf3ffffff (0x1000) MX[B]E > [1] -1 0 0xf3ffe000 - 0xf3ffffff (0x2000) MX[B]E > [2] -1 0 0xf4000000 - 0xf3ffffff (0x0) MX[B]EO > [3] -1 0 0xefee0000 - 0xefefffff (0x20000) MX[B](B) > [4] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) > [5] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E > [6] -1 0 0x0000dc00 - 0x0000dcff (0x100)(II) Loading > /usr/X11R6/lib/modules/extensions/libdbe.a > (II) Module dbe: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 0.2 > (II) Loading extension DOUBLE-BUFFER > (II) LoadModule: "dri" > (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a > (II) Module dri: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > ABI class: X.Org Server Extension, version 0.2 > (II) Loading sub module "drm" > (II) LoadModule: "drm" > (II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a > (II) Module drm: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > ABI class: X.Org Server Extension, version 0.2 > (II) Loading extension XFree86-DRI > (II) LoadModule: "extmod" > (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a > (II) Module extmod: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 0.2 > (II) Loading extension SHAPE > (II) Loading extension MIT-SUNDRY-NONSTANDARD > (II) Loading extension BIG-REQUESTS > (II) Loading extension SYNC > (II) Loading extension MIT-SCREEN-SAVER > (II) Loading extension XC-MISC > (II) Loading extension XFree86-VidModeExtension > (II) Loading extension XFree86-Misc > (II) Loading extension XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension TOG-CUP > (II) Loading extension Extended-Visual-Information > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "glx" > (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a > (II) Module glx: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > ABI class: X.Org Server Extension, version 0.2 > (II) Loading sub module "GLcore" > (II) LoadModule: "GLcore" > (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a > (II) Module GLcore: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > ABI class: X.Org Server Extension, version 0.2 > (II) Loading extension GLX > (II) LoadModule: "record" > (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a > (II) Module record: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.13.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 0.2 > (II) Loading extension RECORD > (II) LoadModule: "xtrap" > (II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a > (II) Module xtrap: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 0.2 > (II) Loading extension DEC-XTRAP > (II) LoadModule: "freetype" > (II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so > (II) Module freetype: vendor="X.Org Foundation & the After X-TT > Project" compiled for 6.8.2, module version = 2.1.0 > Module class: X.Org Font Renderer > ABI class: X.Org Font Renderer, version 0.4 > (II) Loading font FreeType > (II) LoadModule: "type1" > (II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a > (II) Module type1: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.2 > Module class: X.Org Font Renderer > ABI class: X.Org Font Renderer, version 0.4 > (II) Loading font Type1 > (II) Loading font CID > (II) LoadModule: "sis" > (II) Loading /usr/X11R6/lib/modules/drivers/sis_drv.o > (II) Module sis: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 0.7.0 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 0.7 > (II) LoadModule: "mouse" > (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o > (II) Module mouse: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 0.4 > (II) LoadModule: "kbd" > (II) Loading /usr/X11R6/lib/modules/input/kbd_drv.o > (II) Module kbd: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 1.0.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 0.4 > (II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620, > SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, > SIS315H, SIS315PRO, SIS550, SIS650/M650/651/740, SIS330(Xabre), > SIS660/661FX/M661FX/M661MX/741/741GX/M741/760/M760, SIS340 > (II) Primary Device is: PCI 01:00:0 > (**) Chipset override: SIS630/730 > (**) Chipset SIS630/730 found > (II) resource ranges after xf86ClaimFixedResources() call: > [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) > [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [5] -1 0 0xf3fff000 - 0xf3ffffff (0x1000) MX[B]E > [6] -1 0 0xf3ffe000 - 0xf3ffefff (0x1000) MX[B]E > [7] -1 0 0xf4000000 - 0xf3ffffff (0x0) MX[B]EO > [8] -1 0 0xefee0000 - 0xefefffff (0x20000) MX[B](B) > [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) > [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [12] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E > [13] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B]E > [14] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E > [15] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E > [16] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E > [17] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E > [18] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E > [19] -1 0 0x0000cc80 - 0x0000ccff (0x80) IX[B](B) > (II) resource ranges after probing: > [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) > [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) > [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [5] -1 0 0xf3fff000 - 0xf3ffffff (0x1000) MX[B]E > [6] -1 0 0xf3ffe000 - 0xf3ffefff (0x1000) MX[B]E > [7] -1 0 0xf4000000 - 0xf3ffffff (0x0) MX[B]EO > [8] -1 0 0xefee0000 - 0xefefffff (0x20000) MX[B](B) > [9] -1 0 0xe0000000 - 0xe7ffffff (0x8000000) MX[B](B) > [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [15] -1 0 0x0000de00 - 0x0000deff (0x100) IX[B]E > [16] -1 0 0x0000dc00 - 0x0000dcff (0x100) IX[B]E > [17] -1 0 0x0000ffa0 - 0x0000ffbf (0x20) IX[B]E > [18] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E > [19] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E > [20] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E > [21] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E > [22] -1 0 0x0000cc80 - 0x0000ccff (0x80) IX[B](B) > [23] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [24] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) Setting vga for screen 0. > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/X11R6/lib/modules/libvgahw.a > (II) Module vgahw: vendor="X.Org Foundation" > compiled for 6.8.2, module version = 0.1.0 > ABI class: X.Org Video Driver, version 0.7 > (II) SIS(0): SiS driver (2004/08/20-1) > (II) SIS(0): Copyright (C) 2001-2004 Thomas Winischhofer > and others > (II) SIS(0): Compiled for X.org version 6.8.2.0 > (II) SIS(0): See http://www.winischhofer.net/linuxsisvga.shtml for > documentation and updates > (--) SIS(0): This adapter is primary display adapter > (==) SIS(0): Write-combining range (0xa0000,0x10000) was already clear > (II) SIS(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is > 0xc900 (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Loading /usr/X11R6/lib/modules/libramdac.a > (II) Module ramdac: vendor="X.Org Foundation" > compiled for 6.8.2 > > [and stops there. At this point the machine starts to reboot itself. > I've managed to get that information connecting from a remote host > using SSH.]. > > volahia is the machine name, as you may wonder. It's a Pentium III > 1GHz, 512MB RAM, with three IDE devices (two HDs and one CD-ROM). It > has everything "on-board", where: > * SiS900 ethernet card (working perfectly) > * Sis7018 sound card (have a few problems recording sound, but it > isn't the matter now) > * SiS630 video card (looks like there's some driver problem, are you > sure that "ramdac" should be loaded for on-board video cards?) > > The dmesg output for me: > openglx@volahia:~$ dmesg > Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 > root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (1002.28-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x68a Stepping = 10 > Features=0x387f9ff > real memory = 520028160 (495 MB) > avail memory = 499531776 (476 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > pci_link0: irq 0 on acpi0 > pci_link1: irq 10 on acpi0 > pci_link2: irq 11 on acpi0 > pci_link3: irq 0 on acpi0 > pci_link4: irq 0 on acpi0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: mem 0xf4000000-0xf7ffffff at device > 0.0 on pci0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 0.1 on > pci0 > ata0: on atapci0 > ata1: on atapci0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > sis0: port 0xdc00-0xdcff mem > 0xf3ffe000-0xf3ffefff irq 11 at device 1.1 on pci0 > miibus0: on sis0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > sis0: Ethernet address: 00:07:95:c4:65:80 > pcm0: port 0xde00-0xdeff mem 0xf3fff000-0xf3ffffff irq 10 > at device 1.4 on pci0 > pcm0: > pcm0: [GIANT-LOCKED] > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > drm0: port 0xcc80-0xccff mem > 0xe0000000-0xe7ffffff,0xefee0000-0xefefffff at device 0.0 on pci1 > info: [drm] AGP at 0xf4000000 64MB > info: [drm] Initialized sis 1.1.0 20030826 on minor 0 > acpi_button1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq > 6 drq 2 on acpi0 > fdc0: [FAST] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 > on acpi0 sio0: type 16550A > 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/16 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xd3fff on > isa0 sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > 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 1002277240 Hz quality 800 > Timecounters tick every 1.000 msec > ad0: DMA limited to UDMA33, controller found non-ATA66 cable > ad0: 39083MB at ata0-master UDMA33 > ad1: DMA limited to UDMA33, controller found non-ATA66 cable > ad1: 114498MB at ata0-slave UDMA33 > acd0: CDRW at ata1-slave UDMA33 > Trying to mount root from ufs:/dev/ad0s2a > WARNING: / was not properly dismounted > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > WARNING: /media/ad1s1d was not properly dismounted > WARNING: /media/ad1s4d was not properly dismounted > sis0: link state changed to UP > no matching session > > [Ignore the "no matching session" error, it is related to PPPoE > sessioning]. > > I had to disable GDM auto-start, otherwise the machine would be > rebooting itself everytime. Any idea on how we should work on that > X.org problem? Note that the machine was working perfectly on > FreeBSD-5.4, FreeBSD-5.2.1, Linux (Debian 3.0 and 3.1, Slackware 9, > 9.1, 10), Windows (XP, 98), and FreeeDOS. > > If more information if needed, I can provide. > > Thanks in advance. > > -- > openglx@StarByte.net > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:05:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6ED16A422 for ; Thu, 13 Oct 2005 15:05:44 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from smtp202.mail.sc5.yahoo.com (smtp202.mail.sc5.yahoo.com [216.136.129.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 0B8D543D46 for ; Thu, 13 Oct 2005 15:05:42 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: (qmail 45919 invoked from network); 13 Oct 2005 14:30:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-Id:Mime-Version:X-Mailer:Content-Transfer-Encoding; b=rYBNIj8XhZyor2zJv4lnCukpziAIFRSZPYPOjilqR3ExSrzHsj7xXIePxQ7Fx3GfCqbUgqKHkmgtiouyVKzwcMzPJ53DW1z5K4JejTdgARyfjVAyQH/TzhGCfJz1b2Qc4N+/hQ2wgL2Cf1mmXfZkJ2PP+8SsdZEjNgQ6YNsCtT4= ; Received: from unknown (HELO 201-1-112-194.dsl.telesp.net.br) (ricardo?bsd@201.1.112.194 with plain) by smtp202.mail.sc5.yahoo.com with SMTP; 13 Oct 2005 14:30:36 -0000 From: "Ricardo A. Reis" To: Felipe openglx In-Reply-To: <621b657f0510130648m57487570s508b16e729a351c4@mail.gmail.com> References: <621b657f0510130648m57487570s508b16e729a351c4@mail.gmail.com> Content-Type: text/plain Date: Thu, 13 Oct 2005 08:30:07 -0300 Message-Id: <1129203007.13257.17.camel@myfreebsd.homeunix.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: 6.0-RC1: reboot when trying to load X.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 15:05:44 -0000 Hi Felipe, Do you test using vesa driver? I see severals problems with reboot in bad SIS card's, i don't know if this is caused by drive or incompatible device chip. > Hi all, > > this is my first post, and I'm quite new to FreeBSD. Don't push me too hard :) > > Last night I've upgraded a (well) running FreeBSD-5.4 install to > 6.0-RC1 and had it running without problems. Well, mind you, ALMOST > without problems. > > When trying to start X.org server (using GDM, using "startx" command > line, or even using "X" command line), my machine freezes for a few > seconds before rebooting instantly. My first thought was that the > X.org port wasn't compiled for 6.0-RC1, so I recompiled it. Nope, it > still crashes. So I ran X with verbose level 9, and got this (if this > isn't the right place to paste large text blocks, SORRY! Just tell me > where should I read the mailing-lists etiquete): > > openglx@volahia:~$ X -verbose 9 -logverbose 9 tty08 :0 > > (II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620, > SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, SIS315H, > SIS315PRO, SIS550, SIS650/M650/651/740, SIS330(Xabre), > SIS660/661FX/M661FX/M661MX/741/741GX/M741/760/M760, SIS340 > (II) Primary Device is: PCI 01:00:0 > (**) Chipset override: SIS630/730 > (**) Chipset SIS630/730 found > I had to disable GDM auto-start, otherwise the machine would be > rebooting itself everytime. Any idea on how we should work on that > X.org problem? Note that the machine was working perfectly on > FreeBSD-5.4, FreeBSD-5.2.1, Linux (Debian 3.0 and 3.1, Slackware 9, > 9.1, 10), Windows (XP, 98), and FreeeDOS. > > If more information if needed, I can provide. > > Thanks in advance. > > -- > openglx@StarByte.net > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" _______________________________________________________ Promoção Yahoo! Acesso Grátis: a cada hora navegada você acumula cupons e concorre a mais de 500 prêmios! Participe! http://yahoo.fbiz.com.br/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:10:52 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7922E16A41F for ; Thu, 13 Oct 2005 15:10:52 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04CB043D45 for ; Thu, 13 Oct 2005 15:10:49 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j9DFIKMI091517; Thu, 13 Oct 2005 11:18:20 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 13 Oct 2005 11:10:28 -0400 User-Agent: KMail/1.6.2 References: <434BCDF6.3090303@samsco.org> <20051012170258.669d4f45.stanley.jobson@gmx.ch> In-Reply-To: <20051012170258.669d4f45.stanley.jobson@gmx.ch> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200510131110.35339.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1131/Wed Oct 12 16:35:32 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: stanley jobson Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 15:10:52 -0000 On Wednesday 12 October 2005 11:02 am, stanley jobson wrote: > hi, > > > - The QEMU and VMWare packages are known to expose problems in > > the IDE CDROM driver during OS install. > > will this be corrected for 6-stable? Yes. http://docs.freebsd.org/cgi/mid.cgi?200510092124.j99LOBcs038237 http://docs.freebsd.org/cgi/mid.cgi?200510122017.j9CKHZTk067708 Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:15:05 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC7D416A41F for ; Thu, 13 Oct 2005 15:15:05 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88DEE43D45 for ; Thu, 13 Oct 2005 15:15:05 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5CD3D1A3C27; Thu, 13 Oct 2005 08:15:05 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 783AF511F0; Thu, 13 Oct 2005 11:15:04 -0400 (EDT) Date: Thu, 13 Oct 2005 11:15:04 -0400 From: Kris Kennaway To: "Ricardo A. Reis" Message-ID: <20051013151504.GA4576@xor.obsecurity.org> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <1129201350.13257.9.camel@myfreebsd.homeunix.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 15:15:05 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2005 at 08:02:30AM -0300, Ricardo A. Reis wrote: > Hi All, >=20 > I'm very happy with this rc, exist a possibility =20 > to import patch of pr 57641 before final RELEASE? > I use this patch in RELENG_5 for jail storage with MFS. >=20 >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/57641 I'd say it's unlikely: the time to discuss this was 2 months ago at the start of the release process, not a few days before the release. The PR is owned by dd@, so you should talk to him about when he plans to work on it (or release it so that someone else can). Kris --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDTnn3Wry0BWjoQKURAkcbAJ0aemzZ+N4GwnCCO1EwKAjL/eWOnQCghz/2 3jrgUsAkkhFM/Pp+q6MQstk= =uV9f -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:16:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E83D816A41F for ; Thu, 13 Oct 2005 15:16:12 +0000 (GMT) (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 0103A43D45 for ; Thu, 13 Oct 2005 15:16:11 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9DFGAtk027234; Thu, 13 Oct 2005 09:16:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434E7A38.7030305@samsco.org> Date: Thu, 13 Oct 2005 09:16:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stanley jobson References: <434BCDF6.3090303@samsco.org> <20051012170258.669d4f45.stanley.jobson@gmx.ch> In-Reply-To: <20051012170258.669d4f45.stanley.jobson@gmx.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 15:16:13 -0000 stanley jobson wrote: > hi, > > >>- The QEMU and VMWare packages are known to expose problems in the >> IDE CDROM driver during OS install. > > > will this be corrected for 6-stable? > You forgot to quote this part of the mail: > The following issues are known and will be fixed before the release: Scott From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:19:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 140A916A420 for ; Thu, 13 Oct 2005 15:19:22 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C4B043D45 for ; Thu, 13 Oct 2005 15:19:20 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j9DFJFje082977; Thu, 13 Oct 2005 10:19:15 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434E7ADE.5030709@centtech.com> Date: Thu, 13 Oct 2005 10:18:54 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <434E60D6.3030402@centtech.com> <20051013140536.GA10247@crodrigues.org> In-Reply-To: <20051013140536.GA10247@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1131/Wed Oct 12 15:35:32 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 15:19:22 -0000 Craig Rodrigues wrote: > On Thu, Oct 13, 2005 at 08:27:50AM -0500, Eric Anderson wrote: > >>Thanks - great suggestion! I'll do that. Any ideas how to remove the >>FBSDID line jitter from the patches? > > > When you check out the files from CVS, do not expand the CVS keywords by > doing: cvs co -kk So, this brings up a quick question: what methods do most developers use when doing things like this? I looked in the developer's handbook, but didn't see any quick guide on a good method. Do you keep the local cvs repo up to date, then check it out, make changes, etc? How do you do the diffs, and track all the changes, while testing too? I'd like to kind of copy someone else's known-functional method instead of coming up with my own. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:30:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BF5C16A41F for ; Thu, 13 Oct 2005 15:30:15 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0C6243D48 for ; Thu, 13 Oct 2005 15:30:14 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so255546wxc for ; Thu, 13 Oct 2005 08:30:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DwXoGLo9MtnsW4b4GhTJgATFDWYzoONGbZ/Q/+IWFCWON5MIOAbJcNkygISoI+9Jx5novZeiazolcE02Ufb0MJoGmQG7SRmVbpC8TByKsKIC2iI0Fi8JtMGaWkrNsPVKyLLzzrtrj0jH2bwAgPAs/okr5wvgpj8qCkup7JHXFGI= Received: by 10.70.75.15 with SMTP id x15mr733239wxa; Thu, 13 Oct 2005 08:30:13 -0700 (PDT) Received: by 10.70.53.4 with HTTP; Thu, 13 Oct 2005 08:30:13 -0700 (PDT) Message-ID: <790a9fff0510130830l68298bd1p3f3d20c76110df95@mail.gmail.com> Date: Thu, 13 Oct 2005 10:30:13 -0500 From: Scot Hetzel To: stanley jobson In-Reply-To: <20051012170258.669d4f45.stanley.jobson@gmx.ch> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5649_14173406.1129217413803" References: <434BCDF6.3090303@samsco.org> <20051012170258.669d4f45.stanley.jobson@gmx.ch> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 15:30:15 -0000 ------=_Part_5649_14173406.1129217413803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 10/12/05, stanley jobson wrote: > hi, > > > - The QEMU and VMWare packages are known to expose problems in the > > IDE CDROM driver during OS install. > > will this be corrected for 6-stable? > > what about vmware 4 and vmware 5 having in the ports? anybody working on > that? what are the probs? > I'm currently using vmware 5.5 on WinXP to host a FreeBSD guest. But in order to get FreeBSD as the host OS, we'll need to back port some linux ioctl to RELENG_4, RELENG_5, RELENG_6 from -CURRENT. See my MFC request from May 20th: http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050421.html Also, some one will need to re-write orlando's VMware 4 patch to vmmon to work with Vmware 5.* and the VMware 3 vmnet patch to work with VMware 4, and 5.*. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_5649_14173406.1129217413803-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:54:28 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BDB316A41F for ; Thu, 13 Oct 2005 15:54:28 +0000 (GMT) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3AF243D45 for ; Thu, 13 Oct 2005 15:54:26 +0000 (GMT) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id 0E3B6ECD439; Thu, 13 Oct 2005 17:55:12 +0200 (CEST) Date: Thu, 13 Oct 2005 17:55:11 +0200 From: Andy Hilker To: current@freebsd.org Message-ID: <20051013155511.GA1748@mail.crypta.net> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1129201350.13257.9.camel@myfreebsd.homeunix.org> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Cc: Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 15:54:28 -0000 Hi, > > Announcement > > ------------ > > > > The release engineering team is proud to announce the availability of > > FreeBSD 6.0. [...] > > We encourage everyone to help with testing so any final bugs can be > > identified and worked out. Availability of ISO images is given below. Is it possible to include this minor patch for rc-ng scripts? It ist present since 5.3 or earlier... http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/82430 bye, Andy -- Andy Hilker -- mailto:ah@cryptobank.de http://www.cryptobank.de -- PGP Key: https://ca.crypta.net From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:56:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2AEF16A41F; Thu, 13 Oct 2005 15:56:20 +0000 (GMT) (envelope-from stefan@snowfall.se) Received: from mail.snowfall.se (pluring.snowfallnet.com [82.99.34.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC0A543D5F; Thu, 13 Oct 2005 15:56:14 +0000 (GMT) (envelope-from stefan@snowfall.se) Received: from [192.168.0.105] (unknown [87.96.144.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.snowfall.se (Postfix) with ESMTP id 837165A; Thu, 13 Oct 2005 17:56:11 +0200 (CEST) Message-ID: <434E839B.2020209@snowfall.se> Date: Thu, 13 Oct 2005 17:56:11 +0200 From: Stefan Cars User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg 'groggy' Lehey References: <434CBAD5.10306@snowfall.se> <20051013010014.GG49168@wantadilla.lemis.com> In-Reply-To: <20051013010014.GG49168@wantadilla.lemis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: questions@freebsd.org, current@freebsd.org Subject: Re: Moving down from amd64 to i386 ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 15:56:21 -0000 Hi! After doing some testing this is what I found out: 1) Exchanging memory on the machine did not work. Same error. 2) Trying it on another 64 bit machine with same FreeBSD (RC1) creates EXACT same problem 3) Installing the i386 version of RC1 instead of amd64 on the same machines and it works terrific. No crash. The bt is always the same and it always crash the same, look here: #784 0x0000000000000000 in ?? () #785 0x247c8d48002454ff in ?? () #786 0x01a1c0c748006a10 in ?? () #787 0x66fdebf4050f0000 in ?? () #788 0x9066669066669066 in ?? () #789 0x00007fffffffe778 in ?? () #790 0x0000000000000006 in ?? () #791 0x00007fffffffe7b0 in ?? () #792 0x0000000000000017 in ?? () Cannot access memory at address 0x800000000000 Greg 'groggy' Lehey wrote: > On Wednesday, 12 October 2005 at 9:27:17 +0200, Stefan Cars wrote: > >>Hi! >> >>We are having troubles with MySQL 4.1 on a amd64 (it's crashing >>randomly with Seg fault, signal 11. gdb bt says: Cannot access >>memory at address 0x800000000000). We have got information saying >>this is a 64bit related issue and should be fixed by using the i386 >>version instead of amd64 (this is an Intel Xeon). > > > Where did you get that information from? > > >>What is the way to go when moving from amd64 to i386 ? > > > If you mean "how do I install an i386 kernel on this machine", I can't > think of any way except to start from scratch. It would be a good > idea to install a separate disk, so you can access the configuration > files and the database on the old disk. But before doing this, I'd be > very interested in knowing what the problem is. Is the backtrace > always the same? Where does it crash? > > Greg > -- > When replying to this message, please copy the original recipients. > If you don't, I may ignore the reply or reply to the original recipients. > For more information, see http://www.lemis.com/questions.html > See complete headers for address and phone numbers. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:11:12 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F4BC16A41F; Thu, 13 Oct 2005 16:11:12 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id D889243D45; Thu, 13 Oct 2005 16:11:09 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j9DGIdTt093873; Thu, 13 Oct 2005 12:18:39 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org, thierry@herbelot.com Date: Thu, 13 Oct 2005 12:10:50 -0400 User-Agent: KMail/1.6.2 References: <200510131331.27906.thierry@herbelot.com> <200510131621.07299.thierry@herbelot.com> In-Reply-To: <200510131621.07299.thierry@herbelot.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200510131210.55135.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1131/Wed Oct 12 16:35:32 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-emulation@FreeBSD.org, Warner Losh , Juergen Lock , Joshua Coombs Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 16:11:12 -0000 On Thursday 13 October 2005 10:21 am, Thierry Herbelot wrote: > Le Thursday 13 October 2005 15:38, Joshua Coombs a ï¿œcrit : > > Welp, while I have no real help, I can point out this was > > reported by another user on the stable list, QEMU + RC1 == no ed > > well, I should have looked there before posting here ;-) (sorry for > the excellent Michel talon at lpthe.jussieu.fr : I should have > seeen your post) > > > I'm kinda dreading upgrading my 386... I'll pull down the generic > > kernel and do a test boot to see if it's a QEMU thing or a > > reguression in RC1 > > for me, it's definitely a qemu thing : I have two other machines > upgraded to 6.0 post-RC1, and both are working *fine* ; moreover > one is a notebook with a pcmcia ed(4), and this NIC works perfectly > (the issue is therefore seen only on qemu) QEMU emulates RTL8029: ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 and Warner Losh MFC'd new ed(4) right before 6.0-RC1: http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 The new driver does more aggressive probing and it seems QEMU cannot handle it. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:18:01 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D7F16A41F; Thu, 13 Oct 2005 16:18:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E6F243D46; Thu, 13 Oct 2005 16:18:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DGHc6F074461; Thu, 13 Oct 2005 10:17:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 10:18:47 -0600 (MDT) Message-Id: <20051013.101847.45180176.imp@bsdimp.com> To: jkim@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200510131210.55135.jkim@FreeBSD.org> References: <200510131621.07299.thierry@herbelot.com> <200510131210.55135.jkim@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 10:17:39 -0600 (MDT) Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, nox@jelal.kn-bremen.de, jcoombs@gwi.net, thierry@herbelot.com Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 16:18:01 -0000 In message: <200510131210.55135.jkim@FreeBSD.org> Jung-uk Kim writes: : On Thursday 13 October 2005 10:21 am, Thierry Herbelot wrote: : > Le Thursday 13 October 2005 15:38, Joshua Coombs a $,3u=(Bcrit : : > > Welp, while I have no real help, I can point out this was : > > reported by another user on the stable list, QEMU + RC1 == no ed : > : > well, I should have looked there before posting here ;-) (sorry for : > the excellent Michel talon at lpthe.jussieu.fr : I should have : > seeen your post) : > : > > I'm kinda dreading upgrading my 386... I'll pull down the generic : > > kernel and do a test boot to see if it's a QEMU thing or a : > > reguression in RC1 : > : > for me, it's definitely a qemu thing : I have two other machines : > upgraded to 6.0 post-RC1, and both are working *fine* ; moreover : > one is a notebook with a pcmcia ed(4), and this NIC works perfectly : > (the issue is therefore seen only on qemu) : : QEMU emulates RTL8029: : : ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 : ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 : : and Warner Losh MFC'd new ed(4) right before 6.0-RC1: : : http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 : : The new driver does more aggressive probing and it seems QEMU cannot : handle it. Yup. I'm trying to get qemu going here. It core dumps for me in -nographics mode, which frustrates me since I can't run it on my fastest machine while at work (the machine is at home and the DSL line is too slow for qemu's use of X but not too slow for firefox!). I've installed it on my laptop and we'll see how well it works. I'm guessing it may be a bug in all RTL80x9 hardware that I introduced into the patches I committed (or was there from the start). I lost my bid last night on real 8029 and 8019 hardware on ebay. If someone wanted to send it to me, that would be great! I have enough other NE-2000 clone hardware (including about 30 16-bit PC Cards that all work flawlessly or nearly flawlessly[*]). I don't suppose there's an easy way to run qemu where it just boots a FreeBSD kernel... Warner [*] My FA-410 takes forever to autonegotiate, but once it does, it works great. All others work, including one that don't work completely on any other open source OS... From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:21:34 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EEAC16A41F; Thu, 13 Oct 2005 16:21:34 +0000 (GMT) (envelope-from jcoombs@gwi.net) Received: from aphrodite.gwi.net (aphrodite.gwi.net [207.5.128.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7F8F43D45; Thu, 13 Oct 2005 16:21:33 +0000 (GMT) (envelope-from jcoombs@gwi.net) Received: from failure (murdoc.gwi.net [207.5.142.8]) by aphrodite.gwi.net (8.13.1/8.13.1) with SMTP id j9DGLVV3086166; Thu, 13 Oct 2005 12:21:31 -0400 (EDT) (envelope-from jcoombs@gwi.net) Message-ID: <055201c5d012$2c8ca250$1700a8c0@failure> From: "Joshua Coombs" To: "Jung-uk Kim" , , References: <200510131331.27906.thierry@herbelot.com> <200510131621.07299.thierry@herbelot.com> <200510131210.55135.jkim@FreeBSD.org> Date: Thu, 13 Oct 2005 12:21:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Cc: freebsd-emulation@FreeBSD.org, Warner Losh , Juergen Lock Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 16:21:34 -0000 > QEMU emulates RTL8029: > > ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 > ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 > > and Warner Losh MFC'd new ed(4) right before 6.0-RC1: > > http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 > > The new driver does more aggressive probing and it seems QEMU cannot > handle it. > > Jung-uk Kim Interesting. I wonder if this MFC means my 8019 will support full duplex under FreeBSD? The NetBSD 'ne' driver has access to software based media selection, it'd be nice to have access to an ISA nic that handled full-duplex properly. Joshua Coombs From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:28:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2643316A41F for ; Thu, 13 Oct 2005 16:28:28 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9020943D49 for ; Thu, 13 Oct 2005 16:28:27 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id j9DGSQ8V081061; Thu, 13 Oct 2005 09:28:27 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200510131628.j9DGSQ8V081061@gate.bitblocks.com> To: thierry@herbelot.com In-reply-to: Your message of "Thu, 13 Oct 2005 16:21:05 +0200." <200510131621.07299.thierry@herbelot.com> Date: Thu, 13 Oct 2005 09:28:26 -0700 From: Bakul Shah Cc: freebsd-current@freebsd.org, Joshua Coombs Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 16:28:28 -0000 > Le Thursday 13 October 2005 15:38, Joshua Coombs a écrit : > > Welp, while I have no real help, I can point out this was reported by > > another user on the stable list, QEMU + RC1 == no ed > > well, I should have looked there before posting here ;-) (sorry for the > excellent Michel talon at lpthe.jussieu.fr : I should have seeen your post) > > > I'm kinda dreading upgrading my 386... I'll pull down the generic > > kernel and do a test boot to see if it's a QEMU thing or a reguression > > in RC1 > > for me, it's definitely a qemu thing : I have two other machines upgraded to > 6.0 post-RC1, and both are working *fine* ; moreover one is a notebook with a > > pcmcia ed(4), and this NIC works perfectly (the issue is therefore seen only > on qemu) The same problem exists on -current as well. This is due to the /dev/ed related commit done on RELENG_6 branch on 10/8 (merge from an earlier 10/5 commit done on the HEAD branch. This commit supports more ed devices but breaks qemu's ed emulation). qemu does not emulate a couple of ID registers that ed_probe_RTL_80x9() seems to insist on reading. I don't know who is right -- at this point qemu needs to be one of the standard test targets. As shown below, I worked around the problem by always calling nced_probe_Novell() as before (in /sys/dev/ed directory). NOTE: THIS IS A QUICK WORKAROUND, NOT A REAL FIX. I tried a better fix but it didn't work in the few minutes I spent on it (the idea was this: if ed_probe_RTL80x9 fails() with ENXIO, release all resources that may have been allocated by it and then call ed_probe_Novell()). Index: if_ed_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ed/if_ed_pci.c,v retrieving revision 1.47 diff -w -u -b -r1.47 if_ed_pci.c --- if_ed_pci.c 5 Oct 2005 05:21:07 -0000 1.47 +++ if_ed_pci.c 12 Oct 2005 23:30:27 -0000 @@ -84,9 +84,9 @@ int flags = 0; int error; - if (pci_get_devid(dev) == ED_RTL8029_PCI_ID) - error = ed_probe_RTL80x9(dev, PCIR_BAR(0), flags); - else + //if (pci_get_devid(dev) == ED_RTL8029_PCI_ID) + //error = ed_probe_RTL80x9(dev, PCIR_BAR(0), flags); + //else error = ed_probe_Novell(dev, PCIR_BAR(0), flags); if (error) { ed_release_resources(dev); From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:28:46 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18BE716A44A; Thu, 13 Oct 2005 16:28:46 +0000 (GMT) (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 8538143D49; Thu, 13 Oct 2005 16:28:45 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9DGSi9D015477; Thu, 13 Oct 2005 12:28:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9DGSi0r089953; Thu, 13 Oct 2005 12:28:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 280F87302F; Thu, 13 Oct 2005 12:28:44 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051013162844.280F87302F@freebsd-current.sentex.ca> Date: Thu, 13 Oct 2005 12:28:44 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on alpha/alpha 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, 13 Oct 2005 16:28:46 -0000 TB --- 2005-10-13 15:28:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-13 15:28:02 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-10-13 15:28:02 - cleaning the object tree TB --- 2005-10-13 15:28:33 - checking out the source tree TB --- 2005-10-13 15:28:33 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-10-13 15:28:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-13 15:35:22 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-13 15:35:22 - cd /src TB --- 2005-10-13 15:35:22 - /usr/bin/make -B buildworld >>> 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 [...] cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -o savecore savecore.o -lz gzip -cn /src/sbin/savecore/savecore.8 > savecore.8.gz ===> sbin/setkey (all) cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/setkey/setkey.c cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c parse.c /src/sbin/setkey/parse.y: In function `setkeymsg_add': /src/sbin/setkey/parse.y:1023: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/sbin/setkey/parse.y:1039: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/sbin/setkey. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-13 16:28:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-13 16:28:43 - ERROR: failed to build world TB --- 2005-10-13 16:28:43 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:38:55 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 260C916A41F; Thu, 13 Oct 2005 16:38:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E09D43D4C; Thu, 13 Oct 2005 16:38:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DGc8gc074638; Thu, 13 Oct 2005 10:38:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 10:39:17 -0600 (MDT) Message-Id: <20051013.103917.03114813.imp@bsdimp.com> To: jcoombs@gwi.net From: "M. Warner Losh" In-Reply-To: <055201c5d012$2c8ca250$1700a8c0@failure> References: <200510131621.07299.thierry@herbelot.com> <200510131210.55135.jkim@FreeBSD.org> <055201c5d012$2c8ca250$1700a8c0@failure> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 10:38:09 -0600 (MDT) Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, nox@jelal.kn-bremen.de, jkim@FreeBSD.org, thierry@herbelot.com Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 16:38:55 -0000 In message: <055201c5d012$2c8ca250$1700a8c0@failure> "Joshua Coombs" writes: : Interesting. I wonder if this MFC means my 8019 will support full : duplex under FreeBSD? The NetBSD 'ne' driver has access to software : based media selection, it'd be nice to have access to an ISA nic that : handled full-duplex properly. That's the idea. Warner From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:59:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC2F216A41F for ; Thu, 13 Oct 2005 16:59:39 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 400A343D45 for ; Thu, 13 Oct 2005 16:59:39 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 254183FD45 for ; Thu, 13 Oct 2005 18:59:38 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9DGxBT8000561; Thu, 13 Oct 2005 18:59:15 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 18:59:01 +0200 User-Agent: KMail/1.8.2 References: <200510131621.07299.thierry@herbelot.com> <055201c5d012$2c8ca250$1700a8c0@failure> <20051013.103917.03114813.imp@bsdimp.com> In-Reply-To: <20051013.103917.03114813.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510131859.03307.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 13 Oct 2005 16:59:39 -0000 Le Thursday 13 October 2005 18:39, M. Warner Losh a écrit : > In message: <055201c5d012$2c8ca250$1700a8c0@failure> > > "Joshua Coombs" writes: > : Interesting. I wonder if this MFC means my 8019 will support full > : duplex under FreeBSD? The NetBSD 'ne' driver has access to software > : based media selection, it'd be nice to have access to an ISA nic that > : handled full-duplex properly. > > That's the idea. > > Warner Hello, Just FYI, I've just checked that I have the full complement of boards (ISA ne2 at isa0 port 0x280/32 irq 9 under Open, PCI under ??? and PCMCIA running flawlessly under both FreeBSD current and post 6.0-RC1) I planned to convert the old OpenBSD machine (with the ISA board) to at least dual-boot with FreeBSD-6.0, but as I use qemu to prepare the partition image, I'm a bit stuck for now. Is there an iso image for a recent -current ? I had a look at the former japanese snapshot site, but it seems to only follow 5.4-Stable. TfH From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 17:30:35 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB3E216A420; Thu, 13 Oct 2005 17:30:35 +0000 (GMT) (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 46B8F43D45; Thu, 13 Oct 2005 17:30:35 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9DHUXPT068543; Thu, 13 Oct 2005 13:30:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9DHUYgX032593; Thu, 13 Oct 2005 13:30:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2CEAD7302F; Thu, 13 Oct 2005 13:30:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051013173034.2CEAD7302F@freebsd-current.sentex.ca> Date: Thu, 13 Oct 2005 13:30:34 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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, 13 Oct 2005 17:30:36 -0000 TB --- 2005-10-13 16:28:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-13 16:28:44 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-10-13 16:28:44 - cleaning the object tree TB --- 2005-10-13 16:29:23 - checking out the source tree TB --- 2005-10-13 16:29:23 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-10-13 16:29:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-13 16:36:12 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-13 16:36:12 - cd /src TB --- 2005-10-13 16:36:12 - /usr/bin/make -B buildworld >>> 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 [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -o savecore savecore.o -lz gzip -cn /src/sbin/savecore/savecore.8 > savecore.8.gz ===> sbin/setkey (all) cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/setkey/setkey.c cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c parse.c /src/sbin/setkey/parse.y: In function `setkeymsg_add': /src/sbin/setkey/parse.y:1023: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/sbin/setkey/parse.y:1039: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/sbin/setkey. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-13 17:30:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-13 17:30:33 - ERROR: failed to build world TB --- 2005-10-13 17:30:33 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 17:52:25 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E7E716A41F for ; Thu, 13 Oct 2005 17:52:25 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB43943D45 for ; Thu, 13 Oct 2005 17:52:24 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: by xproxy.gmail.com with SMTP id t5so350259wxc for ; Thu, 13 Oct 2005 10:52:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=GyzMyXrVDgRk+IF9mIpby44+2jT088KdAoS/T0aJ2tXFRi/W3B9UGNPGW9k3hrKSZdUCq2mw8PvYMdut2jr9uN4TAoSfQG3vvj2eeIrsav07xbTTHfYKAIStpbzcelOKdbEdLd13qIJtxLw2LBd1vYecbihJipiDWMwyc+gOI6c= Received: by 10.70.65.17 with SMTP id n17mr619977wxa; Thu, 13 Oct 2005 10:52:22 -0700 (PDT) Received: from ?200.102.74.5? ( [200.102.74.5]) by mx.gmail.com with ESMTP id i19sm916378wxd.2005.10.13.10.52.18; Thu, 13 Oct 2005 10:52:22 -0700 (PDT) Message-ID: <434E9EF8.4040603@starbyte.net> Date: Thu, 13 Oct 2005 14:52:56 -0300 From: Felipe openglx User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051006) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ricardo A. Reis" References: <621b657f0510130648m57487570s508b16e729a351c4@mail.gmail.com> <1129203007.13257.17.camel@myfreebsd.homeunix.org> In-Reply-To: <1129203007.13257.17.camel@myfreebsd.homeunix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Felipe openglx Cc: lists@yazzy.org, current@freebsd.org Subject: Re: 6.0-RC1: reboot when trying to load X.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 17:52:25 -0000 Hello, thank you, Ricardo! Using the vesa driver it worked OK. I'm just wondering now how slow this X.org will be while not using the specific driver to SiS boards. Marcin, I had FreeBSD-5.x compat running already, and I was running the GENERIC kernel (as it came for me). Changing the driver has worked, but maybe you were right when said to run the 5.x-compat. Anyhow, I did already compile the X.org to 6-0RC1 before trying the vesa option. Thanks again! Ricardo A. Reis wrote: > Hi Felipe, > > Do you test using vesa driver? I see severals problems with reboot in > bad SIS card's, i don't know if this is caused by drive or incompatible > device chip. > > > > > >>Hi all, >> >>this is my first post, and I'm quite new to FreeBSD. Don't push me too hard :) >> >>Last night I've upgraded a (well) running FreeBSD-5.4 install to >>6.0-RC1 and had it running without problems. Well, mind you, ALMOST >>without problems. >> >>When trying to start X.org server (using GDM, using "startx" command >>line, or even using "X" command line), my machine freezes for a few >>seconds before rebooting instantly. My first thought was that the >>X.org port wasn't compiled for 6.0-RC1, so I recompiled it. Nope, it >>still crashes. So I ran X with verbose level 9, and got this (if this >>isn't the right place to paste large text blocks, SORRY! Just tell me >>where should I read the mailing-lists etiquete): >> >>openglx@volahia:~$ X -verbose 9 -logverbose 9 tty08 :0 >> > > >>(II) SIS: driver for SiS chipsets: SIS5597/5598, SIS530/620, >> SIS6326/AGP/DVD, SIS300/305, SIS630/730, SIS540, SIS315, SIS315H, >> SIS315PRO, SIS550, SIS650/M650/651/740, SIS330(Xabre), >> SIS660/661FX/M661FX/M661MX/741/741GX/M741/760/M760, SIS340 >>(II) Primary Device is: PCI 01:00:0 >>(**) Chipset override: SIS630/730 >>(**) Chipset SIS630/730 found > > > >>I had to disable GDM auto-start, otherwise the machine would be >>rebooting itself everytime. Any idea on how we should work on that >>X.org problem? Note that the machine was working perfectly on >>FreeBSD-5.4, FreeBSD-5.2.1, Linux (Debian 3.0 and 3.1, Slackware 9, >>9.1, 10), Windows (XP, 98), and FreeeDOS. >> >>If more information if needed, I can provide. >> >>Thanks in advance. >> From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 18:10:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CE9916A41F for ; Thu, 13 Oct 2005 18:10:33 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0D7D43D45 for ; Thu, 13 Oct 2005 18:10:32 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9DIARGf032515; Thu, 13 Oct 2005 11:10:27 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9DIAQGA032514; Thu, 13 Oct 2005 11:10:26 -0700 Date: Thu, 13 Oct 2005 11:10:26 -0700 From: Brooks Davis To: Max Laier Message-ID: <20051013181026.GB27418@odin.ac.hmc.edu> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline In-Reply-To: <200510131412.23525.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Eric Anderson Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 18:10:33 -0000 --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2005 at 02:12:11PM +0200, Max Laier wrote: > On Thursday 13 October 2005 13:36, Eric Anderson wrote: > > I have not done any performance testing yet to see if it impacts > > filesystem performance by any measurable amount, so if someone does do > > this testing before I do, please post your results! >=20 > I don't think you can measure one single interger (or 64bit) increase in = face=20 > of a operation that has to access backing store. Even if there is a=20 > performance hit, you don't have to build your kernel with the option enab= led. The one thing I'd be worried about here is that 64bit updates are expensive on 32bit machines if you want them to be atomic. Relative to backing store they probably still don't matter, but the might be noticable. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTqMSXY6L6fI4GtQRAgsnAJ9vPYryM9+nGJya2SLLNLlWLydd0ACgzVYj fn2juLyBAO4e2Slm21hnp+o= =87ky -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 18:14:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9102116A43A for ; Thu, 13 Oct 2005 18:14:10 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37FF143D48 for ; Thu, 13 Oct 2005 18:14:10 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9DIE5Ol000729; Thu, 13 Oct 2005 11:14:05 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9DIE4iw000728; Thu, 13 Oct 2005 11:14:04 -0700 Date: Thu, 13 Oct 2005 11:14:04 -0700 From: Brooks Davis To: Eric Anderson Message-ID: <20051013181404.GC27418@odin.ac.hmc.edu> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <434E60D6.3030402@centtech.com> <20051013140536.GA10247@crodrigues.org> <434E7ADE.5030709@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <434E7ADE.5030709@centtech.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 18:14:11 -0000 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2005 at 10:18:54AM -0500, Eric Anderson wrote: > Craig Rodrigues wrote: > >On Thu, Oct 13, 2005 at 08:27:50AM -0500, Eric Anderson wrote: > > > >>Thanks - great suggestion! I'll do that. Any ideas how to remove the= =20 > >>FBSDID line jitter from the patches? > > > > > >When you check out the files from CVS, do not expand the CVS keywords by > >doing: cvs co -kk >=20 > So, this brings up a quick question: what methods do most developers=20 > use when doing things like this? I looked in the developer's handbook,= =20 > but didn't see any quick guide on a good method. Do you keep the local= =20 > cvs repo up to date, then check it out, make changes, etc? How do you=20 > do the diffs, and track all the changes, while testing too? I'd like to= =20 > kind of copy someone else's known-functional method instead of coming up= =20 > with my own. The easiest way with existing tools is to work in a copy checked out from a locally mirrored CVS repository. You can then use "cvs diff" to generate diffs. If you add new files, you will need to hack the CVS metadate yourself if you want to use "cvs diff -N" to include those files. That's ugly, but it should work. Try a test repo to see what the changes to CVS/Entries would look like. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTqPsXY6L6fI4GtQRAj9KAKDfvmJuI3HcHS+HmslyM8qAGo5BmgCeJVbR UvE3qoWSS96Krhha7c3z7IQ= =Sty/ -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 18:28:47 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E159616A420; Thu, 13 Oct 2005 18:28:47 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 968E143D6A; Thu, 13 Oct 2005 18:28:40 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j9DIa6oW098131; Thu, 13 Oct 2005 14:36:06 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 13 Oct 2005 14:28:18 -0400 User-Agent: KMail/1.6.2 References: <200510131331.27906.thierry@herbelot.com> <200510131621.07299.thierry@herbelot.com> <200510131210.55135.jkim@FreeBSD.org> In-Reply-To: <200510131210.55135.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_FdqTDbJyKm4r4NS" Message-Id: <200510131428.21211.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV devel-20050919/1131/Wed Oct 12 16:35:32 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Joshua Coombs , Juergen Lock , thierry@herbelot.com, freebsd-emulation@FreeBSD.org, Bakul Shah , Warner Losh Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 18:28:48 -0000 --Boundary-00=_FdqTDbJyKm4r4NS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 13 October 2005 12:10 pm, Jung-uk Kim wrote: > QEMU emulates RTL8029: > > ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 > ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 > > and Warner Losh MFC'd new ed(4) right before 6.0-RC1: > > http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 > > The new driver does more aggressive probing and it seems QEMU > cannot handle it. Just for the time being, you can drop the attachment in ports/emulators/qemu/files directory and rebuild qemu to get ed(4) back. Jung-uk Kim --Boundary-00=_FdqTDbJyKm4r4NS Content-Type: text/plain; charset="utf-8"; name="patch-hw::ne2000.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-hw::ne2000.c" --- qemu/hw/ne2000.c.orig Thu Apr 28 15:45:10 2005 +++ qemu/hw/ne2000.c Thu Oct 13 12:40:27 2005 @@ -676,10 +676,10 @@ -1, NULL, NULL); pci_conf = d->dev.config; - pci_conf[0x00] = 0xec; // Realtek 8029 - pci_conf[0x01] = 0x10; - pci_conf[0x02] = 0x29; - pci_conf[0x03] = 0x80; + pci_conf[0x00] = 0x06; // VIA VT86C926 + pci_conf[0x01] = 0x11; + pci_conf[0x02] = 0x26; + pci_conf[0x03] = 0x09; pci_conf[0x0a] = 0x00; // ethernet network controller pci_conf[0x0b] = 0x02; pci_conf[0x0e] = 0x00; // header_type --Boundary-00=_FdqTDbJyKm4r4NS-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 18:31:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31E1116A41F; Thu, 13 Oct 2005 18:31:27 +0000 (GMT) (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 A468043D45; Thu, 13 Oct 2005 18:31:26 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9DIVOsA075215; Thu, 13 Oct 2005 14:31:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9DIVP43000482; Thu, 13 Oct 2005 14:31:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1DBA37302F; Thu, 13 Oct 2005 14:31:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051013183125.1DBA37302F@freebsd-current.sentex.ca> Date: Thu, 13 Oct 2005 14:31:25 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2005 18:31:27 -0000 TB --- 2005-10-13 17:30:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-13 17:30:34 - starting HEAD tinderbox run for i386/i386 TB --- 2005-10-13 17:30:34 - cleaning the object tree TB --- 2005-10-13 17:31:09 - checking out the source tree TB --- 2005-10-13 17:31:09 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-10-13 17:31:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-13 17:37:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-13 17:37:39 - cd /src TB --- 2005-10-13 17:37:39 - /usr/bin/make -B buildworld >>> 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 [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o sconfig sconfig.o gzip -cn /src/sbin/sconfig/sconfig.8 > sconfig.8.gz ===> sbin/setkey (all) cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/sbin/setkey/setkey.c cc -O2 -pipe -I/src/sbin/setkey -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../lib/libipsec -I/src/sbin/setkey/../../sys/netkey -DIPSEC_DEBUG -DINET6 -DYY_NO_UNPUT -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c parse.c /src/sbin/setkey/parse.y: In function `setkeymsg_add': /src/sbin/setkey/parse.y:1023: warning: dereferencing type-punned pointer will break strict-aliasing rules /src/sbin/setkey/parse.y:1039: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /src/sbin/setkey. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-13 18:31:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-13 18:31:24 - ERROR: failed to build world TB --- 2005-10-13 18:31:24 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 19:13:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B453816A41F for ; Thu, 13 Oct 2005 19:13:36 +0000 (GMT) (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 5E24943D4C for ; Thu, 13 Oct 2005 19:13:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 6BE34BC66; Thu, 13 Oct 2005 19:13:33 +0000 (UTC) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 13 Oct 2005 06:36:32 CDT." <434E46C0.7060903@centtech.com> Date: Thu, 13 Oct 2005 21:13:32 +0200 Message-ID: <9165.1129230812@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Current Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 19:13:36 -0000 In message <434E46C0.7060903@centtech.com>, Eric Anderson writes: >[resend to -current for broader test audience] > >I've just finished the first version of ufsstat, a tool to show local >filesystem statistics much like nfsstat does for NFS. I would far to prefer to see a generic method that would work on all filesystems types, rather than a ufs specific tool. If you added counting code to the VOP_FOO() expansions, you should be able to gather statistics for all filesystem types. The collection could be controlled by a mount option if the impact is too big. -- 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 Oct 13 19:30:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4BCB16A420; Thu, 13 Oct 2005 19:30:59 +0000 (GMT) (envelope-from bsd@kelleycows.com) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCF9B43D45; Thu, 13 Oct 2005 19:30:58 +0000 (GMT) (envelope-from bsd@kelleycows.com) Received: from [10.3.29.200] (c-24-30-114-96.hsd1.ca.comcast.net[24.30.114.96]) by comcast.net (sccrmhc14) with ESMTP id <2005101319305101400naccje>; Thu, 13 Oct 2005 19:30:56 +0000 Message-ID: <434EB5E6.7020109@kelleycows.com> Date: Thu, 13 Oct 2005 12:30:46 -0700 From: Christopher Kelley User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20051013175249.804CB16A454@hub.freebsd.org> In-Reply-To: <20051013175249.804CB16A454@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jung-uk Kim Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 19:30:59 -0000 >On Wednesday 12 October 2005 11:02 am, stanley jobson wrote: > > >>> hi, >>> >> >> >>>> > - The QEMU and VMWare packages are known to expose problems in >>>> > the IDE CDROM driver during OS install. >>> >>> >>> >>> will this be corrected for 6-stable? >> >> > >Yes. > >http://docs.freebsd.org/cgi/mid.cgi?200510092124.j99LOBcs038237 >http://docs.freebsd.org/cgi/mid.cgi?200510122017.j9CKHZTk067708 > >Jung-uk Kim > > I am having a problem installing 6-RC1, that I am wondering if this will also fix. It starts to copy from the CD drive, then pretty quickly I get; panic: vm_fault: fault on nofault entry, addr: c641e000 Uptime: 1m44s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort. This is a straight install, I'm not running under VMWare (and I haven't actually a clue what QEMU is), but I don't know if this is something that might be related. The addr is different each time. This is my "beater" machine, an old P233/mmx with only 96megs, but I've successfully installed various 5.x versions, windows, etc on this machine. I've even in the past successfully cvsup'd from 5.4 to 6, just to see if it would work. If I need to provide any more info, please let me know. Christopher From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 19:41:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2355D16A41F for ; Thu, 13 Oct 2005 19:41:39 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E43E43D46 for ; Thu, 13 Oct 2005 19:41:37 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j9DJfZXX088501; Thu, 13 Oct 2005 14:41:36 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434EB85A.9030308@centtech.com> Date: Thu, 13 Oct 2005 14:41:14 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <9165.1129230812@critter.freebsd.dk> In-Reply-To: <9165.1129230812@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1131/Wed Oct 12 15:35:32 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 19:41:39 -0000 Poul-Henning Kamp wrote: > In message <434E46C0.7060903@centtech.com>, Eric Anderson writes: > >>[resend to -current for broader test audience] >> >>I've just finished the first version of ufsstat, a tool to show local >>filesystem statistics much like nfsstat does for NFS. > > > I would far to prefer to see a generic method that would work > on all filesystems types, rather than a ufs specific tool. > > If you added counting code to the VOP_FOO() expansions, you should > be able to gather statistics for all filesystem types. > > The collection could be controlled by a mount option if the impact > is too big. That's an idea I thought of as well, but wanted to start small, since I really am new to C programming. Now that I've done this part, I'll look at the various vop_* pieces and see if it's something in my grasp. From what it sounds like, you'd also like to see per-mount point stats, but from the vfs layer, right? If that's true, then do you have any suggestions on how to store the statistics for each mounted fs? Thanks for the feedback! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 19:53:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D02C016A41F for ; Thu, 13 Oct 2005 19:53:50 +0000 (GMT) (envelope-from Paul.Dekkers@surfnet.nl) Received: from dorsvlegel.surfnet.nl (dorsvlegel.surfnet.nl [192.87.108.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74EB643D46 for ; Thu, 13 Oct 2005 19:53:49 +0000 (GMT) (envelope-from Paul.Dekkers@surfnet.nl) Received: from gromit.ipv6.chippie.org ([2001:610:508:2121:207:e9ff:fe8f:a375] helo=[IPv6:2001:610:508:2121:207:e9ff:fe8f:a375]) by dorsvlegel.surfnet.nl (Exim 4.54) with esmtps (TLSv1:AES256-SHA:256) id 1EQ99A-0003Gu-TN; Thu, 13 Oct 2005 21:53:48 +0200 Message-ID: <434EBB4C.8030609@surfnet.nl> Date: Thu, 13 Oct 2005 21:53:48 +0200 From: Paul Dekkers User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Kelley References: <20051013175249.804CB16A454@hub.freebsd.org> <434EB5E6.7020109@kelleycows.com> In-Reply-To: <434EB5E6.7020109@kelleycows.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SURFnet-Sender-check: 8ae21ef524b09d992f22af3c70f0e299 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 19:53:50 -0000 Hi, Christopher Kelley wrote: > I am having a problem installing 6-RC1, that I am wondering if this > will also fix. It starts to copy from the CD drive, then pretty > quickly I get; > > panic: vm_fault: fault on nofault entry, addr: c641e000 > Uptime: 1m44s > Cannot dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort. > > This is a straight install, I'm not running under VMWare (and I > haven't actually a clue what QEMU is), but I don't know if this is > something that might be related. The addr is different each time. > > This is my "beater" machine, an old P233/mmx with only 96megs, but > I've successfully installed various 5.x versions, windows, etc on this > machine. I've even in the past successfully cvsup'd from 5.4 to 6, > just to see if it would work. FWIW, I just experienced the same with a straight install on a Dell PE 1300, a PIII-500. It was half way through copying the "bin" set. Paul BTW, Probably unrelated: I had to disable apic in order to boot (I'm on the latest BIOS, A12) and ACPI disabled itself. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 19:59:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ED1F16A41F for ; Thu, 13 Oct 2005 19:59:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95F4043D46 for ; Thu, 13 Oct 2005 19:59:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DJvgd8076502; Thu, 13 Oct 2005 13:57:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 13:58:51 -0600 (MDT) Message-Id: <20051013.135851.02300147.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200510131859.03307.thierry@herbelot.com> References: <055201c5d012$2c8ca250$1700a8c0@failure> <20051013.103917.03114813.imp@bsdimp.com> <200510131859.03307.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 13:57:48 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 19:59:56 -0000 In message: <200510131859.03307.thierry@herbelot.com> Thierry Herbelot writes: : Le Thursday 13 October 2005 18:39, M. Warner Losh a =E9crit : : > In message: <055201c5d012$2c8ca250$1700a8c0@failure> : > : > "Joshua Coombs" writes: : > : Interesting. I wonder if this MFC means my 8019 will support ful= l : > : duplex under FreeBSD? The NetBSD 'ne' driver has access to softw= are : > : based media selection, it'd be nice to have access to an ISA nic = that : > : handled full-duplex properly. : > : > That's the idea. : > : > Warner : = : Hello, : = : Just FYI, I've just checked that I have the full complement of boards= (ISA ne2 = : at isa0 port 0x280/32 irq 9 under Open, PCI under ??? and PCMCIA runn= ing = : flawlessly under both FreeBSD current and post 6.0-RC1) : = : I planned to convert the old OpenBSD machine (with the ISA board) to = at least = : dual-boot with FreeBSD-6.0, but as I use qemu to prepare the partitio= n image, = : I'm a bit stuck for now. : = : Is there an iso image for a recent -current ? I had a look at the for= mer = : japanese snapshot site, but it seems to only follow 5.4-Stable. I'll be fixing this in the next day or three and it will be MFC'd from head into RC2 when that happens. I'm not sure where the snapshots are, but there's a patch floating around to get around the qemu issue just posted if you can't wait. I plan on trying it now with RC1. I also plan on looking into the ne2000.c emulation to see why things are failing (eg, is it a flaw in the RTL8029 emulation, or a flaw in if_ed somewhere). Warner From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:14:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C278B16A41F for ; Thu, 13 Oct 2005 20:14:52 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36FB143D46 for ; Thu, 13 Oct 2005 20:14:52 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 13 Oct 2005 16:31:14 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 15:30:14 -0400 User-Agent: KMail/1.8.2 References: <17218.49812.271334.154595@grasshopper.cs.duke.edu> <20051004195742.GA56798@xor.obsecurity.org> <17220.5283.170670.956780@grasshopper.cs.duke.edu> In-Reply-To: <17220.5283.170670.956780@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510131530.16376.jhb@freebsd.org> Cc: Andrew Gallatin , Kris Kennaway Subject: Re: lockmgr: thread <..> unlocking unheld 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: Thu, 13 Oct 2005 20:14:52 -0000 On Wednesday 05 October 2005 02:00 pm, Andrew Gallatin wrote: > It also seems to have started happening on a second amd64 that I just > upgraded from a mid-august -current to CVS cvsupped yesterday. This > is a UP amd64 3000+.. Can you try reverting any of the recent changes to amd64/include/atomic.h? The ones to change foo_ptr() to take uintptr_t should be fine, but maybe try reverting the changes after that (not using +m for example). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:14:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D63F616A420; Thu, 13 Oct 2005 20:14:52 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C62C43D45; Thu, 13 Oct 2005 20:14:51 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 13 Oct 2005 16:31:13 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 15:24:35 -0400 User-Agent: KMail/1.8.2 References: <200510110943.j9B9h7vk044447@gw.catspoiler.org> In-Reply-To: <200510110943.j9B9h7vk044447@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510131524.38744.jhb@freebsd.org> Cc: Don Lewis , openoffice@freebsd.org, re@freebsd.org, mi+mx@aldan.algebra.com, kris@obsecurity.org Subject: Re: 6.0 hangs (while building OOo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 20:14:53 -0000 On Tuesday 11 October 2005 05:43 am, Don Lewis wrote: > On 6 Oct, Kris Kennaway wrote: > > There is code in -current that saves stack traces when lockmgr locks > > are acquired, when DEBUG_LOCKS is enabled - except it sometimes panics > > while trying to save the trace because of a code bug. I remind jeffr > > about this on a more-or-less daily basis, but he hasn't had time to > > commit the fix he has yet. It still may be useful if this is easily > > reproducible. > > I haven't yet tried to backport this to RELENG_6 and I've been having > trouble reproducing it on my SMP machine. It looks like it has some > sort of hardware problem that is causing it to lock up under load. > > >> This problem appears to be some sort of vnode lock leak. > > > > leaked lockmgr locks usually panic when the thread exits. > > There's a KASSERT to in userret() to catch this in the syscall return > path, but that check is only enabled if the INVARIANTS kernel option is > enabled, which is not currently true in RELENG_6, and Mikhail doesn't > want to risk a panic on the machine in question, which is at a remote > location. > > He did reproduce the problem again with DEBUG_LOCKS enabled and we got > some more info. Here's the locked vnode in question: > > (kgdb) print *(struct vnode *)0xc2741ad4 > $1 = {v_type = VDIR, v_tag = 0xc0729abe "ufs", v_op = 0xc076c5c0, > v_data = 0xc2c03630, v_mount = 0xc1f72000, v_nmntvnodes = { > tqe_next = 0xc2742c08, tqe_prev = 0xc2dfa880}, v_un = {vu_mount = 0x0, > vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { > le_next = 0xc2895604, le_prev = 0xc1f01f28}, v_hash = 218659, > v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, > tqh_last = 0xc2741b04}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, > v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xc0783b4c, > lk_flags = 33816640, lk_sharecount = 0, lk_waitcount = 1, > lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc0729abe "ufs", > lk_timo = 6, lk_lockholder = 0xc1fe2300, lk_newlock = 0x0, > lk_filename = 0xc072b093 "/var/src/sys/kern/vfs_subr.c", > lk_lockername = 0xc072aab4 "vop_stdlock", lk_lineno = 1951, > lk_slockholder = 0xffffffff, lk_sfilename = 0xc071d296 "none", > lk_slockername = 0xc0724a8d "never share locked", lk_slineno = 0}, > v_interlock = {mtx_object = {lo_class = 0xc075b224, > lo_name = 0xc072b100 "vnode interlock", > lo_type = 0xc072b100 "vnode interlock", lo_flags = 196608, lo_list = > { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, > mtx_recurse = 0}, v_vnlock = 0xc2741b2c, > filename = 0xc07382b1 "/var/src/sys/ufs/ufs/ufs_lookup.c", line = 563, > v_holdcnt = 5, v_usecount = 4, v_iflag = 0, v_vflag = 0, v_writecount = > 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0xc29b4948}, v_bufobj = { > bo_mtx = 0xc2741b6c, bo_clean = {bv_hd = {tqh_first = 0xcc1cbd48, tqh_last > = 0xcc1cbd80}, bv_root = 0xcc1cbd48, bv_cnt = 1}, bo_dirty = { bv_hd = > {tqh_first = 0x0, tqh_last = 0xc2741bcc}, bv_root = 0x0, bv_cnt = 0}, > bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc0761b04, bo_bsize = 16384, > bo_object = 0xc30cc39c, bo_synclist = {le_next = 0x0, le_prev = 0x0}, > bo_private = 0xc2741ad4, __bo_vnode = 0xc2741ad4}, v_pollinfo = 0x0, > v_label = 0x0} > i) > > The culprit process knows that it is holding the lock: > > (kgdb) print ((struct vnode *)0xc2741ad4)->v_lock->lk_lockholder->td_locks > $3 = 1 > > And this is its stack trace, once again in wait4(): > > (kgdb) where > #0 sched_switch (td=0xc1fe2300, newtd=0xc1e5b300, flags=1) > at /var/src/sys/kern/sched_4bsd.c:980 > #1 0xc1fe2300 in ?? () > #2 0xc0526218 in mi_switch (flags=1, newtd=0x0) > at /var/src/sys/kern/kern_synch.c:356 > #3 0xc0545127 in sleepq_switch (wchan=0x0) > at /var/src/sys/kern/subr_sleepqueue.c:427 > #4 0xc0545400 in sleepq_wait_sig (wchan=0x0) > at /var/src/sys/kern/subr_sleepqueue.c:552 > #5 0xc0525e67 in msleep (ident=0xc1fe520c, mtx=0xc1fe5274, priority=348, > wmesg=0x0, timo=0) at /var/src/sys/kern/kern_synch.c:225 > #6 0xc04feaec in kern_wait (td=0xc1fe2300, pid=-1, status=0xd4922c80, > options=0, rusage=0x0) at /var/src/sys/kern/kern_exit.c:772 > #7 0xc04fdeed in wait4 (td=0x0, uap=0xd4922d04) > at /var/src/sys/kern/kern_exit.c:569 > #8 0xc06ed702 in syscall (frame= > {tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = > 134900352, tf_esi = 9195, tf_ebp = -1077951176, tf_isp = -728617628, tf_ebx > = 672547876, t f_edx = 0, tf_ecx = 137943616, tf_eax = 7, tf_trapno = 12, > tf_err = 2, tf_eip = 671979599, tf_cs = 51, tf_eflags = 534, tf_esp = > -1077951204, tf_ss = 59}) at /var/src/sys/i386/i386/trap.c:976 > #9 0xc06d651f in Xint0x80_syscall () at > /var/src/sys/i386/i386/exception.s:200 #10 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > > The code referenced by the vnode filename and line members is this block > in ufs_lookup(): > > if (flags & ISDOTDOT) { > VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ > error = VFS_VGET(pdp->v_mount, dp->i_ino, > cnp->cn_lkflags, &tdp); > --> vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); > if (error) > return (error); > *vpp = tdp; > } else ... > > > I don't see any obvious lock leaks in the code. Looks like the function returns with the desired leaf vnode locked if I grokked it correctly in my brief perusal, so the bug could be in the caller. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:14:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6CFD16A426 for ; Thu, 13 Oct 2005 20:14:53 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B29143D45 for ; Thu, 13 Oct 2005 20:14:53 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 13 Oct 2005 16:31:15 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 15:50:30 -0400 User-Agent: KMail/1.8.2 References: <20051006075312.GM86136@pcwin002.win.tue.nl> <20051007074520.GS86136@pcwin002.win.tue.nl> In-Reply-To: <20051007074520.GS86136@pcwin002.win.tue.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510131550.31272.jhb@freebsd.org> Cc: Subject: Re: interrupt throttling stepping in too soon? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 20:14:54 -0000 On Friday 07 October 2005 03:45 am, Stijn Hoop wrote: > Followup to my own problem: > > On Thu, Oct 06, 2005 at 09:53:12AM +0200, Stijn Hoop wrote: > > On the console there were multiple DMA_TIMEOUT messages for the disks of > > the array, and just above those was a line about an 'interrupt storm for > > atapci0, throttling'. > > After a rebuild which completed succesfully, I rsynced data to the disks. > About 5 minutes later the same message appeared and the machine panic'd, > this time destroying /var/log with it :-/ > > Anyway, I decided to hammer the disks without waiting a long time for > gvinum to build an array, and indeed I can reproduce this by mounting all 4 > drives, and for each drive dd'ing the whole drive to /dev/null plus > rsync'ing data to it at the same time. It held up at 20 MB/s but I suspect > that the box isn't keeping up with the combined total of interrupts because > it goes down faster when I engage the network (rsync from a remote box). > > So, I guess my question becomes: is there a way to find out why this box > can't handle enough interrupts? Could it be that the motherboard is flawed? > Is this definitely a hardware error or is it still possible that the > interrupt throttling is stepping in too soon and thus screwing the rest > of the system? > > On a sidenote, I monitored systat -vmstat while doing the above and it > appeared that IRQ 11 (ATA controller) was doing around 1000-1100 > irqs/s, and IRQ 5 (xl0) was doing around 800-1000 irqs/s. Is there a > way to log this somehow? Yes, when throttling is on, we limit the interrupts to about hz per second. You can try turning throttling off (by setting the limit to 0) or increasing the threshold via the sysctl hw.intr_storm_threshold. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:14:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DAB716A41F for ; Thu, 13 Oct 2005 20:14:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E00F43D45 for ; Thu, 13 Oct 2005 20:14:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 13 Oct 2005 16:31:15 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 15:51:45 -0400 User-Agent: KMail/1.8.2 References: <200510061321.35170.current@dino.sk> In-Reply-To: <200510061321.35170.current@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510131551.46397.jhb@freebsd.org> Cc: Milan Obuch Subject: Re: pcf module 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, 13 Oct 2005 20:14:54 -0000 On Thursday 06 October 2005 07:21 am, Milan Obuch wrote: > While working on ACCESS.bus support for Geode based WRAP boards I run into > some linker issue. As Geode's controller is full hardware implementation, I > used pcf as a template, sort of. > > After I put my base module infrastructure together and began work with > actual hardware functions and iicbus interface, my module no longer > kldloaded. > > Then I checked pcf module and found the same behavior. If you have no > 'device iicbus' in kernel configuration, issuing 'kldload pcf' gives > link_elf: symbol iicbus_intr undefined > kldload: can't load pcf: No such file or directory. > > Adding 'device iibus' into kernel configuration and rebuilding kernel fixes > this, so it looks like symbol is just not exported. > > As I am using module for development and resulting code will be built in > kernel in application platform (most probably), it is not big issue to me. > I use found work-around. It would be just nice to get this fixed. > > Anyway, is anybody out there using pcf? There is some work done in this > area, but not yet linked into main tree. I have not pcf hardware, so I can > not test anything in this area, but it would be good to make the transition > from older i386/isa/pcf.c to new dev/pcf/... Sounds like it is missing a 'MODULE_DEPEND(iicbus, 1, 1, 1);' line. Can you try adding one and seeing if it fixes the kldload of pcf? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:21:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B87616A41F for ; Thu, 13 Oct 2005 20:21:31 +0000 (GMT) (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 C1C0843D48 for ; Thu, 13 Oct 2005 20:21:30 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id CF64BBC7A; Thu, 13 Oct 2005 20:21:28 +0000 (UTC) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 13 Oct 2005 14:41:14 CDT." <434EB85A.9030308@centtech.com> Date: Thu, 13 Oct 2005 22:21:27 +0200 Message-ID: <9523.1129234887@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Current Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 20:21:31 -0000 In message <434EB85A.9030308@centtech.com>, Eric Anderson writes: >Poul-Henning Kamp wrote: >> I would far to prefer to see a generic method that would work >> on all filesystems types, rather than a ufs specific tool. >> >> If you added counting code to the VOP_FOO() expansions, you should >> be able to gather statistics for all filesystem types. >> >> The collection could be controlled by a mount option if the impact >> is too big. > >That's an idea I thought of as well, but wanted to start small, since I >really am new to C programming. Now that I've done this part, I'll look >at the various vop_* pieces and see if it's something in my grasp. I'd prefer for us to not commit a ufs-only solution, that would be enough to hold off a filesystem independent solution. > From what it sounds like, you'd also like to see per-mount point stats, >but from the vfs layer, right? If that's true, then do you have any >suggestions on how to store the statistics for each mounted fs? In struct mount ? -- 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 Oct 13 20:22:35 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36B3816A41F for ; Thu, 13 Oct 2005 20:22:35 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 563E643D49 for ; Thu, 13 Oct 2005 20:22:34 +0000 (GMT) (envelope-from felipegrazziotin@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so44970nzk for ; Thu, 13 Oct 2005 13:22:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=eY/Uvu5Lqm0tmHi7xuhRAop82DPIJKbJn2zGH3UxDc7EznRvCjCSpr6UF3VAYhY0m1/G6inmuJsf4TmoiiP07rmNfrv7bVxE8f79w5wUzNerQI/q31PQ2pHD1zR4Je98/KLX3QOkEmb12oCN6nu4QWkfdzTEdx05UFp7QrNEo/0= Received: by 10.36.49.17 with SMTP id w17mr2750200nzw; Thu, 13 Oct 2005 13:22:33 -0700 (PDT) Received: by 10.36.134.19 with HTTP; Thu, 13 Oct 2005 13:22:33 -0700 (PDT) Message-ID: <621b657f0510131322x78857d81u7cbe8967151568f2@mail.gmail.com> Date: Thu, 13 Oct 2005 17:22:33 -0300 From: Felipe openglx Sender: felipegrazziotin@gmail.com To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: 6.0 RC1: sound recording with snd_t4dwave doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 20:22:35 -0000 Hello people, anyone else is having problems when trying to do sound recording (with gnome-sound-recorder or having a conversation at Skype, for example) with a SiS 7018 (on-board) soundcard? dmesg tell me this: pcm0:record:0: record interrupt timeout, channel dead and Skype stderr shows: /dev/dsp-1: Device or resource busy I had that error on FreeBSD 5.4 already, and thought that maybe 6.0 could had solved that. The machine is running 6.0RC1, with (the default) GENERIC kernel. Maybe changing the modules? openglx@volahia:~$ kldstat Id Refs Address Size Name 1 21 0xc0400000 62f584 kernel 2 1 0xc0a30000 45b8 snd_t4dwave.ko 3 2 0xc0a35000 1d908 sound.ko 4 1 0xc0a53000 32c4 sis.ko 5 2 0xc0a57000 eeec drm.ko 6 16 0xc0a66000 568bc acpi.ko 7 1 0xc1bf7000 e000 ext2fs.ko 8 1 0xc1cbf000 2000 fire_saver.ko 9 1 0xc1cdd000 15000 linux.ko 10 4 0xc1d68000 a000 netgraph.ko 11 1 0xc1d76000 3000 ng_ether.ko 12 1 0xc1d7a000 5000 ng_pppoe.ko 13 1 0xc1d82000 4000 ng_socket.ko openglx@volahia:~$ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xde00 irq 10 kld snd_t4dwave (4p/1r/4v channels duplex default) And I do already have this sysctls for sound: hw.snd.pcm0.vchans=3D4 hw.snd.maxautovchans=3D4 Could this be a soundcard problem? I wouldn't be surprised, as the sis driver for X.org just reboots my machine (problem already solved if I use the vesa driver). Thanks in advance, -- openglx@StarByte.net From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:25:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5973716A424; Thu, 13 Oct 2005 20:25:11 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFC6343D48; Thu, 13 Oct 2005 20:25:05 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9DKP5iW022584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2005 16:25:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9DKP0Up009166; Thu, 13 Oct 2005 16:25:00 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17230.49819.985757.378764@grasshopper.cs.duke.edu> Date: Thu, 13 Oct 2005 16:24:59 -0400 (EDT) To: John Baldwin In-Reply-To: <200510131530.16376.jhb@freebsd.org> References: <17218.49812.271334.154595@grasshopper.cs.duke.edu> <20051004195742.GA56798@xor.obsecurity.org> <17220.5283.170670.956780@grasshopper.cs.duke.edu> <200510131530.16376.jhb@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: lockmgr: thread <..> unlocking unheld 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: Thu, 13 Oct 2005 20:25:11 -0000 John Baldwin writes: > On Wednesday 05 October 2005 02:00 pm, Andrew Gallatin wrote: > > It also seems to have started happening on a second amd64 that I just > > upgraded from a mid-august -current to CVS cvsupped yesterday. This > > is a UP amd64 3000+.. > > Can you try reverting any of the recent changes to amd64/include/atomic.h? > The ones to change foo_ptr() to take uintptr_t should be fine, but maybe try > reverting the changes after that (not using +m for example). Inline asm is Greek to me, and I'd be no better than a monkey typing at making changes like that. Would you like me to just try reverting all of 1.38? Drew From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:29:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BD2316A41F for ; Thu, 13 Oct 2005 20:29:01 +0000 (GMT) (envelope-from bsd@kelleycows.com) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0268443D48 for ; Thu, 13 Oct 2005 20:28:55 +0000 (GMT) (envelope-from bsd@kelleycows.com) Received: from [10.3.29.200] (c-24-30-114-96.hsd1.ca.comcast.net[24.30.114.96]) by comcast.net (sccrmhc11) with ESMTP id <2005101320285401100lgb93e>; Thu, 13 Oct 2005 20:28:54 +0000 Message-ID: <434EC385.8020100@kelleycows.com> Date: Thu, 13 Oct 2005 13:28:53 -0700 From: Christopher Kelley User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Dekkers References: <20051013175249.804CB16A454@hub.freebsd.org> <434EB5E6.7020109@kelleycows.com> <434EBB4C.8030609@surfnet.nl> In-Reply-To: <434EBB4C.8030609@surfnet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 20:29:01 -0000 Paul Dekkers wrote: > Hi, > > Christopher Kelley wrote: > >> I am having a problem installing 6-RC1, that I am wondering if this >> will also fix. It starts to copy from the CD drive, then pretty >> quickly I get; >> >> panic: vm_fault: fault on nofault entry, addr: c641e000 >> Uptime: 1m44s >> Cannot dump. No dump device defined. >> Automatic reboot in 15 seconds - press a key on the console to abort. >> >> This is a straight install, I'm not running under VMWare (and I >> haven't actually a clue what QEMU is), but I don't know if this is >> something that might be related. The addr is different each time. >> >> This is my "beater" machine, an old P233/mmx with only 96megs, but >> I've successfully installed various 5.x versions, windows, etc on >> this machine. I've even in the past successfully cvsup'd from 5.4 to >> 6, just to see if it would work. > > > FWIW, I just experienced the same with a straight install on a Dell PE > 1300, a PIII-500. > It was half way through copying the "bin" set. > > Paul > > BTW, Probably unrelated: I had to disable apic in order to boot (I'm > on the latest BIOS, A12) and ACPI disabled itself. > Heh, ever get a new idea right after you press "enter" to send a message? I *DID* get it to work, by going into the BIOS and disabling UDMA access for both master and slave on the secondary IDE controller (the CDROM is on the secondary master, nothing on the secondary slave). I left the UDMA on for the primary IDE controller (where the hard drive is). So that's weird. Because I didn't have do that to install 5.x or Windows 98. I guess it won't affect anything, I don't think CDROMs are UDMA anyways. Christopher From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:48:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E51116A41F for ; Thu, 13 Oct 2005 20:48:27 +0000 (GMT) (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 739C843D48 for ; Thu, 13 Oct 2005 20:48:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9DKmLXT071531; Thu, 13 Oct 2005 14:48:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434EC813.60409@samsco.org> Date: Thu, 13 Oct 2005 14:48:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Kelley References: <20051013175249.804CB16A454@hub.freebsd.org> <434EB5E6.7020109@kelleycows.com> <434EBB4C.8030609@surfnet.nl> <434EC385.8020100@kelleycows.com> In-Reply-To: <434EC385.8020100@kelleycows.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Paul Dekkers , freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 20:48:27 -0000 Christopher Kelley wrote: > Paul Dekkers wrote: > >> Hi, >> >> Christopher Kelley wrote: >> >>> I am having a problem installing 6-RC1, that I am wondering if this >>> will also fix. It starts to copy from the CD drive, then pretty >>> quickly I get; >>> >>> panic: vm_fault: fault on nofault entry, addr: c641e000 >>> Uptime: 1m44s >>> Cannot dump. No dump device defined. >>> Automatic reboot in 15 seconds - press a key on the console to abort. >>> >>> This is a straight install, I'm not running under VMWare (and I >>> haven't actually a clue what QEMU is), but I don't know if this is >>> something that might be related. The addr is different each time. >>> >>> This is my "beater" machine, an old P233/mmx with only 96megs, but >>> I've successfully installed various 5.x versions, windows, etc on >>> this machine. I've even in the past successfully cvsup'd from 5.4 to >>> 6, just to see if it would work. >> >> >> >> FWIW, I just experienced the same with a straight install on a Dell PE >> 1300, a PIII-500. >> It was half way through copying the "bin" set. >> >> Paul >> >> BTW, Probably unrelated: I had to disable apic in order to boot (I'm >> on the latest BIOS, A12) and ACPI disabled itself. >> > Heh, ever get a new idea right after you press "enter" to send a > message? I *DID* get it to work, by going into the BIOS and disabling > UDMA access for both master and slave on the secondary IDE controller > (the CDROM is on the secondary master, nothing on the secondary slave). > I left the UDMA on for the primary IDE controller (where the hard drive > is). > > So that's weird. Because I didn't have do that to install 5.x or > Windows 98. I guess it won't affect anything, I don't think CDROMs are > UDMA anyways. > > Christopher > There is a candidate fix for all of these 'panic while copying files off the CD' problems. I've tested it successfully under Qemu since it happens most often there and in VMWare, but there is no reason why it shouldn't also happen on real hardware. So, for those with some to test, please go to ftp://ftp.freebs.org/pub/FreeBSD/snapshots and download the ISO there and install it. Then let me know ASAP whether it helps or not. Thanks, Scott From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:48:48 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF2AB16A41F; Thu, 13 Oct 2005 20:48:48 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D6543D46; Thu, 13 Oct 2005 20:48:47 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9DKmMAY052402; Thu, 13 Oct 2005 13:48:26 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510132048.j9DKmMAY052402@gw.catspoiler.org> Date: Thu, 13 Oct 2005 13:48:22 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200510131524.38744.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: mi+mx@aldan.algebra.com, freebsd-current@FreeBSD.org, re@FreeBSD.org, openoffice@FreeBSD.org, kris@obsecurity.org Subject: Re: 6.0 hangs (while building OOo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 20:48:49 -0000 On 13 Oct, John Baldwin wrote: > On Tuesday 11 October 2005 05:43 am, Don Lewis wrote: >> On 6 Oct, Kris Kennaway wrote: [ snip - attributions trimmed to much - I said:] >> >> This problem appears to be some sort of vnode lock leak. >> > >> > leaked lockmgr locks usually panic when the thread exits. >> >> There's a KASSERT to in userret() to catch this in the syscall return >> path, but that check is only enabled if the INVARIANTS kernel option is >> enabled, which is not currently true in RELENG_6, and Mikhail doesn't >> want to risk a panic on the machine in question, which is at a remote >> location. >> >> He did reproduce the problem again with DEBUG_LOCKS enabled and we got >> some more info. Here's the locked vnode in question: >> >> (kgdb) print *(struct vnode *)0xc2741ad4 >> $1 = {v_type = VDIR, v_tag = 0xc0729abe "ufs", v_op = 0xc076c5c0, >> v_data = 0xc2c03630, v_mount = 0xc1f72000, v_nmntvnodes = { >> tqe_next = 0xc2742c08, tqe_prev = 0xc2dfa880}, v_un = {vu_mount = 0x0, >> vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { >> le_next = 0xc2895604, le_prev = 0xc1f01f28}, v_hash = 218659, >> v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, >> tqh_last = 0xc2741b04}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, >> v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xc0783b4c, >> lk_flags = 33816640, lk_sharecount = 0, lk_waitcount = 1, >> lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc0729abe "ufs", >> lk_timo = 6, lk_lockholder = 0xc1fe2300, lk_newlock = 0x0, >> lk_filename = 0xc072b093 "/var/src/sys/kern/vfs_subr.c", >> lk_lockername = 0xc072aab4 "vop_stdlock", lk_lineno = 1951, >> lk_slockholder = 0xffffffff, lk_sfilename = 0xc071d296 "none", >> lk_slockername = 0xc0724a8d "never share locked", lk_slineno = 0}, >> v_interlock = {mtx_object = {lo_class = 0xc075b224, >> lo_name = 0xc072b100 "vnode interlock", >> lo_type = 0xc072b100 "vnode interlock", lo_flags = 196608, lo_list = >> { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, >> mtx_recurse = 0}, v_vnlock = 0xc2741b2c, >> filename = 0xc07382b1 "/var/src/sys/ufs/ufs/ufs_lookup.c", line = 563, >> v_holdcnt = 5, v_usecount = 4, v_iflag = 0, v_vflag = 0, v_writecount = >> 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0xc29b4948}, v_bufobj = { >> bo_mtx = 0xc2741b6c, bo_clean = {bv_hd = {tqh_first = 0xcc1cbd48, tqh_last >> = 0xcc1cbd80}, bv_root = 0xcc1cbd48, bv_cnt = 1}, bo_dirty = { bv_hd = >> {tqh_first = 0x0, tqh_last = 0xc2741bcc}, bv_root = 0x0, bv_cnt = 0}, >> bo_numoutput = 0, bo_flag = 0, bo_ops = 0xc0761b04, bo_bsize = 16384, >> bo_object = 0xc30cc39c, bo_synclist = {le_next = 0x0, le_prev = 0x0}, >> bo_private = 0xc2741ad4, __bo_vnode = 0xc2741ad4}, v_pollinfo = 0x0, >> v_label = 0x0} >> i) >> >> The culprit process knows that it is holding the lock: >> >> (kgdb) print ((struct vnode *)0xc2741ad4)->v_lock->lk_lockholder->td_locks >> $3 = 1 >> >> And this is its stack trace, once again in wait4(): >> >> (kgdb) where >> #0 sched_switch (td=0xc1fe2300, newtd=0xc1e5b300, flags=1) >> at /var/src/sys/kern/sched_4bsd.c:980 >> #1 0xc1fe2300 in ?? () >> #2 0xc0526218 in mi_switch (flags=1, newtd=0x0) >> at /var/src/sys/kern/kern_synch.c:356 >> #3 0xc0545127 in sleepq_switch (wchan=0x0) >> at /var/src/sys/kern/subr_sleepqueue.c:427 >> #4 0xc0545400 in sleepq_wait_sig (wchan=0x0) >> at /var/src/sys/kern/subr_sleepqueue.c:552 >> #5 0xc0525e67 in msleep (ident=0xc1fe520c, mtx=0xc1fe5274, priority=348, >> wmesg=0x0, timo=0) at /var/src/sys/kern/kern_synch.c:225 >> #6 0xc04feaec in kern_wait (td=0xc1fe2300, pid=-1, status=0xd4922c80, >> options=0, rusage=0x0) at /var/src/sys/kern/kern_exit.c:772 >> #7 0xc04fdeed in wait4 (td=0x0, uap=0xd4922d04) >> at /var/src/sys/kern/kern_exit.c:569 >> #8 0xc06ed702 in syscall (frame= >> {tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = >> 134900352, tf_esi = 9195, tf_ebp = -1077951176, tf_isp = -728617628, tf_ebx >> = 672547876, t f_edx = 0, tf_ecx = 137943616, tf_eax = 7, tf_trapno = 12, >> tf_err = 2, tf_eip = 671979599, tf_cs = 51, tf_eflags = 534, tf_esp = >> -1077951204, tf_ss = 59}) at /var/src/sys/i386/i386/trap.c:976 >> #9 0xc06d651f in Xint0x80_syscall () at >> /var/src/sys/i386/i386/exception.s:200 #10 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> >> >> The code referenced by the vnode filename and line members is this block >> in ufs_lookup(): >> >> if (flags & ISDOTDOT) { >> VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ >> error = VFS_VGET(pdp->v_mount, dp->i_ino, >> cnp->cn_lkflags, &tdp); >> --> vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); >> if (error) >> return (error); >> *vpp = tdp; >> } else ... >> >> >> I don't see any obvious lock leaks in the code. > > Looks like the function returns with the desired leaf vnode locked if I > grokked it correctly in my brief perusal, so the bug could be in the caller. Most likely, but the bug is only rarely triggered and is not caught by DEBUG_VFS_LOCKS. If INVARIANTS is enabled, the problem is caught by the KASSERT in userret(), which is rather too late to find the source of the problem. The problem tends to show up about a third of the way through the openoffice build, but at different places in different runs, and some builds are successful. I was not able to reproduce this problem at all until I discovered that Mikhail had the following in /etc/sysctl.conf: debug.vfscache=0 With this setting, I'm able to reproduce this problem, at least sometimes, on both my SMP box running 6.0-BETA5 and my UP box running HEAD. Earlier today I kicked off another run on the HEAD box with DEBUG_LOCKS and the KTR stuff enabled so I should at least get the call stack that grabbed the lock. The process always seems to be dmake, so I the syscall is probably stat(). I suspect that I'll have to sprinkle some more KTR calls in the code to find the problem. Because the problem doesn't seem to occur with the default debug.vfscache setting (or if it does, it is *very* rare), I don't think this is a show stopper for 6.0-RELEASE. It might be fun to run the stress tests with this sysctl setting. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:51:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6890916A41F for ; Thu, 13 Oct 2005 20:51:23 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0252D43D55 for ; Thu, 13 Oct 2005 20:51:22 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp2-g19.free.fr (Postfix) with ESMTP id BD028521CF for ; Thu, 13 Oct 2005 22:51:21 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9DKp7wi030362; Thu, 13 Oct 2005 22:51:12 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2005 22:50:59 +0200 User-Agent: KMail/1.8.2 References: <055201c5d012$2c8ca250$1700a8c0@failure> <200510131859.03307.thierry@herbelot.com> <20051013.135851.02300147.imp@bsdimp.com> In-Reply-To: <20051013.135851.02300147.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510132251.00632.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 13 Oct 2005 20:51:23 -0000 Le Thursday 13 October 2005 21:58, M. Warner Losh a écrit : > > I'll be fixing this in the next day or three and it will be MFC'd from > head into RC2 when that happens. I'm not sure where the snapshots > are, but there's a patch floating around to get around the qemu issue > just posted if you can't wait. I plan on trying it now with RC1. I > also plan on looking into the ne2000.c emulation to see why things are > failing (eg, is it a flaw in the RTL8029 emulation, or a flaw in if_ed > somewhere). Great ! I'll try the patch ASAP TfH From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:06:01 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B41B316A41F; Thu, 13 Oct 2005 21:06:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 115CE43D48; Thu, 13 Oct 2005 21:06:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DL5Hgj077137; Thu, 13 Oct 2005 15:05:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 15:06:26 -0600 (MDT) Message-Id: <20051013.150626.121295478.imp@bsdimp.com> To: nox@jelal.kn-bremen.de From: "M. Warner Losh" In-Reply-To: <20051013200254.GA11267@saturn.kn-bremen.de> References: <200510131210.55135.jkim@FreeBSD.org> <200510131428.21211.jkim@FreeBSD.org> <20051013200254.GA11267@saturn.kn-bremen.de> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 15:05:18 -0600 (MDT) Cc: jcoombs@gwi.net, thierry@herbelot.com, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, bakul@BitBlocks.com, jkim@FreeBSD.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 21:06:01 -0000 In message: <20051013200254.GA11267@saturn.kn-bremen.de> Juergen Lock writes: : On Thu, Oct 13, 2005 at 02:28:18PM -0400, Jung-uk Kim wrote: : > On Thursday 13 October 2005 12:10 pm, Jung-uk Kim wrote: : > > QEMU emulates RTL8029: : > > : > > ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 : > > ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 : > > : > > and Warner Losh MFC'd new ed(4) right before 6.0-RC1: : > > : > > http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 : > > : > > The new driver does more aggressive probing and it seems QEMU : > > cannot handle it. : > : > Just for the time being, you can drop the attachment in : > ports/emulators/qemu/files directory and rebuild qemu to get ed(4) : > back. : > : > Jung-uk Kim : : >[patch snipped] : : Okay, we could add this as an option to our qemu port (`-ne2kvia' or : something like that), anyone thinks it is necessary? (I guess this : issue will be fixed in 6.0-R?) We could also fix the RTL8029 emulation to like work :-) Warner From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:15:02 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12C6516A41F for ; Thu, 13 Oct 2005 21:15:02 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 05EBB43D67 for ; Thu, 13 Oct 2005 21:14:54 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail invoked by alias); 13 Oct 2005 21:14:52 -0000 Received: from unknown (EHLO klamath) [212.204.44.203] by mail.gmx.net (mp013) with SMTP; 13 Oct 2005 23:14:52 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: Brooks Davis In-Reply-To: <20051013181404.GC27418@odin.ac.hmc.edu> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <434E60D6.3030402@centtech.com> <20051013140536.GA10247@crodrigues.org> <434E7ADE.5030709@centtech.com> <20051013181404.GC27418@odin.ac.hmc.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Wy0FD6ODh8MQD3ldjQss" Date: Thu, 13 Oct 2005 23:14:50 +0200 Message-Id: <1129238090.1002.33.camel@klamath.syndrom23.de> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org, Eric Anderson Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 21:15:02 -0000 --=-Wy0FD6ODh8MQD3ldjQss Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-10-13 at 11:14 -0700, Brooks Davis wrote: > On Thu, Oct 13, 2005 at 10:18:54AM -0500, Eric Anderson wrote: > > Craig Rodrigues wrote: > > >On Thu, Oct 13, 2005 at 08:27:50AM -0500, Eric Anderson wrote: > > > > > >>Thanks - great suggestion! I'll do that. Any ideas how to remove th= e=20 > > >>FBSDID line jitter from the patches? > > > > > > > > >When you check out the files from CVS, do not expand the CVS keywords = by > > >doing: cvs co -kk > >=20 > > So, this brings up a quick question: what methods do most developers=20 > > use when doing things like this? I looked in the developer's handbook,= =20 > > but didn't see any quick guide on a good method. Do you keep the local= =20 > > cvs repo up to date, then check it out, make changes, etc? How do you=20 > > do the diffs, and track all the changes, while testing too? I'd like t= o=20 > > kind of copy someone else's known-functional method instead of coming u= p=20 > > with my own. >=20 > The easiest way with existing tools is to work in a copy checked out > from a locally mirrored CVS repository. You can then use "cvs diff" to > generate diffs. =20 > If you add new files, you will need to hack the CVS > metadate yourself if you want to use "cvs diff -N" to include those > files. That's ugly, but it should work. =20 This should not be needed at all. cvs add works as well.=20 Regards, -- Andreas --=20 was macht man eigentlich auf einer linux-gamer lan ? hl server aufsetzen und freuen ? *duck* ^^ --=-Wy0FD6ODh8MQD3ldjQss Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDTs5KYucd7Ow1ygwRAsQHAJ91FPjN5CIfdqtVr6uIQVx65YjASQCfahli kCBOFXjbykhyRbODCeludIk= =JDAZ -----END PGP SIGNATURE----- --=-Wy0FD6ODh8MQD3ldjQss-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:15:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DC4A16A41F for ; Thu, 13 Oct 2005 21:15:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD6EA43D6B for ; Thu, 13 Oct 2005 21:15:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DLDS7o077200; Thu, 13 Oct 2005 15:13:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 15:14:36 -0600 (MDT) Message-Id: <20051013.151436.85394837.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200510132251.00632.thierry@herbelot.com> References: <200510131859.03307.thierry@herbelot.com> <20051013.135851.02300147.imp@bsdimp.com> <200510132251.00632.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 15:13:28 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 21:15:12 -0000 In message: <200510132251.00632.thierry@herbelot.com> Thierry Herbelot writes: : Le Thursday 13 October 2005 21:58, M. Warner Losh a =E9crit : : > : > I'll be fixing this in the next day or three and it will be MFC'd f= rom : > head into RC2 when that happens. I'm not sure where the snapshots : > are, but there's a patch floating around to get around the qemu iss= ue : > just posted if you can't wait. I plan on trying it now with RC1. = I : > also plan on looking into the ne2000.c emulation to see why things = are : > failing (eg, is it a flaw in the RTL8029 emulation, or a flaw in if= _ed : > somewhere). : = : Great ! I'll try the patch ASAP Looks like it is a combination of problems. The PCI registers claim to be a 8029, but it doesn't emulate the 8029 specific registers. I have a patch for this. In addition, the ed driver has a mistake in its 8029 support. I've fixed this as well and am testing the result. Warner From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:15:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B9416A431 for ; Thu, 13 Oct 2005 21:15:15 +0000 (GMT) (envelope-from jdoolittle@kingsquarry.net) Received: from imf22aec.mail.bellsouth.net (imf22aec.mail.bellsouth.net [205.152.59.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9969343D68 for ; Thu, 13 Oct 2005 21:15:08 +0000 (GMT) (envelope-from jdoolittle@kingsquarry.net) Received: from ibm67aec.bellsouth.net ([68.209.160.53]) by imf22aec.mail.bellsouth.net with ESMTP id <20051013211507.JOT14447.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net> for ; Thu, 13 Oct 2005 17:15:07 -0400 Received: from saturn.kingsquarry.net ([68.209.160.53]) by ibm67aec.bellsouth.net with ESMTP id <20051013211503.UNOU1915.ibm67aec.bellsouth.net@saturn.kingsquarry.net> for ; Thu, 13 Oct 2005 17:15:03 -0400 Received: from localhost (localhost.kingsquarry.net [127.0.0.1]) by localhost.kingsquarry.net (Postfix) with ESMTP id 7DC8160DF for ; Thu, 13 Oct 2005 17:19:25 -0400 (EDT) Received: from saturn.kingsquarry.net ([127.0.0.1]) by localhost (saturn.kingsquarry.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00549-03-2 for ; Thu, 13 Oct 2005 17:19:24 -0400 (EDT) Received: from [127.0.0.1] (mars.kingsquarry.net [192.168.1.71]) by saturn.kingsquarry.net (Postfix) with ESMTP id C057F60CF for ; Thu, 13 Oct 2005 17:19:24 -0400 (EDT) Message-ID: <434ECE4D.8040003@kingsquarry.net> Date: Thu, 13 Oct 2005 17:14:53 -0400 From: Jeff Doolittle User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at kingsquarry.net Subject: 6.0-RC1 & ASUS P4R800-V/Sis 180 RAID X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 21:15:16 -0000 I upgraded my second machine to 6.0-RC1 this afternoon and have lost my raid mirror configured on an SIS 180 Raid controller (as provided on the ASUS P4R800-V motherboard). I've read the release notes and double checked UPDATING and I didn't see any removal of existing support (other than 80386). The array simply isn't even being picked up anymore (no AR0 device). What have I missed? This is true regardless of a GENERIC or custom kernel. The following is a cut-n-paste of the dmesg from my last GENERIC kernel boot: ======================================== FreeBSD 6.0-RC1 #1: Thu Oct 13 16:43:57 EDT 2005 root@mercury.kingsquarry.net:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x441d> Hyperthreading: 2 logical CPUs real memory = 535756800 (510 MB) avail memory = 514928640 (491 MB) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: Power Button (fixed) pci_link0: irq 0 on acpi0 pci_link1: irq 0 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 0 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) skc0: port 0xe400-0xe4ff mem 0xe1000000-0xe1003fff ir q 19 at device 13.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:11:2f:9e:f6:f0 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ohci0: mem 0xe1004000-0xe1004fff irq 19 at devic e 19.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe1005000-0xe1005fff irq 19 at devic e 19.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe1006000-0xe1006fff irq 19 at d evice 19.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: (0x1002) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf00 0-0xf00f at device 20.1 on pci0 ata0: on atapci0 ata1: on atapci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 fwohci0: port 0xc000-0xc07f mem 0xe0000000-0xe00007ff irq 17 at device 9.0 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:00:a2:7f:e5 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:a2:7f:e5 fwe0: Ethernet address: 02:e0:18:a2:7f:e5 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci1: port 0xc400-0xc407,0xc800-0xc803,0xcc00-0x cc07,0xd000-0xd003,0xd400-0xd40f irq 18 at device 10.0 on pci2 ata2: on atapci1 ata3: on atapci1 pci0: at device 20.5 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xcc000-0xcffff,0xd0000-0xd3fff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 3006903705 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA33 ad2: 76319MB at ata1-master UDMA33 acd0: CDROM at ata1-slave PIO3 Trying to mount root from ufs:/dev/ad0s1a ======================================== Thanks - Jeff From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:19:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E86D16A41F for ; Thu, 13 Oct 2005 21:19:03 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C797A43D72 for ; Thu, 13 Oct 2005 21:18:55 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9DLIr1C024876; Thu, 13 Oct 2005 14:18:53 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9DLIrPV024875; Thu, 13 Oct 2005 14:18:53 -0700 Date: Thu, 13 Oct 2005 14:18:53 -0700 From: Brooks Davis To: Andreas Kohn Message-ID: <20051013211853.GA16688@odin.ac.hmc.edu> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <434E60D6.3030402@centtech.com> <20051013140536.GA10247@crodrigues.org> <434E7ADE.5030709@centtech.com> <20051013181404.GC27418@odin.ac.hmc.edu> <1129238090.1002.33.camel@klamath.syndrom23.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <1129238090.1002.33.camel@klamath.syndrom23.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Eric Anderson Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 21:19:03 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2005 at 11:14:50PM +0200, Andreas Kohn wrote: > On Thu, 2005-10-13 at 11:14 -0700, Brooks Davis wrote: > > On Thu, Oct 13, 2005 at 10:18:54AM -0500, Eric Anderson wrote: > > > Craig Rodrigues wrote: > > > >On Thu, Oct 13, 2005 at 08:27:50AM -0500, Eric Anderson wrote: > > > > > > > >>Thanks - great suggestion! I'll do that. Any ideas how to remove = the=20 > > > >>FBSDID line jitter from the patches? > > > > > > > > > > > >When you check out the files from CVS, do not expand the CVS keyword= s by > > > >doing: cvs co -kk > > >=20 > > > So, this brings up a quick question: what methods do most developers= =20 > > > use when doing things like this? I looked in the developer's handboo= k,=20 > > > but didn't see any quick guide on a good method. Do you keep the loc= al=20 > > > cvs repo up to date, then check it out, make changes, etc? How do yo= u=20 > > > do the diffs, and track all the changes, while testing too? I'd like= to=20 > > > kind of copy someone else's known-functional method instead of coming= up=20 > > > with my own. > >=20 > > The easiest way with existing tools is to work in a copy checked out > > from a locally mirrored CVS repository. You can then use "cvs diff" to > > generate diffs. =20 >=20 > > If you add new files, you will need to hack the CVS > > metadate yourself if you want to use "cvs diff -N" to include those > > files. That's ugly, but it should work. =20 >=20 > This should not be needed at all. cvs add works as well.=20 Oops, you are correct. That is in fact not needed. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTs88XY6L6fI4GtQRAqv7AJ0evXDHG/rZCBaQ1j/bR5f08Rr5FACfXGQJ 9qvHuo1KcL+UEzA5dFeFFLw= =m6xN -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:33:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBF2116A41F; Thu, 13 Oct 2005 21:33:55 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from core.inec.ru (core.inec.ru [213.148.3.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6177443D45; Thu, 13 Oct 2005 21:33:55 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [213.85.81.137] (helo=[192.168.0.3]) by core.inec.ru with esmtp (Exim 4.51 (FreeBSD)) id 1EQAhU-0002ji-Ud; Fri, 14 Oct 2005 01:33:21 +0400 Message-ID: <434ED2C3.9010407@FreeBSD.org> Date: Fri, 14 Oct 2005 01:33:55 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051001) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: kientzle@FreeBSD.org Subject: installworld fails on fresh -current (libarchive 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: Thu, 13 Oct 2005 21:33:55 -0000 ===> lib/libarchive (install) printf: not found "/usr/src/lib/libarchive/Makefile", line 28: warning: "printf "%d.%02d.%03d" 1 2 36" returned non-zero status expr: not found "/usr/src/lib/libarchive/Makefile", line 31: warning: "expr 1 + 2" returned non- zero status install -C -o root -g wheel -m 444 libarchive.a /usr/lib install -C -o root -g wheel -m 444 libarchive_p.a /usr/lib install -s -o root -g wheel -m 444 libarchive.so. /usr/lib install: libarchive.so.: No such file or directory *** Error code 71 Stop in /usr/src/lib/libarchive. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 -- Sem. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:46:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 217A016A41F for ; Thu, 13 Oct 2005 21:46:13 +0000 (GMT) (envelope-from Paul.Dekkers@surfnet.nl) Received: from dorsvlegel.surfnet.nl (dorsvlegel.surfnet.nl [192.87.108.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 813D843D49 for ; Thu, 13 Oct 2005 21:46:11 +0000 (GMT) (envelope-from Paul.Dekkers@surfnet.nl) Received: from gromit.ipv6.chippie.org ([2001:610:508:2121:207:e9ff:fe8f:a375] helo=[IPv6:2001:610:508:2121:207:e9ff:fe8f:a375]) by dorsvlegel.surfnet.nl (Exim 4.54) with esmtps (TLSv1:AES256-SHA:256) id 1EQAtu-0003qj-WC; Thu, 13 Oct 2005 23:46:11 +0200 Message-ID: <434ED5A2.7090405@surfnet.nl> Date: Thu, 13 Oct 2005 23:46:10 +0200 From: Paul Dekkers User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20051013175249.804CB16A454@hub.freebsd.org> <434EB5E6.7020109@kelleycows.com> <434EBB4C.8030609@surfnet.nl> <434EC385.8020100@kelleycows.com> <434EC813.60409@samsco.org> In-Reply-To: <434EC813.60409@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SURFnet-Sender-check: 8ae21ef524b09d992f22af3c70f0e299 Cc: Christopher Kelley , freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 21:46:13 -0000 Scott, Scott Long wrote: > Christopher Kelley wrote: > >> Paul Dekkers wrote: >> >>> Christopher Kelley wrote: >>> >>>> I am having a problem installing 6-RC1, that I am wondering if this >>>> will also fix. It starts to copy from the CD drive, then pretty >>>> quickly I get; >>>> >>>> panic: vm_fault: fault on nofault entry, addr: c641e000 >>>> Uptime: 1m44s >>>> Cannot dump. No dump device defined. >>>> Automatic reboot in 15 seconds - press a key on the console to >>>> abort. >>>> >>>> This is a straight install, I'm not running under VMWare (and I >>>> haven't actually a clue what QEMU is), but I don't know if this is >>>> something that might be related. The addr is different each time. >>>> >>>> This is my "beater" machine, an old P233/mmx with only 96megs, but >>>> I've successfully installed various 5.x versions, windows, etc on >>>> this machine. I've even in the past successfully cvsup'd from 5.4 >>>> to 6, just to see if it would work. >>> >>> FWIW, I just experienced the same with a straight install on a Dell >>> PE 1300, a PIII-500. >>> It was half way through copying the "bin" set. >>> >>> Paul >>> >>> BTW, Probably unrelated: I had to disable apic in order to boot (I'm >>> on the latest BIOS, A12) and ACPI disabled itself. >> >> Heh, ever get a new idea right after you press "enter" to send a >> message? I *DID* get it to work, by going into the BIOS and >> disabling UDMA access for both master and slave on the secondary IDE >> controller (the CDROM is on the secondary master, nothing on the >> secondary slave). I left the UDMA on for the primary IDE controller >> (where the hard drive is). >> >> So that's weird. Because I didn't have do that to install 5.x or >> Windows 98. I guess it won't affect anything, I don't think CDROMs >> are UDMA anyways. >> >> Christopher > > There is a candidate fix for all of these 'panic while copying files off > the CD' problems. I've tested it successfully under Qemu since it > happens most often there and in VMWare, but there is no reason why it > shouldn't also happen on real hardware. So, for those with some to > test, please go to ftp://ftp.freebs.org/pub/FreeBSD/snapshots and > download the ISO there and install it. Then let me know ASAP whether > it helps or not. It helps; the 13 October snapshot installs just fine. Paul P.S. Unlike Christopher I have no UDMA settings in the BIOS, and hw.ata.ata_dma=0 didn't do it for me, so this fix is certainly welcome :-) From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:54:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB0616A41F for ; Thu, 13 Oct 2005 21:54:05 +0000 (GMT) (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 091BE43D46 for ; Thu, 13 Oct 2005 21:54:04 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9DLs23s079216; Thu, 13 Oct 2005 15:54:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <434ED779.7020300@samsco.org> Date: Thu, 13 Oct 2005 15:54:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Dekkers References: <20051013175249.804CB16A454@hub.freebsd.org> <434EB5E6.7020109@kelleycows.com> <434EBB4C.8030609@surfnet.nl> <434EC385.8020100@kelleycows.com> <434EC813.60409@samsco.org> <434ED5A2.7090405@surfnet.nl> In-Reply-To: <434ED5A2.7090405@surfnet.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Christopher Kelley , freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 21:54:05 -0000 Paul Dekkers wrote: > Scott, > > Scott Long wrote: > >> Christopher Kelley wrote: >> >>> Paul Dekkers wrote: >>> >>>> Christopher Kelley wrote: >>>> >>>>> I am having a problem installing 6-RC1, that I am wondering if this >>>>> will also fix. It starts to copy from the CD drive, then pretty >>>>> quickly I get; >>>>> >>>>> panic: vm_fault: fault on nofault entry, addr: c641e000 >>>>> Uptime: 1m44s >>>>> Cannot dump. No dump device defined. >>>>> Automatic reboot in 15 seconds - press a key on the console to >>>>> abort. >>>>> >>>>> This is a straight install, I'm not running under VMWare (and I >>>>> haven't actually a clue what QEMU is), but I don't know if this is >>>>> something that might be related. The addr is different each time. >>>>> >>>>> This is my "beater" machine, an old P233/mmx with only 96megs, but >>>>> I've successfully installed various 5.x versions, windows, etc on >>>>> this machine. I've even in the past successfully cvsup'd from 5.4 >>>>> to 6, just to see if it would work. >>>> >>>> >>>> FWIW, I just experienced the same with a straight install on a Dell >>>> PE 1300, a PIII-500. >>>> It was half way through copying the "bin" set. >>>> >>>> Paul >>>> >>>> BTW, Probably unrelated: I had to disable apic in order to boot (I'm >>>> on the latest BIOS, A12) and ACPI disabled itself. >>> >>> >>> Heh, ever get a new idea right after you press "enter" to send a >>> message? I *DID* get it to work, by going into the BIOS and >>> disabling UDMA access for both master and slave on the secondary IDE >>> controller (the CDROM is on the secondary master, nothing on the >>> secondary slave). I left the UDMA on for the primary IDE controller >>> (where the hard drive is). >>> >>> So that's weird. Because I didn't have do that to install 5.x or >>> Windows 98. I guess it won't affect anything, I don't think CDROMs >>> are UDMA anyways. >>> >>> Christopher >> >> >> There is a candidate fix for all of these 'panic while copying files off >> the CD' problems. I've tested it successfully under Qemu since it >> happens most often there and in VMWare, but there is no reason why it >> shouldn't also happen on real hardware. So, for those with some to >> test, please go to ftp://ftp.freebs.org/pub/FreeBSD/snapshots and >> download the ISO there and install it. Then let me know ASAP whether >> it helps or not. > > > It helps; the 13 October snapshot installs just fine. > > Paul > > P.S. Unlike Christopher I have no UDMA settings in the BIOS, and > hw.ata.ata_dma=0 didn't do it for me, so this fix is certainly welcome :-) > > Yeah, twiddling UDMA just changes the timing, it doesn't actually fix the bug. Scott From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:25:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 668BB16A41F for ; Thu, 13 Oct 2005 22:25:08 +0000 (GMT) (envelope-from bsd@kelleycows.com) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9594943D58 for ; Thu, 13 Oct 2005 22:25:07 +0000 (GMT) (envelope-from bsd@kelleycows.com) Received: from [10.3.29.200] (c-24-30-114-96.hsd1.ca.comcast.net[24.30.114.96]) by comcast.net (rwcrmhc14) with ESMTP id <200510132225050140096atte>; Thu, 13 Oct 2005 22:25:06 +0000 Message-ID: <434EDEC0.8000109@kelleycows.com> Date: Thu, 13 Oct 2005 15:25:04 -0700 From: Christopher Kelley User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20051013175249.804CB16A454@hub.freebsd.org> <434EB5E6.7020109@kelleycows.com> <434EBB4C.8030609@surfnet.nl> <434EC385.8020100@kelleycows.com> <434EC813.60409@samsco.org> In-Reply-To: <434EC813.60409@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Dekkers , freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 22:25:08 -0000 Scott Long wrote: > Christopher Kelley wrote: > >> Paul Dekkers wrote: >> >>> Hi, >>> >>> Christopher Kelley wrote: >>> >>>> I am having a problem installing 6-RC1, that I am wondering if this >>>> will also fix. It starts to copy from the CD drive, then pretty >>>> quickly I get; >>>> >>>> panic: vm_fault: fault on nofault entry, addr: c641e000 >>>> Uptime: 1m44s >>>> Cannot dump. No dump device defined. >>>> Automatic reboot in 15 seconds - press a key on the console to >>>> abort. >>>> >>>> This is a straight install, I'm not running under VMWare (and I >>>> haven't actually a clue what QEMU is), but I don't know if this is >>>> something that might be related. The addr is different each time. >>>> >>>> This is my "beater" machine, an old P233/mmx with only 96megs, but >>>> I've successfully installed various 5.x versions, windows, etc on >>>> this machine. I've even in the past successfully cvsup'd from 5.4 >>>> to 6, just to see if it would work. >>> >>> >>> >>> >>> FWIW, I just experienced the same with a straight install on a Dell >>> PE 1300, a PIII-500. >>> It was half way through copying the "bin" set. >>> >>> Paul >>> >>> BTW, Probably unrelated: I had to disable apic in order to boot (I'm >>> on the latest BIOS, A12) and ACPI disabled itself. >>> >> Heh, ever get a new idea right after you press "enter" to send a >> message? I *DID* get it to work, by going into the BIOS and >> disabling UDMA access for both master and slave on the secondary IDE >> controller (the CDROM is on the secondary master, nothing on the >> secondary slave). I left the UDMA on for the primary IDE controller >> (where the hard drive is). >> >> So that's weird. Because I didn't have do that to install 5.x or >> Windows 98. I guess it won't affect anything, I don't think CDROMs >> are UDMA anyways. >> >> Christopher >> > > There is a candidate fix for all of these 'panic while copying files off > the CD' problems. I've tested it successfully under Qemu since it > happens most often there and in VMWare, but there is no reason why it > shouldn't also happen on real hardware. So, for those with some to > test, please go to ftp://ftp.freebs.org/pub/FreeBSD/snapshots and > download the ISO there and install it. Then let me know ASAP whether > it helps or not. > > Thanks, > > Scott > > (Sorry Scott, you'll get two copies of this, I forgot to reply all) Yes, success here also, with UDMA set to on for both controllers in my BIOS. Thanks! From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:36:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DF616A41F for ; Thu, 13 Oct 2005 22:36:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D347F43D45 for ; Thu, 13 Oct 2005 22:36:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DMZdR9077910; Thu, 13 Oct 2005 16:35:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 16:36:47 -0600 (MDT) Message-Id: <20051013.163647.106822892.imp@bsdimp.com> To: thierry@herbelot.com From: "M. Warner Losh" In-Reply-To: <200510132251.00632.thierry@herbelot.com> References: <200510131859.03307.thierry@herbelot.com> <20051013.135851.02300147.imp@bsdimp.com> <200510132251.00632.thierry@herbelot.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Oct_13_16:36:47_2005_831)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 16:35:39 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 22:36:11 -0000 ----Next_Part(Thu_Oct_13_16:36:47_2005_831)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In message: <200510132251.00632.thierry@herbelot.com> Thierry Herbelot writes: : Le Thursday 13 October 2005 21:58, M. Warner Losh a =E9crit : : > : > I'll be fixing this in the next day or three and it will be MFC'd f= rom : > head into RC2 when that happens. I'm not sure where the snapshots : > are, but there's a patch floating around to get around the qemu iss= ue : > just posted if you can't wait. I plan on trying it now with RC1. = I : > also plan on looking into the ne2000.c emulation to see why things = are : > failing (eg, is it a flaw in the RTL8029 emulation, or a flaw in if= _ed : > somewhere). : = : Great ! I'll try the patch ASAP I've committed changes to -current to work on patched and unpatched versions of qemu. Here's my patches to qemu to implement the RTL8029 specific registers. Place them in files/patch-hw::ne2000.c of the emulators/qemu port. Warner ----Next_Part(Thu_Oct_13_16:36:47_2005_831)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-hw::ne2000.c" --- hw/ne2000.c~ Thu Oct 13 16:33:39 2005 +++ hw/ne2000.c Thu Oct 13 16:33:47 2005 @@ -47,7 +47,9 @@ #define EN0_CRDAHI 0x09 /* high byte, current remote dma address RD */ #define EN0_RSARHI 0x09 /* Remote start address reg 1 */ #define EN0_RCNTLO 0x0a /* Remote byte count reg WR */ +#define EN0_RTL8029ID0 0x0a /* Realtek ID byte #1 RD */ #define EN0_RCNTHI 0x0b /* Remote byte count reg WR */ +#define EN0_RTL8029ID1 0x0b /* Realtek ID byte #2 RD */ #define EN0_RSR 0x0c /* rx status reg RD */ #define EN0_RXCR 0x0c /* RX configuration reg WR */ #define EN0_TXCR 0x0d /* TX configuration reg WR */ @@ -64,6 +66,11 @@ #define EN2_STARTPG 0x21 /* Starting page of ring bfr RD */ #define EN2_STOPPG 0x22 /* Ending page +1 of ring bfr RD */ +#define EN3_CONFIG0 0x33 +#define EN3_CONFIG1 0x34 +#define EN3_CONFIG2 0x35 +#define EN3_CONFIG3 0x36 + /* Register accessed at EN_CMD, the 8390 base addr. */ #define E8390_STOP 0x01 /* Stop and reset the chip */ #define E8390_START 0x02 /* Start the chip, clear reset */ @@ -385,6 +392,21 @@ case EN2_STOPPG: ret = s->stop >> 8; break; + case EN0_RTL8029ID0: + ret = 0x50; + break; + case EN0_RTL8029ID1: + ret = 0x43; + break; + case EN3_CONFIG0: + ret = 0; /* 10baseT media */ + break; + case EN3_CONFIG2: + ret = 0x40; /* 10baseT active */ + break; + case EN3_CONFIG3: + ret = 0x40; /* Full duplex */ + break; default: ret = 0x00; break; ----Next_Part(Thu_Oct_13_16:36:47_2005_831)---- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 23:00:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8487616A424 for ; Thu, 13 Oct 2005 23:00:27 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41CEA43D5A for ; Thu, 13 Oct 2005 23:00:18 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j9DN0EFI048988; Thu, 13 Oct 2005 16:00:14 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j9DN0EAg048987; Thu, 13 Oct 2005 16:00:14 -0700 (PDT) (envelope-from rizzo) Date: Thu, 13 Oct 2005 16:00:14 -0700 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20051013160014.A48952@xorpc.icir.org> References: <200510131859.03307.thierry@herbelot.com> <20051013.135851.02300147.imp@bsdimp.com> <200510132251.00632.thierry@herbelot.com> <20051013.163647.106822892.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051013.163647.106822892.imp@bsdimp.com>; from imp@bsdimp.com on Thu, Oct 13, 2005 at 04:36:47PM -0600 Cc: freebsd-current@freebsd.org, thierry@herbelot.com Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 23:00:28 -0000 On Thu, Oct 13, 2005 at 04:36:47PM -0600, M. Warner Losh wrote: ... > I've committed changes to -current to work on patched and unpatched > versions of qemu. Here's my patches to qemu to implement the RTL8029 > specific registers. Place them in files/patch-hw::ne2000.c of the > emulators/qemu port. > > Warner > --- hw/ne2000.c~ Thu Oct 13 16:33:39 2005 > +++ hw/ne2000.c Thu Oct 13 16:33:47 2005 probably need to add qemu/ in front of the filename because patch is invoked wiht -p1 ... cheers luigi > @@ -47,7 +47,9 @@ > #define EN0_CRDAHI 0x09 /* high byte, current remote dma address RD */ > #define EN0_RSARHI 0x09 /* Remote start address reg 1 */ > #define EN0_RCNTLO 0x0a /* Remote byte count reg WR */ > +#define EN0_RTL8029ID0 0x0a /* Realtek ID byte #1 RD */ > #define EN0_RCNTHI 0x0b /* Remote byte count reg WR */ > +#define EN0_RTL8029ID1 0x0b /* Realtek ID byte #2 RD */ > #define EN0_RSR 0x0c /* rx status reg RD */ > #define EN0_RXCR 0x0c /* RX configuration reg WR */ > #define EN0_TXCR 0x0d /* TX configuration reg WR */ > @@ -64,6 +66,11 @@ > #define EN2_STARTPG 0x21 /* Starting page of ring bfr RD */ > #define EN2_STOPPG 0x22 /* Ending page +1 of ring bfr RD */ > > +#define EN3_CONFIG0 0x33 > +#define EN3_CONFIG1 0x34 > +#define EN3_CONFIG2 0x35 > +#define EN3_CONFIG3 0x36 > + > /* Register accessed at EN_CMD, the 8390 base addr. */ > #define E8390_STOP 0x01 /* Stop and reset the chip */ > #define E8390_START 0x02 /* Start the chip, clear reset */ > @@ -385,6 +392,21 @@ > case EN2_STOPPG: > ret = s->stop >> 8; > break; > + case EN0_RTL8029ID0: > + ret = 0x50; > + break; > + case EN0_RTL8029ID1: > + ret = 0x43; > + break; > + case EN3_CONFIG0: > + ret = 0; /* 10baseT media */ > + break; > + case EN3_CONFIG2: > + ret = 0x40; /* 10baseT active */ > + break; > + case EN3_CONFIG3: > + ret = 0x40; /* Full duplex */ > + break; > default: > ret = 0x00; > break; > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 23:25:35 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02A3416A41F; Thu, 13 Oct 2005 23:25:35 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D56D543D49; Thu, 13 Oct 2005 23:25:33 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9DNPBif052696; Thu, 13 Oct 2005 16:25:14 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510132325.j9DNPBif052696@gw.catspoiler.org> Date: Thu, 13 Oct 2005 16:25:11 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200510131524.38744.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: mi+mx@aldan.algebra.com, freebsd-current@FreeBSD.org, re@FreeBSD.org, kris@obsecurity.org Subject: Re: 6.0 hangs (while building OOo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 23:25:35 -0000 On 13 Oct, John Baldwin wrote: > On Tuesday 11 October 2005 05:43 am, Don Lewis wrote: >> On 6 Oct, Kris Kennaway wrote: [ snip ] >> >> This problem appears to be some sort of vnode lock leak. >> > >> > leaked lockmgr locks usually panic when the thread exits. >> >> There's a KASSERT to in userret() to catch this in the syscall return >> path, but that check is only enabled if the INVARIANTS kernel option is >> enabled, [ snip ] >> The code referenced by the vnode filename and line members is this block >> in ufs_lookup(): >> >> if (flags & ISDOTDOT) { >> VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ >> error = VFS_VGET(pdp->v_mount, dp->i_ino, >> cnp->cn_lkflags, &tdp); >> --> vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); >> if (error) >> return (error); >> *vpp = tdp; >> } else ... >> >> >> I don't see any obvious lock leaks in the code. > > Looks like the function returns with the desired leaf vnode locked if I > grokked it correctly in my brief perusal, so the bug could be in the caller. I think I might have found *the* bug, but if even if it is not the cause of the lock leak, I did find *a* bug. I just had my latest build hang. It didn't panic in userret(), dmake and another process both deadlocked waiting for vnode locks. Here's the list of locked vnodes: db> show lockedvnod Locked vnodes 0xc44c56cc: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc4a61b58 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc32b2180 (pid 44849) with 1 pendi ng#0 0xc0639d5e at lockmgr+0x566 #1 0xc0690ccd at vop_stdlock+0x21 #2 0xc081744f at VOP_LOCK_APV+0x87 #3 0xc078ac24 at ffs_lock+0x10 #4 0xc081744f at VOP_LOCK_APV+0x87 #5 0xc06a47e4 at vn_lock+0xac #6 0xc0698b52 at vget+0x8e #7 0xc06919e1 at vfs_hash_get+0x8d #8 0xc0789adf at ffs_vget+0x27 #9 0xc0790539 at ufs_lookup+0xab9 #10 0xc08155e3 at VOP_CACHEDLOOKUP_APV+0x9b #11 0xc068eafd at vfs_cache_lookup+0xb5 #12 0xc081550f at VOP_LOOKUP_APV+0x87 #13 0xc0692a9a at lookup+0x3e2 #14 0xc0692456 at namei+0x37e #15 0xc069e922 at kern_access+0x6a #16 0xc069e8b5 at access+0x15 #17 0xc08058df at syscall+0x22f ino 1224704, on dev da0s2a 0xc66fd6cc: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc4a59108 ref 0 pages 2 lock type ufs: EXCL (count 1) by thread 0xc2761480 (pid 44639) with 1 pendi ng#0 0xc0639d5e at lockmgr+0x566 #1 0xc0690ccd at vop_stdlock+0x21 #2 0xc081744f at VOP_LOCK_APV+0x87 #3 0xc078ac24 at ffs_lock+0x10 #4 0xc081744f at VOP_LOCK_APV+0x87 #5 0xc06a47e4 at vn_lock+0xac #6 0xc0698b52 at vget+0x8e #7 0xc06919e1 at vfs_hash_get+0x8d #8 0xc0789adf at ffs_vget+0x27 #9 0xc07904ce at ufs_lookup+0xa4e #10 0xc08155e3 at VOP_CACHEDLOOKUP_APV+0x9b #11 0xc068eafd at vfs_cache_lookup+0xb5 #12 0xc081550f at VOP_LOOKUP_APV+0x87 #13 0xc0692a9a at lookup+0x3e2 #14 0xc0692456 at namei+0x37e #15 0xc069ecd7 at kern_lstat+0x47 #16 0xc069ec73 at lstat+0x1b #17 0xc08058df at syscall+0x22f ino 1224721, on dev da0s2a This is the stack trace for process 44849: (kgdb) where #0 0xc06551b7 in sched_switch (td=0xc32b2180, newtd=0xc2373180, flags=1) at /usr/src/sys/kern/sched_4bsd.c:973 #1 0xc064aa14 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:356 #2 0xc0662100 in sleepq_switch (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:427 #3 0xc06622e4 in sleepq_wait (wchan=0xc66fd724) at /usr/src/sys/kern/subr_sleepqueue.c:539 #4 0xc064a685 in msleep (ident=0xc66fd724, mtx=0xc09477e8, priority=80, wmesg=0xc087909e "ufs", timo=0) at /usr/src/sys/kern/kern_synch.c:227 #5 0xc0639759 in acquire (lkpp=0xeb6818d8, extflags=64, wanted=393216) at /usr/src/sys/kern/kern_lock.c:115 #6 0xc0639cba in lockmgr (lkp=0xc66fd724, flags=8194, interlkp=0x40, td=0xc32b2180) at /usr/src/sys/kern/kern_lock.c:340 #7 0xc0690ccd in vop_stdlock (ap=0x0) at /usr/src/sys/kern/vfs_default.c:263 #8 0xc081744f in VOP_LOCK_APV (vop=0xc08e0420, a=0xeb681940) at vnode_if.c:1642 #9 0xc078ac24 in ffs_lock (ap=0xeb681940) at /usr/src/sys/ufs/ffs/ffs_vnops.c:341 #10 0xc081744f in VOP_LOCK_APV (vop=0xc0912ce0, a=0xeb681940) at vnode_if.c:1642 #11 0xc06a47e4 in vn_lock (vp=0xc66fd6cc, flags=8194, td=0xc32b2180) at vnode_if.h:844 ---Type to continue, or q to quit--- #12 0xc0698b52 in vget (vp=0xc66fd6cc, flags=8194, td=0xc32b2180) at /usr/src/sys/kern/vfs_subr.c:1953 #13 0xc06919e1 in vfs_hash_get (mp=0xc25af800, hash=1224721, flags=2, td=0xc32b2180, vpp=0xeb681a94, fn=0, arg=0x0) at /usr/src/sys/kern/vfs_hash.c:81 #14 0xc0789adf in ffs_vget (mp=0xc25af800, ino=1224721, flags=2, vpp=0xeb681a94) at pcpu.h:162 #15 0xc0790539 in ufs_lookup (ap=0xeb681b3c) at /usr/src/sys/ufs/ufs/ufs_lookup.c:571 #16 0xc08155e3 in VOP_CACHEDLOOKUP_APV (vop=0xc0913220, a=0xeb681b3c) at vnode_if.c:150 #17 0xc068eafd in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 #18 0xc081550f in VOP_LOOKUP_APV (vop=0xc0913220, a=0xeb681bd4) at vnode_if.c:99 #19 0xc0692a9a in lookup (ndp=0xeb681c68) at vnode_if.h:56 #20 0xc0692456 in namei (ndp=0xeb681c68) at /usr/src/sys/kern/vfs_lookup.c:203 #21 0xc069e922 in kern_access (td=0xc32b2180, path=0x0, pathseg=UIO_USERSPACE, flags=0) at /usr/src/sys/kern/vfs_syscalls.c:1879 #22 0xc069e8b5 in access (td=0xc32b2180, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:1856 #23 0xc08058df in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 65, tf_esi = 1208418304, tf_ ebp = -1077950920, tf_isp = -345498268, tf_ebx = 1208382424, tf_edx = 134513381, ---Type to continue, or q to quit--- tf_ecx = 1208418370, tf_eax = 33, tf_trapno = 12, tf_err = 2, tf_eip = 12082991 75, tf_cs = 51, tf_eflags = 582, tf_esp = -1077950964, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:976 #24 0xc07f7bdf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #25 0x00000033 in ?? () Frame 15 and some of its variables might be interesting: (kgdb) frame 15 #15 0xc0790539 in ufs_lookup (ap=0xeb681b3c) at /usr/src/sys/ufs/ufs/ufs_lookup.c:571 571 error = VFS_VGET(pdp->v_mount, dp->i_ino, (kgdb) print /x flags $2 = 0x1000044 LOCKLEAF | FOLLOW | MPSAFE (kgdb) print *cnp $2 = {cn_nameiop = 0, cn_flags = 16777284, cn_thread = 0xc32b2180, cn_cred = 0xc3655000, cn_lkflags = 2, cn_pnbuf = 0xc25ed400 "/mnt/ports/editors/openoffice.org-2.0/work/solenv/unxfb sd.pro/lib/libc.so.6", cn_nameptr = 0xc25ed40b "editors/openoffice.org-2.0/work/solenv/unxfbsd.pro/li b/libc.so.6", cn_namelen = 7, cn_consume = 0} Process 44639 is dmake, and this is where things really start to get interesting: (kgdb) thread 99 [Switching to thread 99 (Thread 100082)]#0 0xc06551b7 in sched_switch ( td=0xc2761480, newtd=0xc32b2180, flags=1) at /usr/src/sys/kern/sched_4bsd.c:973 973 cpu_switch(td, newtd); (kgdb) where #0 0xc06551b7 in sched_switch (td=0xc2761480, newtd=0xc32b2180, flags=1) at /usr/src/sys/kern/sched_4bsd.c:973 #1 0xc064aa14 in mi_switch (flags=1, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:356 #2 0xc0662100 in sleepq_switch (wchan=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:427 #3 0xc06622e4 in sleepq_wait (wchan=0xc44c5724) at /usr/src/sys/kern/subr_sleepqueue.c:539 #4 0xc064a685 in msleep (ident=0xc44c5724, mtx=0xc09477c4, priority=80, wmesg=0xc087909e "ufs", timo=0) at /usr/src/sys/kern/kern_synch.c:227 #5 0xc0639759 in acquire (lkpp=0xeb5b08f0, extflags=64, wanted=393216) at /usr/src/sys/kern/kern_lock.c:115 #6 0xc0639cba in lockmgr (lkp=0xc44c5724, flags=12290, interlkp=0x40, td=0xc2761480) at /usr/src/sys/kern/kern_lock.c:340 #7 0xc0690ccd in vop_stdlock (ap=0x0) at /usr/src/sys/kern/vfs_default.c:263 #8 0xc081744f in VOP_LOCK_APV (vop=0xc08e0420, a=0xeb5b0958) at vnode_if.c:1642 #9 0xc078ac24 in ffs_lock (ap=0xeb5b0958) at /usr/src/sys/ufs/ffs/ffs_vnops.c:341 #10 0xc081744f in VOP_LOCK_APV (vop=0xc0912ce0, a=0xeb5b0958) at vnode_if.c:1642 #11 0xc06a47e4 in vn_lock (vp=0xc44c56cc, flags=4098, td=0xc2761480) at vnode_if.h:844 ---Type to continue, or q to quit--- #12 0xc07904e3 in ufs_lookup (ap=0xeb5b0a7c) at /usr/src/sys/ufs/ufs/ufs_lookup.c:563 #13 0xc08155e3 in VOP_CACHEDLOOKUP_APV (vop=0xc0913220, a=0xeb5b0a7c) at vnode_if.c:150 #14 0xc068eafd in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 #15 0xc081550f in VOP_LOOKUP_APV (vop=0xc0913220, a=0xeb5b0b14) at vnode_if.c:99 #16 0xc0692a9a in lookup (ndp=0xeb5b0ba0) at vnode_if.h:56 #17 0xc0692456 in namei (ndp=0xeb5b0ba0) at /usr/src/sys/kern/vfs_lookup.c:203 #18 0xc069ecd7 in kern_lstat (td=0xc2761480, path=0x0, pathseg=UIO_USERSPACE, sbp=0xeb5b0c74) at /usr/src/sys/kern/vfs_syscalls.c:2102 #19 0xc069ec73 in lstat (td=0xc2761480, uap=0xeb5b0d04) at /usr/src/sys/kern/vfs_syscalls.c:2086 #20 0xc08058df in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134600610, tf_esi = 13473007 6, tf_ebp = -1077951800, tf_isp = -346354332, tf_ebx = 1209300040, tf_edx = 0, t f_ecx = 0, tf_eax = 190, tf_trapno = 12, tf_err = 2, tf_eip = 1209192707, tf_cs = 51, tf_eflags = 658, tf_esp = -1077952004, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:976 #21 0xc07f7bdf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #22 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 12 #12 0xc07904e3 in ufs_lookup (ap=0xeb5b0a7c) at /usr/src/sys/ufs/ufs/ufs_lookup.c:563 563 vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); (kgdb) print /x flags $3 = 0x100a004 LOCKLEAF | ISDOTDOT | ISLASTCN | MPSAFE (kgdb) print *cnp $1 = {cn_nameiop = 0, cn_flags = 16818180, cn_thread = 0xc2761480, cn_cred = 0xc2912680, cn_lkflags = 2, cn_pnbuf = 0xc25ed000 "../../../../../..", cn_nameptr = 0xc25ed00f "..", cn_namelen = 2, cn_consume = 0} Process 44849 has directory vnode 0xc44c56cc / inode 1224704 locked and is trying to lock vnode 0xc66fd6cc, and dmake (process 44639) has directory vnode 0xc66fd6cc / inode 1224721 locked and is trying to lock vnode 0xc44c56cc, hence the deadlock. But this isn't supposed to happen because ufs only locks directories starting from the root when doing lookups, and takes special care to get the lock order right when doing a lookup on "..". This is where things really get interesting. The dmake process is doing a ".." lookup and is calling vn_lock() here: (kgdb) frame 12 #12 0xc07904e3 in ufs_lookup (ap=0xeb5b0a7c) at /usr/src/sys/ufs/ufs/ufs_lookup.c:563 563 vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); (kgdb) list 558 pdp = vdp; 559 if (flags & ISDOTDOT) { 560 VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ 561 error = VFS_VGET(pdp->v_mount, dp->i_ino, 562 cnp->cn_lkflags, &tdp); 563 vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); 564 if (error) 565 return (error); 566 *vpp = tdp; 567 } else if (dp->i_number == dp->i_ino) { It has unlocked the current directory in the path, it has called VFS_VGET() to lock the ".." directory (inode 1224721), and is attempted to relock the current directory, which is a child of the ".." directory. But, if we peek at the directory that dmake has locked ... fsdb -r /dev/da0s2a ** /dev/da0s2a (NO WRITE) Examining file system `/dev/da0s2a' Last Mounted on /mnt current inode: directory I=2 MODE=40755 SIZE=512 MTIME=Oct 11 02:10:20 2005 [0 nsec] CTIME=Oct 11 02:10:20 2005 [0 nsec] ATIME=Oct 13 12:16:02 2005 [0 nsec] OWNER=root GRP=wheel LINKCNT=8 FLAGS=0 BLKCNT=4 GEN=53557245 fsdb (inum: 2)> inode 1224721 current inode: directory I=1224721 MODE=40755 SIZE=4608 MTIME=Oct 5 17:56:57 2005 [0 nsec] CTIME=Oct 11 02:39:39 2005 [0 nsec] ATIME=Oct 13 12:16:02 2005 [0 nsec] OWNER=root GRP=wheel LINKCNT=233 FLAGS=0 BLKCNT=c GEN=33427862 fsdb (inum: 1224721)> ls slot 0 ino 1224721 reclen 12: directory, `.' slot 1 ino 1224704 reclen 12: directory, `..' slot 2 ino 125495 reclen 12: directory, `CVS' slot 3 ino 125496 reclen 16: directory, `tpad' [snip] it looks like we are trying to lock the parent of the directory that we have locked! The bug is that once we have unlocked pdp, another thread can do a lookup and overwrite dp->i_ino, so instead of getting the vnode for the ".." directory entry, VFS_VGET() will return the vnode for a subdirectory of the current directory, and when we relock the current directory we'll have a lock order reversal. Even if this doesn't result in a deadlock, it looks like it has the potential for mucking up lookups that involve "..". I also don't currently see a way for this to become a vnode lock leak. The fix is to preserve a copy of dp->d_ino before unlocking pdp, and pass the saved value to VFS_VGET(). Index: sys/ufs/ufs/ufs_lookup.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_lookup.c,v retrieving revision 1.77 diff -u -r1.77 ufs_lookup.c --- sys/ufs/ufs/ufs_lookup.c 13 Apr 2005 10:59:09 -0000 1.77 +++ sys/ufs/ufs/ufs_lookup.c 13 Oct 2005 23:20:59 -0000 @@ -153,6 +153,7 @@ int flags = cnp->cn_flags; int nameiop = cnp->cn_nameiop; struct thread *td = cnp->cn_thread; + u_int32_t saved_ino; bp = NULL; slotoffset = -1; @@ -557,8 +558,9 @@ */ pdp = vdp; if (flags & ISDOTDOT) { + saved_ino = dp->i_ino; VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ - error = VFS_VGET(pdp->v_mount, dp->i_ino, + error = VFS_VGET(pdp->v_mount, saved_ino, cnp->cn_lkflags, &tdp); vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); if (error) From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 23:27:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7243D16A41F; Thu, 13 Oct 2005 23:27:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C7543D64; Thu, 13 Oct 2005 23:27:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DNPkS0078315; Thu, 13 Oct 2005 17:25:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 17:26:55 -0600 (MDT) Message-Id: <20051013.172655.102656323.imp@bsdimp.com> To: nox@jelal.kn-bremen.de From: "M. Warner Losh" In-Reply-To: <20051013200254.GA11267@saturn.kn-bremen.de> References: <200510131210.55135.jkim@FreeBSD.org> <200510131428.21211.jkim@FreeBSD.org> <20051013200254.GA11267@saturn.kn-bremen.de> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 17:25:52 -0600 (MDT) Cc: jcoombs@gwi.net, thierry@herbelot.com, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, bakul@BitBlocks.com, jkim@freebsd.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 23:27:45 -0000 In message: <20051013200254.GA11267@saturn.kn-bremen.de> Juergen Lock writes: : On Thu, Oct 13, 2005 at 02:28:18PM -0400, Jung-uk Kim wrote: : > On Thursday 13 October 2005 12:10 pm, Jung-uk Kim wrote: : > > QEMU emulates RTL8029: : > > : > > ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 : > > ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 : > > : > > and Warner Losh MFC'd new ed(4) right before 6.0-RC1: : > > : > > http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 : > > : > > The new driver does more aggressive probing and it seems QEMU : > > cannot handle it. : > : > Just for the time being, you can drop the attachment in : > ports/emulators/qemu/files directory and rebuild qemu to get ed(4) : > back. : > : > Jung-uk Kim : : >[patch snipped] : : Okay, we could add this as an option to our qemu port (`-ne2kvia' or : something like that), anyone thinks it is necessary? (I guess this : issue will be fixed in 6.0-R?) I've committed patches to -current to fix this problem. The fixes correct a minor botch in the probing code, while also adding tolerance for the RTL8029 that's claimed to be there to not really be there. I've posted patches to qemu that improves that RTL8029 emulation, but those aren't required for FreeBSD to work. RC1 won't work with qemu, patched or unpatched, due to the minor botch. RC2 and newer will have this problem fixed. The qemu folks can include and improve upon my patches as they see fit in the future. The problem with just switching to the VIA VT86C926 is that it isn't exactly like a NE-2000. According to its datasheet: >>7. CONTROL AND STATUS REGISTERS >>VT86C926 supports the control and status registers of DP8390 except >>those explained as follows. >> >> * VT86C926 supports all page 1 registers. Only part of Page 2 is >> supported. >> * VT86C926 supports Early Transmit Underrun (ETUN) >> * VT86C926 supports most of page 0 registers. >> * The meaning and use of 01H (CLAD0) and 02H (CLAD1) of page 0 is >> altered. >> * The 06H (FIFO port) of page 0 is not supported. >> * The following control/status bits in page 0 are not supported: >> -- (D3,D4,D5) == (0,1,1) of CR (00H) : Send Packet Command (RD0 - RD2) >> -- D1 of DCR: Byte Order Select (BOS) >> -- D2 of DCR: Long Address Select (LAS) >> -- D4 of DCR: Auto-initialize Remote (ARM) >> -- D5, D6 of DCR: FIFO Threshold Select (FT0 and FT1) >> -- D4 of TCR: Collision Offset Enable (OFST) >> -- D5 of TSR: FIFO Underrun (FU) >> -- D7 of TSR: Out of Window Collision (OWC) >> -- D3 of RSR: FIFO Overrun (FO) None of which are enshrined in hw/ne2000.c as far as I can tell. The early interrupt stuff isn't part of a NE2000 at all (that's the ETUN). Of course its datasheet is maddening. It talks about different bits and registers, but never defines their offsets or values! Warner From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 23:37:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2E5D16A41F for ; Thu, 13 Oct 2005 23:37:00 +0000 (GMT) (envelope-from emoe@cox.net) Received: from centrmmtao06.cox.net (centrmmtao06.cox.net [70.168.83.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6966143D46 for ; Thu, 13 Oct 2005 23:37:00 +0000 (GMT) (envelope-from emoe@cox.net) Received: from [192.168.10.5] (really [68.97.44.169]) by centrmmtao06.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051013233637.QMGA24602.centrmmtao06.cox.net@[192.168.10.5]> for ; Thu, 13 Oct 2005 19:36:37 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <119079C9-0A1D-4BFF-81B1-4D063C335CC5@cox.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Erik Moe Date: Thu, 13 Oct 2005 18:36:56 -0500 X-Mailer: Apple Mail (2.734) Subject: Kernel panic: "spec nodes went here" in 6.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: Thu, 13 Oct 2005 23:37:00 -0000 This may be a known issue, but I haven't found much discussion on it. I'm playing with 6.0-RC1 and the kernel test suite. Within minutes of running the suite I get a kernel panic: "spec nodes went here". This seems to happen consistently. The panic happens in ffsext_strategy(), but it looks like the arguments to the mkdir() system call are missing. [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: panic: spec nodes went here Uptime: 56m52s Dumping 254 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 255MB (65088 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0637806 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:399 #2 0xc0637a9c in panic (fmt=0xc0879536 "spec nodes went here") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc0788988 in ffsext_strategy (ap=0xd16d39c0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:1245 #4 0xc0816c79 in VOP_STRATEGY_APV (vop=0xc08fab60, a=0xd16d39c0) at vnode_if.c:1796 #5 0xc06813fc in bufstrategy (bo=0xc1fa01d0, bp=0x0) at vnode_if.h:928 #6 0xc067bfc4 in bufwrite (bp=0xc6650b60) at buf.h:415 #7 0xc0791bc9 in ufs_mkdir (ap=0xd16d3bb8) at buf.h:399 #8 0xc0816840 in VOP_MKDIR_APV (vop=0x0, a=0xd16d3bb8) at vnode_if.c: 1251 #9 0xc0695c05 in kern_mkdir (td=0xc2889a80, path=0xbfbfac90
, segflg=UIO_USERSPACE, mode=504) at vnode_if.h:653 #10 0xc06958e9 in mkdir (td=0xc2889a80, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:3301 #11 0xc0807177 in syscall (frame= {tf_fs = 671416379, tf_es = -1078001605, tf_ds = -1078198213, tf_edi = 671416968, tf_esi = -1077941124, tf_ebp = -1077957512, tf_isp = -781370012, tf_ebx = 1, tf_edx = -1077957485, tf_ecx = 0, tf_eax = 136, tf_trapno = 12, tf_err = 2, tf_eip = 671841683, tf_cs = 51, tf_eflags = 658, tf_esp = -1077958580, tf_ss = 59}) at /usr/src/ sys/i386/i386/trap.c:976 #12 0xc07f605f in Xint0x80_syscall () at /usr/src/sys/i386/i386/ exception.s:200 ---Type to continue, or q to quit--- #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 3 #3 0xc0788988 in ffsext_strategy (ap=0xd16d39c0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:1245 1245 panic("spec nodes went here"); (kgdb) l 1240 if (VTOI(vp)->i_fs->fs_magic == FS_UFS2_MAGIC && 1241 lbn < 0 && lbn >= -NXADDR) 1242 return (VOP_STRATEGY_APV(&ufs_vnodeops, ap)); 1243 if (vp->v_type == VFIFO) 1244 return (VOP_STRATEGY_APV(&ufs_fifoops, ap)); 1245 panic("spec nodes went here"); 1246 } 1247 1248 /* 1249 * Vnode extattr transaction commit/abort (kgdb) p *vp $1 = {v_type = VDIR, v_tag = 0xc086a45a "ufs", v_op = 0xc08fab60, v_data = 0xc2446bdc, v_mount = 0xc16f7000, v_nmntvnodes = { tqe_next = 0xc1abb440, tqe_prev = 0xc1f08124}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { le_next = 0xc253abb0, le_prev = 0xc16a4f9c}, v_hash = 2873446, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xc1fa0140}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xc0920340, lk_flags = 262208, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc086a45a "ufs", lk_timo = 51, lk_lockholder = 0xc2889a80, lk_newlock = 0x0}, v_interlock = {mtx_object = {lo_class = 0xc08c19c4, lo_name = 0xc086b7bb "vnode interlock", lo_type = 0xc086b7bb "vnode interlock", lo_flags = 196608, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc1fa0168, v_holdcnt = 2, v_usecount = 1, v_iflag = 0, v_vflag = 4, v_writecount = 0, v_freelist = { tqe_next = 0xc2450660, tqe_prev = 0xc1f654f8}, v_bufobj = { bo_mtx = 0xc1fa018c, bo_clean = {bv_hd = {tqh_first = 0xc6650b60, tqh_last = 0xc6650b98}, bv_root = 0xc6650b60, bv_cnt = 1}, bo_dirty = { bv_hd = {tqh_first = 0x0, tqh_last = 0xc1fa01e4}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 1, bo_flag = 0, bo_ops = 0xc08c7864, bo_bsize = 16384, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xc1fa0110, __bo_vnode = 0xc1fa0110}, ---Type to continue, or q to quit--- v_pollinfo = 0x0, v_label = 0x0} (kgdb) Erik Moe emoe@cox.net From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 23:39:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B863916A41F for ; Thu, 13 Oct 2005 23:39:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 599A443D46 for ; Thu, 13 Oct 2005 23:39:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9DNbX3K078401; Thu, 13 Oct 2005 17:37:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 17:38:42 -0600 (MDT) Message-Id: <20051013.173842.67102047.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20051013160014.A48952@xorpc.icir.org> References: <200510132251.00632.thierry@herbelot.com> <20051013.163647.106822892.imp@bsdimp.com> <20051013160014.A48952@xorpc.icir.org> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 17:37:34 -0600 (MDT) Cc: freebsd-current@freebsd.org, thierry@herbelot.com Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 23:39:05 -0000 In message: <20051013160014.A48952@xorpc.icir.org> Luigi Rizzo writes: : On Thu, Oct 13, 2005 at 04:36:47PM -0600, M. Warner Losh wrote: : ... : > I've committed changes to -current to work on patched and unpatched : > versions of qemu. Here's my patches to qemu to implement the RTL8029 : > specific registers. Place them in files/patch-hw::ne2000.c of the : > emulators/qemu port. : > : > Warner : : > --- hw/ne2000.c~ Thu Oct 13 16:33:39 2005 : > +++ hw/ne2000.c Thu Oct 13 16:33:47 2005 : probably need to add qemu/ in front of the filename because : patch is invoked wiht -p1 ... Thanks! Warner From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 00:10:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A4C116A41F; Fri, 14 Oct 2005 00:10:40 +0000 (GMT) (envelope-from grog@lemis.com) Received: from ext-gw.lemis.com (ext-gw.lemis.com [150.101.14.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52CC343D46; Fri, 14 Oct 2005 00:10:39 +0000 (GMT) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by ext-gw.lemis.com (Postfix) with ESMTP id 37E09131D5D; Fri, 14 Oct 2005 09:40:38 +0930 (CST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 18EA484815; Fri, 14 Oct 2005 09:40:38 +0930 (CST) Date: Fri, 14 Oct 2005 09:40:38 +0930 From: Greg 'groggy' Lehey To: Stefan Cars Message-ID: <20051014001038.GX49168@wantadilla.lemis.com> References: <434CBAD5.10306@snowfall.se> <20051013010014.GG49168@wantadilla.lemis.com> <434E839B.2020209@snowfall.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OxWh+UR3R7TveXYN" Content-Disposition: inline In-Reply-To: <434E839B.2020209@snowfall.se> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: questions@freebsd.org, current@freebsd.org Subject: MySQL crashes on amd64 (was: Moving down from amd64 to i386 ??) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 00:10:40 -0000 --OxWh+UR3R7TveXYN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Sequence recovered--see http://www.lemis.com/email/email-format.html] On Thursday, 13 October 2005 at 17:56:11 +0200, Stefan Cars wrote: > Greg 'groggy' Lehey wrote: >> On Wednesday, 12 October 2005 at 9:27:17 +0200, Stefan Cars wrote: >> >>> Hi! >>> >>> We are having troubles with MySQL 4.1 on a amd64 (it's crashing >>> randomly with Seg fault, signal 11. gdb bt says: Cannot access >>> memory at address 0x800000000000). We have got information saying >>> this is a 64bit related issue and should be fixed by using the i386 >>> version instead of amd64 (this is an Intel Xeon). >> >> Where did you get that information from? I'd still like to know an answer to this question. >>> What is the way to go when moving from amd64 to i386 ? >> >> If you mean "how do I install an i386 kernel on this machine", I can't >> think of any way except to start from scratch. It would be a good >> idea to install a separate disk, so you can access the configuration >> files and the database on the old disk. But before doing this, I'd be >> very interested in knowing what the problem is. Is the backtrace >> always the same? Where does it crash? > > After doing some testing this is what I found out: > > 1) Exchanging memory on the machine did not work. Same error. > 2) Trying it on another 64 bit machine with same FreeBSD (RC1) creates > EXACT same problem > 3) Installing the i386 version of RC1 instead of amd64 on the same > machines and it works terrific. No crash. Hmm. That's interesting. This is obviously not a hardware issue. > The bt is always the same and it always crash the same, look here: > > #784 0x0000000000000000 in ?? () > #785 0x247c8d48002454ff in ?? () > #786 0x01a1c0c748006a10 in ?? () > #787 0x66fdebf4050f0000 in ?? () > #788 0x9066669066669066 in ?? () > #789 0x00007fffffffe778 in ?? () > #790 0x0000000000000006 in ?? () > #791 0x00007fffffffe7b0 in ?? () > #792 0x0000000000000017 in ?? () > Cannot access memory at address 0x800000000000 Without function names instead of ??, it's impossible to say what's happening here. You'd need to build with debug symbols. Since you've been told that this is an issue, it would be good to know more. As we've mentioned on other threads, there are reasons to believe that there are problems with the threading libraries, but currently we don't have enough information to investigate them. Note that the other recent thread refers to problems running in the configuration you have just installed: see http://bugs.mysql.com/bug.php?id=12251 for more details. If you see anything similar, please let us know. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers. --OxWh+UR3R7TveXYN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDTvd+IubykFB6QiMRAvfCAKCJykA1ckKvHtt8pCWvlR5cxcvppACgqshU is5g2J0/J/E2RU5GlB29nXo= =THjG -----END PGP SIGNATURE----- --OxWh+UR3R7TveXYN-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 00:13:43 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97E9C16A41F for ; Fri, 14 Oct 2005 00:13:43 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3840D43D49 for ; Fri, 14 Oct 2005 00:13:43 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9E0DVNu052772; Thu, 13 Oct 2005 17:13:35 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510140013.j9E0DVNu052772@gw.catspoiler.org> Date: Thu, 13 Oct 2005 17:13:31 -0700 (PDT) From: Don Lewis To: emoe@cox.net In-Reply-To: <119079C9-0A1D-4BFF-81B1-4D063C335CC5@cox.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: Kernel panic: "spec nodes went here" in 6.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: Fri, 14 Oct 2005 00:13:43 -0000 On 13 Oct, Erik Moe wrote: > This may be a known issue, but I haven't found much discussion on > it. I'm playing with 6.0-RC1 and the kernel test suite. Within > minutes of running the suite I get a kernel panic: "spec nodes went > here". This seems to happen consistently. The panic happens in > ffsext_strategy(), but it looks like the arguments to the mkdir() > system call are missing. This was fixed in HEAD with sys/ufs/ffs/ffs_alloc.c 1.136. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 03:35:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795FC16A41F for ; Fri, 14 Oct 2005 03:35:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1936643D46 for ; Fri, 14 Oct 2005 03:35:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9E3ZB5r080199; Thu, 13 Oct 2005 21:35:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 21:36:21 -0600 (MDT) Message-Id: <20051013.213621.35849592.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200510132028.32070.doconnor@gsoft.com.au> References: <200510132028.32070.doconnor@gsoft.com.au> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 21:35:14 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Patches for ports to install KLD source X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 03:35:59 -0000 In message: <200510132028.32070.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : Here is a sent of patches for 2 ports (x11/nvidia-server and palm/uppc-kmod) : that have them install the KLD source and gets the KLD's rebuilt with the : kernel. : : Apply the attached patches and do.. : mkdir /usr/local/kld /usr/X11R6/kld : : Then copy the attached Makefile to /usr/local/kld and /usr/X11R6/kld. : : Unfortunately I don't know a nice way of discovering PREFIX and/or X11BASE : except, say.. : make -f /usr/ports/Mk/bsd.port.mk -V PREFIX : make -f /usr/ports/Mk/bsd.port.mk -V X11BASE : : which seems a bit gross.. : : For the nvidia port - I've only tried it on -current so I don't know if it : will work OK with the other versions it installs on different : systems/configurations. How is this different than setting PORTS_MODULES in your kernel config file? Warner From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 03:38:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2593816A41F for ; Fri, 14 Oct 2005 03:38:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB1D243D45 for ; Fri, 14 Oct 2005 03:38:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9E3cXk9080217; Thu, 13 Oct 2005 21:38:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 21:39:43 -0600 (MDT) Message-Id: <20051013.213943.05622321.imp@bsdimp.com> To: freebsd@psam.se From: "M. Warner Losh" In-Reply-To: <434E538F.80000@psam.se> References: <434E538F.80000@psam.se> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 21:38:33 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Thoshiba Tecra 8000 with 3com 3CXFE575CT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 03:38:59 -0000 In message: <434E538F.80000@psam.se> Psadi writes: : I had decided to try FreeBSD 6.0 on my laptop. After I installed it : beta4 I recived alot of xl0: watchdog timeout every time I try to use : the internet. Interrupts aren't being routed correctly. You need to fix that. There's a tiny chance it is in your hardware setup, but since prior versions work, I'd guess this is the case. You'll need to save the dmesg from 6.0 and from 5.4 and compare the too. Sadly, the Tecra 8000 moniker was used by a lot of different laptops. Mine just works w/o any issues. : At startup I see that I get CARDBUS1: Resource not specified in CIS: : id=14, size=80 Ignore these. Generally they are just noise. : I added in pccard.conf that it should use IRQ 3,5,10,15 though when I : look it still uses 11 pccard.conf is completely ignored. : What else can I try or do to get more info for those that needs it? Put the laptop in my hands, and I'll fix it :-). Otherwise, we'll have to start with boot -v dmesgs from working and broken systems. Warner From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 03:41:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CCD216A41F for ; Fri, 14 Oct 2005 03:41:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2D7543D45 for ; Fri, 14 Oct 2005 03:41:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9E3evgW080243; Thu, 13 Oct 2005 21:41:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 13 Oct 2005 21:42:07 -0600 (MDT) Message-Id: <20051013.214207.05880708.imp@bsdimp.com> To: jcoombs@gwi.net From: "M. Warner Losh" In-Reply-To: References: <200510131331.27906.thierry@herbelot.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 13 Oct 2005 21:41:01 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 03:41:59 -0000 In message: "Joshua Coombs" writes: : Welp, while I have no real help, I can point out this was reported by : another user on the stable list, QEMU + RC1 == no ed I've committed the changes to -current and asked for permission to MFC. I've installed qemu (cool little utility that) and have done extensive testing with it. There are multiple issues that this uncovers. Some are in qemu and some in if_ed. I've generated patches for qemu that makes it better (support the RTL8029 specific registers better) and sent them off to the qemu list. Warner From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 04:52:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2AD16A41F for ; Fri, 14 Oct 2005 04:52:44 +0000 (GMT) (envelope-from current@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CC1743D45 for ; Fri, 14 Oct 2005 04:52:43 +0000 (GMT) (envelope-from current@dino.sk) Received: from home.dino.sk ([213.215.74.194]) (AUTH: PLAIN milan, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by bsd.dino.sk with esmtp; Fri, 14 Oct 2005 06:52:47 +0200 id 0000006D.434F39A0.00009C60 From: Milan Obuch To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 06:51:53 +0200 User-Agent: KMail/1.8.2 References: <200510061321.35170.current@dino.sk> <200510131551.46397.jhb@freebsd.org> In-Reply-To: <200510131551.46397.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510140652.01440.current@dino.sk> Subject: Re: pcf module 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, 14 Oct 2005 04:52:45 -0000 On Thursday 13 October 2005 21:51, John Baldwin wrote: > On Thursday 06 October 2005 07:21 am, Milan Obuch wrote: =2E.. > > Then I checked pcf module and found the same behavior. If you have no > > 'device iicbus' in kernel configuration, issuing 'kldload pcf' gives > > link_elf: symbol iicbus_intr undefined > > kldload: can't load pcf: No such file or directory. > > > > Adding 'device iibus' into kernel configuration and rebuilding kernel > > fixes this, so it looks like symbol is just not exported. > > =2E.. > > > > Anyway, is anybody out there using pcf? There is some work done in this > > area, but not yet linked into main tree. I have not pcf hardware, so I > > can not test anything in this area, but it would be good to make the > > transition from older i386/isa/pcf.c to new dev/pcf/... > > Sounds like it is missing a 'MODULE_DEPEND(iicbus, 1, 1, 1);' line. =A0Can > you try adding one and seeing if it fixes the kldload of pcf? Bingo! Actually, it is 'MODULE_DEPEND(pcf_isa, iicbus, 1, 1, 1);', at least with=20 6.0-RC1, after looking elsewhere I added 'MODULE_VERSION(pcf_isa, 1);' as=20 well. Those ones are not written literally at other places, but nevertheles= s,=20 this works. Still, transition from 'sys/i386/isa/pcf.c' to '/sys/dev/pcf/*' solves this= =20 isue as well, because there it is already fixed. With Makefile changed to =2EPATH: =A0 =A0 =A0 =A0 =A0${.CURDIR}/../../../../dev/pcf KMOD =A0 =A0 =A0 =A0 =A0 =A0=3D pcf SRCS =A0 =A0 =A0 =A0 =A0 =A0=3D device_if.h bus_if.h iicbus_if.h isa_if.h \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pcf.c pcf_isa.c =2Einclude it just works. I changed directly Makefile=20 in /sr/src/sys/modules/i2c/controllers/pcf, just for test, so maybe this is= =20 not enough, however, it works. So, the question remains - is anybody out there using pcf devices to confir= m=20 this really works? For me it compiles and kldloads, but I have no real devi= ce=20 to test real functionality. And the other question - is anybody out there using i2c devices at all? If = so,=20 I would like to hear about their experiences. This area seems to be not=20 covered anywhere. Googling for 'freebsd i2c' and similar does not reveal=20 anything interesting for me... Milan From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 05:14:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B58A116A41F for ; Fri, 14 Oct 2005 05:14:45 +0000 (GMT) (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 1856D43D45 for ; Fri, 14 Oct 2005 05:14:44 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9E5EPUL039033 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 14 Oct 2005 14:44:26 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "M. Warner Losh" Date: Fri, 14 Oct 2005 14:44:12 +0930 User-Agent: KMail/1.8.2 References: <200510132028.32070.doconnor@gsoft.com.au> <20051013.213621.35849592.imp@bsdimp.com> In-Reply-To: <20051013.213621.35849592.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9490620.V9p8xV8rE6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510141444.21457.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: Patches for ports to install KLD source X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 05:14:45 -0000 --nextPart9490620.V9p8xV8rE6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 14 Oct 2005 13:06, M. Warner Losh wrote: > : For the nvidia port - I've only tried it on -current so I don't know if > : it will work OK with the other versions it installs on different > : systems/configurations. > > How is this different than setting PORTS_MODULES in your kernel config > file? PORTS_MODULES will upgrade your port if your ports tree is updated, this ca= n=20 be a nasty suprise. nvidia-driver 6113 used to be the latest version of the= =20 port that would work on my laptop and an automatic upgrade would have been= =20 very frustrating - ie I think it's a POLA violation. It makes building your kernel slower - it installs everything related to th= e=20 port instead of just rebuilding the KLD. For most people this probably isn'= t=20 a big issue but it's a drag when you are testing new kernels. It also seems a bit less of a "big hammer" approach to the problem :) =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 --nextPart9490620.V9p8xV8rE6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDTz6t5ZPcIHs/zowRAu6RAJ9XLptg3GorD/ADQdG9VAyJwURdcgCfWarv jwu7PKjlfL3nfF3rXLFlpt0= =dnur -----END PGP SIGNATURE----- --nextPart9490620.V9p8xV8rE6-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 05:55:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7447C16A41F for ; Fri, 14 Oct 2005 05:55:03 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B47443D6A for ; Fri, 14 Oct 2005 05:55:01 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from [127.0.0.1] (c220-237-120-88.thorn1.nsw.optusnet.com.au [220.237.120.88]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9E5st1I000738; Fri, 14 Oct 2005 15:54:56 +1000 Message-ID: <434F4846.4020101@mawer.org> Date: Fri, 14 Oct 2005 15:55:18 +1000 From: Antony Mawer User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kientzle@acm.org Subject: make installworld fails on -CURRENT from 13 Oct 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 05:55:03 -0000 It looks as though there's a problem with the recent libarchive checkin here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libarchive/Makefile?rev=1.40&content-type=text/x-cvsweb-markup When trying to upgrade a 6.0-RC1 machien to -CURRENT, I get the following: ===> lib/libarchive (install) printf: not found "/usr/src/lib/libarchive/Makefile", line 28: warning: "printf "%d.%02d.%03d" 1 2 36" returned non-zero status expr: not found "/usr/src/lib/libarchive/Makefile", line 31: warning: "expr 1 + 2" returned non-zero status install -C -o root -g wheel -m 444 libarchive.a /usr/lib install -C -o root -g wheel -m 444 libarchive_p.a /usr/lib install -s -o root -g wheel -m 444 libarchive.so. /usr/lib install: libarchive.so.: No such file or directory *** Error code 71 Stop in /usr/src/lib/libarchive. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This is on (after rebooting with the new kernel): FreeBSD antgproxy.gptech.com.au 7.0-CURRENT FreeBSD 7.0-CURRENT #15: Fri Oct 14 04:22:17 EST 2005 root@antgproxy.gptech.com.au:/usr/obj/usr/src/sys/GPROXY6 i386 Cheers Antony From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 06:35:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AA9C16A41F for ; Fri, 14 Oct 2005 06:35:26 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 632EB43D4C for ; Fri, 14 Oct 2005 06:35:25 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 14 Oct 2005 06:35:23 -0000 Received: from p5090D77F.dip.t-dialin.net (EHLO klotz.local) [80.144.215.127] by mail.gmx.net (mp001) with SMTP; 14 Oct 2005 08:35:23 +0200 X-Authenticated: #989277 Received: from [192.168.0.1] (klotz.local [192.168.0.1]) by klotz.local (8.13.4/8.13.4) with ESMTP id j9E6YUnM001459 for ; Fri, 14 Oct 2005 08:34:31 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <434F5176.2060704@nurfuerspam.de> Date: Fri, 14 Oct 2005 08:34:30 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051012) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: panic: RELENG_6 BETA5 in atpic_handle_intr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 06:35:26 -0000 Hi, I've seen a panic on my Thinkpad (R40) after it has been idle for one hour at night (cpufreq and powerd is in use). The trace shows: Fatal trap 1: privileged instruction fault while in kernel mode processor eflags = resume, IOPL=0 current process: 11 (idle) atpic_handle_intr() acpi_cpu_idle() idle_proc() fork_exit() fork_trampoline() Martin From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 07:00:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4774816A420 for ; Fri, 14 Oct 2005 07:00:14 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95E6A43D48 for ; Fri, 14 Oct 2005 07:00:13 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp2-g19.free.fr (Postfix) with ESMTP id 754BB4C68F for ; Fri, 14 Oct 2005 09:00:12 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j9E6xnXs021985; Fri, 14 Oct 2005 08:59:54 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 08:59:40 +0200 User-Agent: KMail/1.8.2 References: <200510131859.03307.thierry@herbelot.com> <200510132251.00632.thierry@herbelot.com> <20051013.151436.85394837.imp@bsdimp.com> In-Reply-To: <20051013.151436.85394837.imp@bsdimp.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510140859.42748.thierry@herbelot.com> Cc: "M. Warner Losh" Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.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, 14 Oct 2005 07:00:14 -0000 Le Thursday 13 October 2005 23:14, M. Warner Losh a écrit : > > Looks like it is a combination of problems. The PCI registers claim > to be a 8029, but it doesn't emulate the 8029 specific registers. I > have a patch for this. In addition, the ed driver has a mistake in > its 8029 support. I've fixed this as well and am testing the result. Hello, Here are the results : (with a kernel including your latest patches and an un-patched qemu) $FreeBSD: src/sys/dev/ed/if_ed.c,v 1.265 2005/09/26 18:22:24 imp Exp $ $FreeBSD: src/sys/dev/ed/if_ed_novell.c,v 1.8 2005/09/07 03:20:33 imp Exp $ $FreeBSD: src/sys/dev/ed/if_ed_rtl80x9.c,v 1.2 2005/10/13 22:06:02 imp Exp $ $FreeBSD: src/sys/dev/ed/if_ed_pci.c,v 1.48 2005/10/13 22:12:34 imp Exp $ $FreeBSD: src/sys/dev/ed/if_ed_isa.c,v 1.25 2005/10/05 05:21:07 imp Exp $ $FreeBSD: src/sys/dev/ed/if_ed_wd80x3.c,v 1.5 2005/08/28 23:56:25 imp Exp $ % qemu -snapshot -serial stdio newm-wd1.img OK unload OK load /boot/kernel-current /boot/kernel-current text=0x490bf0 data=0x82340+0x9ac6c syms=[0x4+0x690f0+0x4+0x7e65d] OK boot -s -v GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=01 base=0000000000100000 len=0000000007f00000 Copyright (c) 1992-2005 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 7.0-CURRENT #9: Fri Oct 14 08:36:40 CEST 2005 XXX@YYY:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. [SNIP device spam] pci0: at device 2.0 (no driver attached) ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 ed0: [MPSAFE] ed0: bpf attached ed0: Ethernet address: 52:54:00:12:34:56 ed0: type NE2000 (16 bit) ex_isa_identify() Summary : The new ed(4) works as advertised with this new kernel inside a qemu Thanks TfH From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:07:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37DAB16A41F; Fri, 14 Oct 2005 09:07:20 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from hurl.ugcs.caltech.edu (hurl.ugcs.caltech.edu [131.215.176.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 870D243D46; Fri, 14 Oct 2005 09:07:19 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by livecd.ugcs.caltech.edu (Postfix, from userid 3640) id 9916F1C3BAF; Wed, 12 Oct 2005 19:54:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by livecd.ugcs.caltech.edu (Postfix) with ESMTP id 83E5D1C3B98; Wed, 12 Oct 2005 19:54:45 -0700 (PDT) Date: Wed, 12 Oct 2005 19:54:45 -0700 (PDT) From: Jon Dama To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: amd64@freebsd.org Subject: [6.0b5/AMD64] ls /otherdir/devfs induces panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 09:07:20 -0000 The following sequence induces an instant panic: 1) machine just up, no load 2) mount_devfs devfs /test/dev 3) chroot /test /bin/sh 4) ls /dev *PANIC* panic: kmem_malloc(-1905729536): kmem_map too small: 6881290 total allocated Dumping 8191 MB (3 chunks) chunk 0: 1MB (156 pages) ( dump fails to finish ) Kernel: GENERIC AMD64 6.0 Beta 5 I am aware of the VM_KMEM_SIZE_MAX kernel setting, but thought I'd drop a line on the list now because kmem_malloc(-1905729536) seems rather unusual to me. Thanks, Jon From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:07:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9665416A41F; Fri, 14 Oct 2005 09:07:20 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from hurl.ugcs.caltech.edu (hurl.ugcs.caltech.edu [131.215.176.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8755343D53; Fri, 14 Oct 2005 09:07:19 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by livecd.ugcs.caltech.edu (Postfix, from userid 3640) id A11B21C3B8F; Thu, 13 Oct 2005 13:07:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by livecd.ugcs.caltech.edu (Postfix) with ESMTP id 87FC91C3B86; Thu, 13 Oct 2005 13:07:41 -0700 (PDT) Date: Thu, 13 Oct 2005 13:07:41 -0700 (PDT) From: Jon Dama To: amd64@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@freebsd.org Subject: [6.0b5/amd64] ls /otherdir/dev induces panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 09:07:20 -0000 The following sequence induces an instant panic: 1) machine just up, no load 2) mount_devfs devfs /test/dev 3) chroot /test /bin/sh 4) ls /dev *PANIC* panic: kmem_malloc(-1905729536): kmem_map too small: 6881290 total allocated Dumping 8191 MB (3 chunks) chunk 0: 1MB (156 pages) ( dump fails to finish ) Kernel: GENERIC AMD64 6.0 Beta 5 I am aware of the VM_KMEM_SIZE_MAX kernel setting, but thought I'd drop a line on the list now because kmem_malloc(-1905729536) seems rather unusual to me. Thanks, Jon sysctl -a | grep kmem vm.kmem_size_scale: 3 vm.kmem_size_max: 419430400 vm.kmem_size: 419430400 Copyright (c) 1992-2005 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 6.0-BETA5 #0: Sat Oct 8 15:44:03 PDT 2005 xxx@xxxx:/usr/obj/usr/src/sys/SHELL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 250 (2390.61-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 Features=0x78bfbff AMD Features=0xe0500800 real memory = 9663676416 (9216 MB) avail memory = 8285224960 (7901 MB) ACPI APIC Table: 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-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 9 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 6.0 on pci0 pci3: on pcib1 ohci0: mem 0xfc8fd000-0xfc8fdfff irq 19 at devic e 0.0 on pci3 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfc8fe000-0xfc8fefff irq 19 at devic e 0.1 on pci3 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered atapci0: port 0xbc00-0xbc07,0xb800-0xb803,0xb400-0 xb407,0xb000-0xb003,0xac00-0xac0f mem 0xfc8ffc00-0xfc8fffff irq 17 at device 11. 0 on pci3 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376, 0xffa0-0xffaf at device 7.1 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pci0: at device 7.5 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 bge0: mem 0xfc6f0000-0xfc6 fffff irq 24 at device 9.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:e0:81:2d:a3:dc pci0: at device 10.1 (no driver attached ) pcib3: at device 11.0 on pci0 pci1: on pcib3 pci0: at device 11.1 (no driver attached ) pcib4: on acpi0 pci4: on pcib4 agp0: mem 0xf0000000-0xf7ffffff at device 0.0 on pci4 pcib5: at device 1.0 on pci4 pci5: on pcib5 pci5: at device 0.0 (no driver attached) acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi 0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xc0000-0xc97ff,0xc9800-0xcdfff on isa0 atkbdc0: at port 0x60,0x64 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 uhub2: NMB Dell USB Keyboard Hub, class 9/0, rev 1.10/0.01, addr 2 uhub2: 3 ports with 2 removable, bus powered ukbd0: NMB Dell USB 7HK Keyboard, rev 1.10/0.01, addr 3, iclass 3/1 kbd0 at ukbd0 uhid0: NMB Dell USB 7HK Keyboard, rev 1.10/0.01, addr 3, iclass 3/1 Timecounters tick every 1.000 msec acd0: CDROM at ata1-master PIO3 ad6: 70911MB at ata3-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad6s1a From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:10:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A11F16A41F for ; Fri, 14 Oct 2005 09:10:12 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABE9643D46 for ; Fri, 14 Oct 2005 09:10:11 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 12F3721EB; Fri, 14 Oct 2005 05:10:34 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id A65F08A; Fri, 14 Oct 2005 05:10:30 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EQLZk-0004pw-OQ; Fri, 14 Oct 2005 10:10:04 +0100 Date: Fri, 14 Oct 2005 10:10:04 +0100 From: Brian Candler To: Brooks Davis Message-ID: <20051014091004.GC18513@uk.tiscali.com> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051013181026.GB27418@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: Max Laier , freebsd-current@freebsd.org, Eric Anderson Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 09:10:12 -0000 On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote: > > I don't think you can measure one single interger (or 64bit) increase in face > > of a operation that has to access backing store. Even if there is a > > performance hit, you don't have to build your kernel with the option enabled. > > The one thing I'd be worried about here is that 64bit updates are > expensive on 32bit machines if you want them to be atomic. Relative to > backing store they probably still don't matter, but the might be > noticable. I'd be grateful if you could clarify that point for me. Are you saying that if I write long long foo; ... foo++; then the C compiler generates code for 'foo++' which is not thread-safe? (And therefore I would have to protect it with a mutex or critical section) Or are you saying that the C compiler inserts its own code around foo++ to turn it into a critical section, and therefore runs less efficiently than you'd expect? Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:29:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFDED16A41F for ; Fri, 14 Oct 2005 09:29:29 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id D21EF43D46 for ; Fri, 14 Oct 2005 09:29:26 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Oct 2005 09:29:25 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp033) with SMTP; 14 Oct 2005 11:29:25 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 11:29:10 +0200 User-Agent: KMail/1.8.1 References: <200510111932.50224@harrymail> In-Reply-To: <200510111932.50224@harrymail> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14295524.TzjkuYRUAT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510141129.21557@harrymail> X-Y-GMX-Trusted: 0 Subject: Re: nss_ldap segmentation fault with 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: Fri, 14 Oct 2005 09:29:29 -0000 --nextPart14295524.TzjkuYRUAT Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag, 11. Oktober 2005 19:32 CEST schrieb Emanuel Strobl: > Hello, > > I set up ldap authentication against (MS)AD-Server and see segmentation > faults of `id user-xy` for example. > The strange thing is that if I fire id for the first time it works, but > then it segfaults. The cause is the following line in > /etc/nsswitch.conf: "group: file ldap". As soon as I add ldap I can't su > anymore because nss_ldap.so seems to crash. If I remove the group ldap > directive (and leave shells and passwd with ldap) everything is working > fine again. How can I provide useful info to get this fixed? Please, is there no way to use LDAP user database with recent FreeBSD? Is there anything in the base which I don't know or do I still need the=20 nss_ldap port? (which doesn't work with RC1!) Thanks, =2Dharry --nextPart14295524.TzjkuYRUAT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDT3pxBylq0S4AzzwRAretAJ9uyUf6WyK3gOu5Fre0n9DBJ0vfhwCgkp2j hZiAvTtE/TzjfoaJyLJlpgM= =dezh -----END PGP SIGNATURE----- --nextPart14295524.TzjkuYRUAT-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:34:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C97B516A41F for ; Fri, 14 Oct 2005 09:34:45 +0000 (GMT) (envelope-from DAntrushin@mail.ru) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F9E43D46 for ; Fri, 14 Oct 2005 09:34:45 +0000 (GMT) (envelope-from DAntrushin@mail.ru) Received: from [81.3.158.68] (port=50745 helo=[129.159.124.237]) by mx1.mail.ru with esmtp id 1EQLxb-000AhQ-00 for freebsd-current@freebsd.org; Fri, 14 Oct 2005 13:34:44 +0400 Message-ID: <434F7BB3.5020808@mail.ru> Date: Fri, 14 Oct 2005 13:34:43 +0400 From: Denis Antrushin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> In-Reply-To: <20051014091004.GC18513@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 09:34:45 -0000 Brian Candler wrote: > On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote: > >>>I don't think you can measure one single interger (or 64bit) increase in face >>>of a operation that has to access backing store. Even if there is a >>>performance hit, you don't have to build your kernel with the option enabled. >> >>The one thing I'd be worried about here is that 64bit updates are >>expensive on 32bit machines if you want them to be atomic. Relative to >>backing store they probably still don't matter, but the might be >>noticable. > > > I'd be grateful if you could clarify that point for me. Are you saying that > if I write > > long long foo; > ... > foo++; > > then the C compiler generates code for 'foo++' which is not thread-safe? > (And therefore I would have to protect it with a mutex or critical section) Yes. On 32-bit it looks something like that: cltd movl $1 %eax movl $0, %edx addl -16(%ebp), %eax adcl -12(%ebp), %edx movl %eax, -16(%ebp) movl %edx, -12(%ebp) > Or are you saying that the C compiler inserts its own code around foo++ to > turn it into a critical section, and therefore runs less efficiently than > you'd expect? C compilers not that smart yet, AFAIK :-) From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:41:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5805716A41F for ; Fri, 14 Oct 2005 09:41:40 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id BBD4E43D46 for ; Fri, 14 Oct 2005 09:41:38 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Oct 2005 09:41:36 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp011) with SMTP; 14 Oct 2005 11:41:36 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org, nectar@freebsd.org Date: Fri, 14 Oct 2005 11:41:21 +0200 User-Agent: KMail/1.8.1 References: <200510111932.50224@harrymail> In-Reply-To: <200510111932.50224@harrymail> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2608857.aVeXJzgxEF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510141141.33231@harrymail> X-Y-GMX-Trusted: 0 Cc: Subject: Re: nss_ldap segmentation fault with 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: Fri, 14 Oct 2005 09:41:40 -0000 --nextPart2608857.aVeXJzgxEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag, 11. Oktober 2005 19:32 CEST schrieb Emanuel Strobl: > Hello, > > I set up ldap authentication against (MS)AD-Server and see segmentation > faults of `id user-xy` for example. > The strange thing is that if I fire id for the first time it works, but > then it segfaults. The cause is the following line in > /etc/nsswitch.conf: "group: file ldap". As soon as I add ldap I can't su > anymore because nss_ldap.so seems to crash. If I remove the group ldap > directive (and leave shells and passwd with ldap) everything is working > fine again. How can I provide useful info to get this fixed? > > Thanks, > > -Harry I have some (probably useless) results after compiling nss_ldap with debug= =20 enabled, but I don't know how to get a core dump from a .so :( =46irst the debug output of nss_ldap when it crashes, next when is succeeds= =2E=20 I have no idea why it sometimes works but most times crashes :( file:/usr/ports/net/nss_ldap#96: id hsc1 nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_search_s nss_ldap: =3D=3D> do_init nss_ldap: =3D=3D> do_close_no_unbind nss_ldap: <=3D=3D do_close_no_unbind (connection was not open) nss_ldap: =3D=3D> ldap_init nss_ldap: <=3D=3D ldap_init nss_ldap: <=3D=3D do_init (initialized session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: =3D=3D> ldap_init nss_ldap: <=3D=3D ldap_init nss_ldap: <=3D=3D do_init (initialized session) nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: =3D=3D> do_set_sockopts nss_ldap: <=3D=3D do_set_sockopts nss_ldap: <=3D=3D do_open (session connected to DSA) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DUser)(sAMAccountName=3Dhsc1)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search_s nss_ldap: =3D=3D> do_parse_s nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: <=3D=3D do_parse_s nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_ent_context_init_locked nss_ldap: <=3D=3D _nss_ldap_ent_context_init_locked nss_ldap: =3D=3D> _nss_ldap_search nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DGroup)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search nss_ldap: <=3D=3D do_search nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push=20 (CN=3DDom=C3=A4nen-Admins,CN=3DUsers,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s Segmentation fault (core dumped) =2D----------------------------------------------------------------------- View times repeated to crash, then suddenly one success which lokks like=20 this: file:/usr/ports/net/nss_ldap#97: id hsc1 nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_search_s nss_ldap: =3D=3D> do_init nss_ldap: =3D=3D> do_close_no_unbind nss_ldap: <=3D=3D do_close_no_unbind (connection was not open) nss_ldap: =3D=3D> ldap_init nss_ldap: <=3D=3D ldap_init nss_ldap: <=3D=3D do_init (initialized session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: =3D=3D> ldap_init nss_ldap: <=3D=3D ldap_init nss_ldap: <=3D=3D do_init (initialized session) nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: =3D=3D> do_set_sockopts nss_ldap: <=3D=3D do_set_sockopts nss_ldap: <=3D=3D do_open (session connected to DSA) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DUser)(sAMAccountName=3Dhsc1)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search_s nss_ldap: =3D=3D> do_parse_s nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: <=3D=3D do_parse_s nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_ent_context_init_locked nss_ldap: <=3D=3D _nss_ldap_ent_context_init_locked nss_ldap: =3D=3D> _nss_ldap_search nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DGroup)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search nss_ldap: <=3D=3D do_search nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push=20 (CN=3DDom=C3=A4nen-Admins,CN=3DUsers,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push=20 (CN=3DDom=C3=A4nen-Benutzer,CN=3DUsers,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push (CN=3DEntwicklung,OU=3DSecurity=20 Groups,OU=3DMyBusiness,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push (CN=3DMarketing,OU=3DSecurity=20 Groups,OU=3DMyBusiness,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push (CN=3DVerwaltung,OU=3DSecurity=20 Groups,OU=3DMyBusiness,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push (CN=3DVertrieb,OU=3DSecurity=20 Groups,OU=3DMyBusiness,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getent_ex nss_ldap: =3D=3D> do_parse nss_ldap: =3D=3D> do_result nss_ldap: <=3D=3D do_result nss_ldap: <=3D=3D do_parse nss_ldap: <=3D=3D _nss_ldap_getent_ex nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_ent_context_init_locked nss_ldap: <=3D=3D _nss_ldap_ent_context_init_locked nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_search_s nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DGroup)(msSFU30GidNumber=3D100= 12)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search_s nss_ldap: =3D=3D> do_parse_s nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push=20 (CN=3DDom=C3=A4nen-Admins,CN=3DUsers,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse_s nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_search_s nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DGroup)(msSFU30GidNumber=3D100= 12)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search_s nss_ldap: =3D=3D> do_parse_s nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push=20 (CN=3DDom=C3=A4nen-Admins,CN=3DUsers,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse_s nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_enter nss_ldap: <=3D=3D _nss_ldap_enter nss_ldap: =3D=3D> _nss_ldap_getbyname nss_ldap: =3D=3D> _nss_ldap_search_s nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_filter nss_ldap: :=3D=3D do_filter: (&(objectclass=3DGroup)(msSFU30GidNumber=3D100= 11)) nss_ldap: <=3D=3D do_filter nss_ldap: =3D=3D> do_with_reconnect nss_ldap: =3D=3D> do_open nss_ldap: =3D=3D> do_init nss_ldap: <=3D=3D do_init (cached session) nss_ldap: <=3D=3D do_open (cached session) nss_ldap: =3D=3D> do_search_s nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: =3D=3D> do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_bind nss_ldap: <=3D=3D do_search_s nss_ldap: <=3D=3D do_with_reconnect nss_ldap: <=3D=3D _nss_ldap_search_s nss_ldap: =3D=3D> do_parse_s nss_ldap: =3D=3D> _nss_ldap_assign_userpassword nss_ldap: <=3D=3D _nss_ldap_assign_userpassword nss_ldap: =3D=3D> _nss_ldap_namelist_find nss_ldap: <=3D=3D _nss_ldap_namelist_find nss_ldap: =3D=3D> _nss_ldap_namelist_push=20 (CN=3DDom=C3=A4nen-Benutzer,CN=3DUsers,DC=3Dmars,DC=3Dmable,DC=3Dde) nss_ldap: <=3D=3D _nss_ldap_namelist_push nss_ldap: =3D=3D> _nss_ldap_dn2uid nss_ldap: <=3D=3D _nss_ldap_dn2uid nss_ldap: =3D=3D> _nss_ldap_namelist_destroy nss_ldap: <=3D=3D _nss_ldap_namelist_destroy nss_ldap: <=3D=3D do_parse_s nss_ldap: =3D=3D> _nss_ldap_ent_context_release nss_ldap: <=3D=3D _nss_ldap_ent_context_release nss_ldap: =3D=3D> _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_leave nss_ldap: <=3D=3D _nss_ldap_getbyname uid=3D10015(hsc1) gid=3D10012(Dom=C3=A4nen-Admins) groups=3D10012(Dom=C3=A4= nen-Admins),=20 10011(Dom=C3=A4nen-Benutzer) --nextPart2608857.aVeXJzgxEF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDT31NBylq0S4AzzwRAn5/AJ0XjBSquOeUTr5oenr6NwhJcLsB7gCfftHV +KYm9SCfYo++taZZ7tTJCXg= =G9B5 -----END PGP SIGNATURE----- --nextPart2608857.aVeXJzgxEF-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 10:12:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B91E216A41F for ; Fri, 14 Oct 2005 10:12:14 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E9A543D45 for ; Fri, 14 Oct 2005 10:12:12 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Oct 2005 10:10:42 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp005) with SMTP; 14 Oct 2005 12:10:42 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 12:10:31 +0200 User-Agent: KMail/1.8.1 References: <200510111932.50224@harrymail> <200510141141.33231@harrymail> In-Reply-To: <200510141141.33231@harrymail> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2236984.0dSMALvLf2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510141210.41313@harrymail> X-Y-GMX-Trusted: 0 Cc: nectar@freebsd.org Subject: Re: nss_ldap segmentation fault with 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: Fri, 14 Oct 2005 10:12:14 -0000 --nextPart2236984.0dSMALvLf2 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 14. Oktober 2005 11:41 CEST schrieb Emanuel Strobl: > Am Dienstag, 11. Oktober 2005 19:32 CEST schrieb Emanuel Strobl: > > Hello, > > > > I set up ldap authentication against (MS)AD-Server and see > > segmentation faults of `id user-xy` for example. > > The strange thing is that if I fire id for the first time it works, > > but then it segfaults. The cause is the following line in > > /etc/nsswitch.conf: "group: file ldap". As soon as I add ldap I can't > > su anymore because nss_ldap.so seems to crash. If I remove the group > > ldap directive (and leave shells and passwd with ldap) everything is > > working fine again. How can I provide useful info to get this fixed? While desperate tinkering I found that --enable-rfc2307bis is the culprit. If I comment it out in the ports Makefile everything is working fine! I hope this helps to get the port in a working-by-default state, even=20 better was if FreeBSD could handle ldap user databases from the base,=20 IMHO. Thanks, =2DHarry --nextPart2236984.0dSMALvLf2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDT4QhBylq0S4AzzwRAvDDAJ9igzf5r06TFEhubnT0rRthXHLD8gCdFc95 ajU2Xb/fkLw56VARckGBdus= =Unfu -----END PGP SIGNATURE----- --nextPart2236984.0dSMALvLf2-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 10:30:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B40616A41F for ; Fri, 14 Oct 2005 10:30:04 +0000 (GMT) (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 BF71643D45 for ; Fri, 14 Oct 2005 10:30:03 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9EAU19E028938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 14 Oct 2005 20:30:02 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9EAU0Hh009592; Fri, 14 Oct 2005 20:30:01 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9EAU0Mk009588; Fri, 14 Oct 2005 20:30:00 +1000 (EST) (envelope-from pjeremy) Date: Fri, 14 Oct 2005 20:30:00 +1000 From: Peter Jeremy To: Brian Candler Message-ID: <20051014102959.GB7346@cirb503493.alcatel.com.au> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051014091004.GC18513@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 10:30:04 -0000 On Fri, 2005-Oct-14 10:10:04 +0100, Brian Candler wrote: >I'd be grateful if you could clarify that point for me. Are you saying that >if I write > > long long foo; > ... > foo++; > >then the C compiler generates code for 'foo++' which is not thread-safe? >(And therefore I would have to protect it with a mutex or critical section) foo++ is not normally thread-safe even if foo is an int or pointer. Typical iA32 code looks like: addl $1,foo This is only thread-safe in a UP environment. Typical RISC code looks like: load foo,%reg add $1,%reg store %reg,foo This is not thread-safe. Note that the compiler may keep foo in a register for an extended period unless you convince the compiler not to. Especially on RISC processors, the compiler will normally spread the load/add/store to try and avoid pipeline stalls. If you share foo between two threads, you need to use atomic operations (see ), mutexes or critical sections on all updates. Note that you can do atomic 64-bit operations on iA32 (except 80386 and 80486) using a locked cmpxchg8b in a loop. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 10:32:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3B0916A41F for ; Fri, 14 Oct 2005 10:32:27 +0000 (GMT) (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 70F9943D45 for ; Fri, 14 Oct 2005 10:32:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 0084A9453; Fri, 14 Oct 2005 12:32:25 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 0B582405A; Fri, 14 Oct 2005 12:32:14 +0200 (CEST) Date: Fri, 14 Oct 2005 12:32:13 +0200 From: Jeremie Le Hen To: Denis Antrushin Message-ID: <20051014103213.GF14063@obiwan.tataz.chchile.org> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <434F7BB3.5020808@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434F7BB3.5020808@mail.ru> User-Agent: Mutt/1.5.10i Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 10:32:27 -0000 Hi, > >I'd be grateful if you could clarify that point for me. Are you saying that > >if I write > > > > long long foo; > > ... > > foo++; > > > >then the C compiler generates code for 'foo++' which is not thread-safe? > >(And therefore I would have to protect it with a mutex or critical section) > > Yes. On 32-bit it looks something like that: > > cltd > movl $1 %eax > movl $0, %edx > addl -16(%ebp), %eax > adcl -12(%ebp), %edx > movl %eax, -16(%ebp) > movl %edx, -12(%ebp) I'm not sure about it but I bet there are some macro for this kind of thing in order to use a mutex only when necessary (IOW, on archs that don't support 64bits natively). Am I right, and in this case what are those macros ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 10:34:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A57A16A41F for ; Fri, 14 Oct 2005 10:34:11 +0000 (GMT) (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 C04E943D48 for ; Fri, 14 Oct 2005 10:34:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id F22E595A1; Fri, 14 Oct 2005 12:34:09 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 259604080; Fri, 14 Oct 2005 12:33:58 +0200 (CEST) Date: Fri, 14 Oct 2005 12:33:58 +0200 From: Jeremie Le Hen To: Denis Antrushin Message-ID: <20051014103358.GA30844@obiwan.tataz.chchile.org> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <434F7BB3.5020808@mail.ru> <20051014103213.GF14063@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051014103213.GF14063@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.10i Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 10:34:11 -0000 > I'm not sure about it but I bet there are some macro for this kind of > thing in order to use a mutex only when necessary (IOW, on archs that > don't support 64bits natively). Am I right, and in this case what > are those macros ? Ok, forget it, I didn't read Peter Jeremy's next email. This is . Sorry for the noise. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 11:05:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88C4316A41F for ; Fri, 14 Oct 2005 11:05:50 +0000 (GMT) (envelope-from jiashiun@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C6C43D46 for ; Fri, 14 Oct 2005 11:05:49 +0000 (GMT) (envelope-from jiashiun@gmail.com) Received: by qproxy.gmail.com with SMTP id a39so263034qbd for ; Fri, 14 Oct 2005 04:05:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nxnPNNH8bEGRDHicCK18RKuO21b1iljPBoDrb+vqqf3DeKUd+qohxXAOi3XkEHW6u2D0iAdhhY2nXakMY+iOhMO2KBWpYPvw5t7s9251pCT1wA7m0NPb5yGBSjvttE2ie0JuFo/tJC8bh4b/0L90K6AB/d/Ka7yw4BZWYmw0ayc= Received: by 10.65.138.15 with SMTP id q15mr607059qbn; Fri, 14 Oct 2005 04:05:48 -0700 (PDT) Received: by 10.65.107.12 with HTTP; Fri, 14 Oct 2005 04:05:48 -0700 (PDT) Message-ID: <1d6d20bc0510140405g46ce76aei@mail.gmail.com> Date: Fri, 14 Oct 2005 19:05:48 +0800 From: Jia-Shiun Li To: Lawrence Farr In-Reply-To: <20051011122055.DCAB46C8811@gunfright.epcdirect.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051011122055.DCAB46C8811@gunfright.epcdirect.co.uk> Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: SATA Ports not found on Asus P5LD2-VM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 11:05:50 -0000 2005/10/11, Lawrence Farr : > Apologies, here's the rest of it > > I have an Asus P5LD2-VM motheroard: > > Any ideas anyone? You have your ICH7 configured to IDE-compatible mode, and there is apparently driver problems with it. Try setting it to ACHI mode. ICH7 ids was added by Soren but not tested. It would be very appreciated if you can test both configurations and attach complete verbose dmesgs to sos@ and current@. If you disable the ITE controller in BIOS setting then OS will not be able to find it. Enable it and try agin to see if 'pciconf -lv' can find any unknown device. IT8212F (RAID ver) is supported, but not IT8211 (non-RAID). From the spec of similar model P5LD2 it seemed to be an IT8211. However as far as I know the only difference in between to the driver is PCI device id, since the driver does not use its hw RAID function. If you are able to compile and test the kernel/driver w/ patches it would be better. Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 11:08:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1ACE16A41F; Fri, 14 Oct 2005 11:08:21 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9042F43D46; Fri, 14 Oct 2005 11:08:21 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 9C2B59F; Fri, 14 Oct 2005 07:07:08 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 4E37E6175; Fri, 14 Oct 2005 07:07:05 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EQNQ6-0004xj-N2; Fri, 14 Oct 2005 12:08:14 +0100 Date: Fri, 14 Oct 2005 12:08:14 +0100 From: Brian Candler To: Emanuel Strobl Message-ID: <20051014110814.GA19035@uk.tiscali.com> References: <200510111932.50224@harrymail> <200510141141.33231@harrymail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510141141.33231@harrymail> User-Agent: Mutt/1.4.2.1i Cc: nectar@freebsd.org, freebsd-current@freebsd.org Subject: Re: nss_ldap segmentation fault with 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: Fri, 14 Oct 2005 11:08:22 -0000 On Fri, Oct 14, 2005 at 11:41:21AM +0200, Emanuel Strobl wrote: > nss_ldap: ==> do_search_s > Segmentation fault (core dumped) It looks like the program which loaded nss_ldap.so has dumped core. This might be login, sshd, ... I really don't know :-) But a scan across your filesystem for *.core might turn it up. Alternatively, you should be able to put the file in a directory of your choice using # sysctl kern.corefile=/var/tmp/%N.core If it's a setuid program (like /usr/bin/login), you will in any case need to set # sysctl kern.sugid_coredump=1 to get it written to disk. However there will be other people here who are much more expert in how to get core files than me... Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:44:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA9D416A41F for ; Thu, 13 Oct 2005 16:44:57 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8E6843D45 for ; Thu, 13 Oct 2005 16:44:57 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 85EE82F2B; Thu, 13 Oct 2005 11:44:56 -0500 (CDT) Date: Thu, 13 Oct 2005 11:44:56 -0500 To: Andy Hilker Message-ID: <20051013164456.GA11820@soaustin.net> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051013155511.GA1748@mail.crypta.net> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Fri, 14 Oct 2005 12:12:50 +0000 Cc: current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 16:44:58 -0000 On Thu, Oct 13, 2005 at 05:55:11PM +0200, Andy Hilker wrote: > Is it possible to include this minor patch for rc-ng scripts? It > ist present since 5.3 or earlier... I hate to pick on any particular poster, but, folks ... We're at the tail-end (I **hope**) of a release cycle that began (if you take 'src freeze' as 'began') on 10 June 2005. This means we just entered the 4th month of it (2.5 of which have been in either ports freeze or thaw). For comparision 5.3 ran from 16 Aug 2004 to 5 Nov 2004, in which ports was frozen or thawed for 2 months. (And we thought _that_ hurt at the time!) This long cycle is really putting the ports team at a disadvantage because there are certain thing we just can't do in a thaw, and all we do during freezes is bugfixes. The first rule of software engineering is that "the final product will have bugs" and the second rule of software engineering is "eventually you have to ship a product". If we held off any release until GNATS was empty we could just all stop now because they arrive faster than we have current volunteers to fix them. People really need to be realistic about what can and can not be fixed and when. Once you're already 2 months past your initial deadline, and counting, the only things that should be going in are things that would otherwise be completely deadly to us. Everything else is going to have to catch the next train because this one is pulling away from the platform. End of rant. No, I'm not on Release Engineering, so I can't speak for them. OTOH I _do_ have many (too many) years of professional experience and I _can_ speak for it. And again, this is not directed at OP, there's been several people within a couple of days asking almost the exact same question. mcl From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 17:17:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 075F316A41F for ; Thu, 13 Oct 2005 17:17:50 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90BE143D46 for ; Thu, 13 Oct 2005 17:17:49 +0000 (GMT) (envelope-from marsgmiro@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so376624nzd for ; Thu, 13 Oct 2005 10:17:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mgne2qhtjWb+6BwW7mhT9ccw3SKPzhGQOF8EUypP7mZA+NEBQmqmhatBCCGueuDXukFj5nTjf9gCuq9EQXhELpn0Pr4MrXDRSP7gShm+kE/3FeH69CTUbATfkB2mA0q5fOazFOciDxx4qNTjmecSY6ryJBhobAiAeXTE7PPglQ4= Received: by 10.36.75.9 with SMTP id x9mr2237407nza; Thu, 13 Oct 2005 10:17:46 -0700 (PDT) Received: by 10.36.72.10 with HTTP; Thu, 13 Oct 2005 10:17:46 -0700 (PDT) Message-ID: <28edec3c0510131017s6e5c8234n8d3a56fe67c042a8@mail.gmail.com> Date: Fri, 14 Oct 2005 01:17:46 +0800 From: "Mars G. Miro" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Fri, 14 Oct 2005 12:12:50 +0000 Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 17:17:50 -0000 > In message: <200510131210.55135.jkim at FreeBSD.org> > Jung-uk Kim writes: > : On Thursday 13 October 2005 10:21 am, Thierry Herbelot wrote: > : > Le Thursday 13 October 2005 15:38, Joshua Coombs a =1B$,3u=3D=1B(Bcri= t : > : > > Welp, while I have no real help, I can point out this was > : > > reported by another user on the stable list, QEMU + RC1 =3D=3D no e= d > : > > : > well, I should have looked there before posting here ;-) (sorry for > : > the excellent Michel talon at lpthe.jussieu.fr : I should have > : > seeen your post) > : > > : > > I'm kinda dreading upgrading my 386... I'll pull down the generic > : > > kernel and do a test boot to see if it's a QEMU thing or a > : > > reguression in RC1 > : > > : > for me, it's definitely a qemu thing : I have two other machines > : > upgraded to 6.0 post-RC1, and both are working *fine* ; moreover > : > one is a notebook with a pcmcia ed(4), and this NIC works perfectly > : > (the issue is therefore seen only on qemu) > : For the record, I have never been able to successfully use qemu (w/ or w/o kqemu, whether i386 or amd64) + 6.0 (up to RC1). It just panics somewhere during the installation -- I'm able to get past sysinstall, create my FreeBSD partitions, and proceed to doing a minimal install, but somewhere in the middle of extracting, it just panics. I thought it was caused by some of the ATA problems (w/c were supposed to be fixed) but somehow I've not been successful. Some people also said something about turning off INVARIANTS, WITNESS and friends but I haven't checked whether this is disabled in RC1. Some people also had the same problems in VMWare and 6.X though I don't know if they've tried RC1 and whether that would work. Maybe those who have VMWare report back?. I wanted to track this down but have been busy with other more impt matters ;-( This doesn't happen in 5.X, where I'm able to install it fine whether in i386 or amd64, though the latter I've had to patch my tree because there's no ed. This is on FreeBSD/amd64 5.4Rp7 Thanks. > : QEMU emulates RTL8029: > : > : ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 > : ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 > : > : and Warner Losh MFC'd new ed(4) right before 6.0-RC1: > : > : http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 > : > : The new driver does more aggressive probing and it seems QEMU cannot > : handle it. > Yup. I'm trying to get qemu going here. It core dumps for me in > -nographics mode, which frustrates me since I can't run it on my > fastest machine while at work (the machine is at home and the DSL line > is too slow for qemu's use of X but not too slow for firefox!). I've > installed it on my laptop and we'll see how well it works. I'm > guessing it may be a bug in all RTL80x9 hardware that I introduced > into the patches I committed (or was there from the start). > I lost my bid last night on real 8029 and 8019 hardware on ebay. If > someone wanted to send it to me, that would be great! I have enough > other NE-2000 clone hardware (including about 30 16-bit PC Cards that > all work flawlessly or nearly flawlessly[*]). > I don't suppose there's an easy way to run qemu where it just boots a > FreeBSD kernel... > Warner > [*] My FA-410 takes forever to autonegotiate, but once it does, it > works great. All others work, including one that don't work > completely on any other open source OS... cheers mars From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:06:36 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D92FA16A41F for ; Thu, 13 Oct 2005 22:06:36 +0000 (GMT) (envelope-from ah@cryptobank.de) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B81143D49 for ; Thu, 13 Oct 2005 22:06:36 +0000 (GMT) (envelope-from ah@cryptobank.de) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id 4B516ECD43B; Fri, 14 Oct 2005 00:07:17 +0200 (CEST) Date: Fri, 14 Oct 2005 00:07:17 +0200 From: Andy Hilker To: Mark Linimon Message-ID: <20051013220716.GA24448@mail.crypta.net> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> <20051013164456.GA11820@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051013164456.GA11820@soaustin.net> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker X-Mailman-Approved-At: Fri, 14 Oct 2005 12:12:50 +0000 Cc: current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Thu, 13 Oct 2005 22:06:37 -0000 You (Mark Linimon) wrote: > On Thu, Oct 13, 2005 at 05:55:11PM +0200, Andy Hilker wrote: > > Is it possible to include this minor patch for rc-ng scripts? It > > ist present since 5.3 or earlier... > > I hate to pick on any particular poster, but, folks ... [...] Sorry, but I begged several times and this issue is a minor patch but maybe a real bug in some environments. I just want to ask and remember because it is open since at least 5.3 ! This is not a stopper issue for release, it was just a question. It would be a big step forward if someone take this bug report in his responsibility, take a look and fixing as soon as possible. bye, Andy From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 07:34:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41E0D16A41F for ; Fri, 14 Oct 2005 07:34:45 +0000 (GMT) (envelope-from manfred@odiisi.net) Received: from mx-02.sil.at (mx-02.sil.at [86.59.12.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA18943D48 for ; Fri, 14 Oct 2005 07:34:44 +0000 (GMT) (envelope-from manfred@odiisi.net) Received: from [62.116.73.122] (helo=solitec22.solitec.lan) by mx-02.sil.at with esmtp (Exim 4.52) id 1EQK5T-0002BX-HA for freebsd-current@freebsd.org; Fri, 14 Oct 2005 09:34:43 +0200 From: Manfred Odenstein To: freebsd-current@freebsd.org In-Reply-To: <434DDA4A.2060701@gddsn.org.cn> References: <434DDA4A.2060701@gddsn.org.cn> Content-Type: text/plain Date: Fri, 14 Oct 2005 09:34:42 +0200 Message-Id: <1129275282.8280.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Scan-Signature: 7198b07309c365c0bb33c6491e37ce8a X-Mailman-Approved-At: Fri, 14 Oct 2005 12:12:50 +0000 Subject: Re: Netgear WG511 drivers help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 07:34:45 -0000 hello, this driver worked for me (freenbsd 5.4 on IBM T22 with Netgear WG511) http://green.homeunix.org/~green/prism54-driver/pff/ Am Donnerstag, den 13.10.2005, 11:53 +0800 schrieb Suken Woo: > lists: > the Netgear WG511 dosen't support on freebsd and ndis wrapper doesn't > work either > anybody could give any help?? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 20:08:29 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D17416A41F; Thu, 13 Oct 2005 20:08:29 +0000 (GMT) (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 7272343D48; Thu, 13 Oct 2005 20:08:27 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j9DK8M7Q008211; Thu, 13 Oct 2005 22:08:22 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j9DK8MIx008209; Thu, 13 Oct 2005 22:08:22 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j9DK2uNv011503; Thu, 13 Oct 2005 22:02:56 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j9DK2s3A011502; Thu, 13 Oct 2005 22:02:54 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 13 Oct 2005 22:02:54 +0200 To: Jung-uk Kim Message-ID: <20051013200254.GA11267@saturn.kn-bremen.de> Mail-Followup-To: Jung-uk Kim , freebsd-current@FreeBSD.org, thierry@herbelot.com, Joshua Coombs , Warner Losh , Bakul Shah , freebsd-emulation@FreeBSD.org References: <200510131331.27906.thierry@herbelot.com> <200510131621.07299.thierry@herbelot.com> <200510131210.55135.jkim@FreeBSD.org> <200510131428.21211.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510131428.21211.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 14 Oct 2005 12:13:51 +0000 Cc: Joshua Coombs , thierry@herbelot.com, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, Bakul Shah , Warner Losh Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2005 20:08:29 -0000 On Thu, Oct 13, 2005 at 02:28:18PM -0400, Jung-uk Kim wrote: > On Thursday 13 October 2005 12:10 pm, Jung-uk Kim wrote: > > QEMU emulates RTL8029: > > > > ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 > > ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 > > > > and Warner Losh MFC'd new ed(4) right before 6.0-RC1: > > > > http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 > > > > The new driver does more aggressive probing and it seems QEMU > > cannot handle it. > > Just for the time being, you can drop the attachment in > ports/emulators/qemu/files directory and rebuild qemu to get ed(4) > back. > > Jung-uk Kim >[patch snipped] Okay, we could add this as an option to our qemu port (`-ne2kvia' or something like that), anyone thinks it is necessary? (I guess this issue will be fixed in 6.0-R?) Juergen From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 12:34:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF2816A41F for ; Fri, 14 Oct 2005 12:34:15 +0000 (GMT) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (vijn.xs4all.nl [194.109.254.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACD8A43D46 for ; Fri, 14 Oct 2005 12:34:13 +0000 (GMT) (envelope-from info@martenvijn.nl) Received: from [192.168.1.6] ([192.168.1.6]) by martenvijn.nl (8.13.3/8.13.1) with ESMTP id j9ECarlf066767; Fri, 14 Oct 2005 14:36:53 +0200 (CEST) (envelope-from info@martenvijn.nl) From: Marten Vijn To: beheer@lijst.wirelessleiden.nl, freebsd-current@freebsd.org Content-Type: text/plain Organization: Marten Vijn Date: Fri, 14 Oct 2005 14:34:27 +0000 Message-Id: <1129300467.656.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: wi2 died on 6.0 rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@martenvijn.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 12:34:15 -0000 on a soekris 4521 => wi2 died while upgrading from 6.0. Beta3 to 6.0 rc1 tested diffent soekri en diffent prism (senao) cards the probleem is reproduceable. a booted system shows me wi1 and wi2 when pullout both cards and put then in place after a while. regards, Marten CNodeMarten# uname -a FreeBSD CNodeMarten.wLeiden.NET 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Wed Oct 5 22:42:34 CEST 2005 root@:/usr/obj/usr/src/sys/TINYBSD i386 wi1: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi1: using RF:PRISM2.5 MAC:ISL3873 wi1: Intersil Firmware: Primary (1.1.1), Station (1.5.6) wi1: Ethernet address: 00:02:6f:01:5c:6e wi2: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard1 wi2: using RF:PRISM2.5 MAC:ISL3873 wi2: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi2: Ethernet address: 00:02:6f:06:d6:2d sis0: Applying short cable fix (reg=ed) CNodeMarten# though in FreeBSD CNodeMarten.wLeiden.NET 6.0-RC1 FreeBSD 6.0-RC1 #0: Thu Oct 13 16:29:13 CEST 2005 root@:/usr/obj/usr/src/sys/TINYBSD i386 wi2 died.... wi1: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi1: using RF:PRISM2.5 MAC:ISL3873 wi1: Intersil Firmware: Primary (1.1.1), Station (1.5.6) wi1: Ethernet address: 00:02:6f:01:5c:6e wi2: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard1 wi2: timeout in wi_cmd 0x0000; event status 0x0000 wi2: timeout in wi_cmd 0x0000; event status 0x0000 wi2: timeout in wi_cmd 0x0000; event status 0x0000 : init failed device_attach: wi2 attach returned 6 after reconnecting the cards: wi1: detached stray irq7 wi1: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi1: using RF:PRISM2.5 MAC:ISL3873 wi1: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi1: Ethernet address: 00:02:6f:06:d6:2d too many stray irq 7's: not logging anymore wi2: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi2: using RF:PRISM2.5 MAC:ISL3873 wi2: Intersil Firmware: Primary (1.1.1), Station (1.5.6) wi2: Ethernet address: 00:02:6f:06:d6:1f CNodeMarten# dmesg: CNodeMarten# dmesg Copyright (c) 1992-2005 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 6.0-RC1 #0: Thu Oct 13 16:29:13 CEST 2005 root@:/usr/obj/usr/src/sys/TINYBSD Timecounter "i8254" frequency 1189158 Hz quality 0 CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin = "AuthenticAMD" Id = 0x494 Stepping = 4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 60416000 (57 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard sysctl machdep.i8254_freq=1189161 returns 0 Timecounter "ELAN" frequency 8192000 Hz quality 1000 pcib0: pcibus 0 on motherboard pci0: on pcib0 wi0: mem 0xa0000000-0xa0000fff irq 10 at device 16.0 on pci0 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.1), Station (1.8.0) wi0: Ethernet address: 00:06:25:a7:48:db cbb0: mem 0xa0001000-0xa0001fff irq 11 at device 17. 0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0xa0002000-0xa0002fff irq 11 at device 17. 1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 sis0: port 0xe100-0xe1ff mem 0xa0003000-0xa000 3fff irq 5 at device 18.0 on pci0 sis0: Silicon Revision: DP83815D miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c1:1d:fc sis1: port 0xe200-0xe2ff mem 0xa0004000-0xa000 4fff irq 9 at device 19.0 on pci0 sis1: Silicon Revision: DP83815D miibus1: on sis1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c1:1d:fd isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd1fff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A Timecounters tick every 1.000 msec Elan-mmcr driver: MMCR at 0xc5b90000. PPS support. Elan-mmcr Soekris net45xx comBIOS ver. 1.24 20040312 Copyright (C) 2000-2004 ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, defa ult to accept, logging disabled wi1: at port 0x100-0x13f irq 11 function 0 config 1 on p ccard0 wi1: using RF:PRISM2.5 MAC:ISL3873 wi1: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi1: Ethernet address: 00:02:6f:06:d6:2d wi2: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard1 wi2: timeout in wi_cmd 0x0000; event status 0x0000 wi2: timeout in wi_cmd 0x0000; event status 0x0000 wi2: timeout in wi_cmd 0x0000; event status 0x0000 : init failed device_attach: wi2 attach returned 6 ad0: 61MB at ata0-master PIO1 Trying to mount root from ufs:/dev/ad0s1a CNodeMarten# CNodeMarten# pciconf -lvv hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x30001022 rev=0x00 hdr=0x00 class = bridge subclass = HOST-PCI wi0@pci0:16:0: class=0x028000 card=0x38741737 chip=0x38731260 rev=0x01 hdr=0x00 class = network cbb0@pci0:17:0: class=0x060700 card=0x00000000 chip=0xac51104c rev=0x00 hdr=0x02 class = bridge subclass = PCI-CardBus cbb1@pci0:17:1: class=0x060700 card=0x00000000 chip=0xac51104c rev=0x00 hdr=0x02 class = bridge subclass = PCI-CardBus sis0@pci0:18:0: class=0x020000 card=0x0020100b chip=0x0020100b rev=0x00 hdr=0x00 class = network subclass = ethernet sis1@pci0:19:0: class=0x020000 card=0x0020100b chip=0x0020100b rev=0x00 hdr=0x00 class = network subclass = ethernet CNodeMarten# CNodeMarten# cat /var/log/messages Jan 1 17:51:44 CNodeMarten newsyslog[243]: logfile first created Jan 1 17:51:45 CNodeMarten syslogd: kernel boot file is /boot/kernel/kernel Jan 1 17:51:45 CNodeMarten kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jan 1 17:51:45 CNodeMarten kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 1 17:51:45 CNodeMarten kernel: The Regents of the University of California. All rights reserved. Jan 1 17:51:45 CNodeMarten kernel: FreeBSD 6.0-RC1 #0: Thu Oct 13 16:29:13 CEST 2005 Jan 1 17:51:45 CNodeMarten kernel: root@:/usr/obj/usr/src/sys/TINYBSD Jan 1 17:51:45 CNodeMarten kernel: Timecounter "i8254" frequency 1189158 Hz quality 0 Jan 1 17:51:45 CNodeMarten kernel: CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Jan 1 17:51:45 CNodeMarten kernel: Origin = "AuthenticAMD" Id = 0x494 Stepping = 4 Jan 1 17:51:45 CNodeMarten kernel: Features=0x1 Jan 1 17:51:45 CNodeMarten kernel: real memory = 67108864 (64 MB) Jan 1 17:51:45 CNodeMarten kernel: avail memory = 60416000 (57 MB) Jan 1 17:51:45 CNodeMarten kernel: ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) Jan 1 17:51:45 CNodeMarten kernel: npx0: [FAST] Jan 1 17:51:45 CNodeMarten kernel: npx0: on motherboard Jan 1 17:51:45 CNodeMarten kernel: npx0: INT 16 interface Jan 1 17:51:45 CNodeMarten kernel: cpu0 on motherboard Jan 1 17:51:45 CNodeMarten kernel: sysctl machdep.i8254_freq=1189161 returns 0 Jan 1 17:51:45 CNodeMarten kernel: Timecounter "ELAN" frequency 8192000 Hz quality 1000 Jan 1 17:51:45 CNodeMarten kernel: pcib0: pcibus 0 on motherboard Jan 1 17:51:45 CNodeMarten kernel: pci0: on pcib0 Jan 1 17:51:45 CNodeMarten kernel: wi0: mem 0xa0000000-0xa0000fff irq 10 at device 16.0 on pci0 Jan 1 17:51:45 CNodeMarten kernel: wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) Jan 1 17:51:45 CNodeMarten kernel: wi0: Intersil Firmware: Primary (1.1.1), Station (1.8.0) Jan 1 17:51:45 CNodeMarten kernel: wi0: Ethernet address: 00:06:25:a7:48:db Jan 1 17:51:45 CNodeMarten kernel: cbb0: mem 0xa0001000-0xa0001fff irq 11 at device 17.0 on pci0 Jan 1 17:51:45 CNodeMarten kernel: cardbus0: on cbb0 Jan 1 17:51:45 CNodeMarten kernel: pccard0: <16-bit PCCard bus> on cbb0 Jan 1 17:51:45 CNodeMarten kernel: cbb1: mem 0xa0002000-0xa0002fff irq 11 at device 17.1 on pci0 Jan 1 17:51:45 CNodeMarten kernel: cardbus1: on cbb1 Jan 1 17:51:45 CNodeMarten kernel: pccard1: <16-bit PCCard bus> on cbb1 Jan 1 17:51:45 CNodeMarten kernel: sis0: port 0xe100-0xe1ff mem 0xa0003000-0xa0003fff irq 5 at device 18.0 on pci0 Jan 1 17:51:45 CNodeMarten kernel: sis0: Silicon Revision: DP83815D Jan 1 17:51:45 CNodeMarten kernel: miibus0: on sis0 Jan 1 17:51:45 CNodeMarten kernel: ukphy0: on miibus0 Jan 1 17:51:45 CNodeMarten kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jan 1 17:51:45 CNodeMarten kernel: sis0: Ethernet address: 00:00:24:c1:1d:fc Jan 1 17:51:45 CNodeMarten kernel: sis1: port 0xe200-0xe2ff mem 0xa0004000-0xa0004fff irq 9 at device 19.0 on pci0 Jan 1 17:51:45 CNodeMarten kernel: sis1: Silicon Revision: DP83815D Jan 1 17:51:45 CNodeMarten kernel: miibus1: on sis1 Jan 1 17:51:45 CNodeMarten kernel: ukphy1: on miibus1 Jan 1 17:51:45 CNodeMarten kernel: ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jan 1 17:51:45 CNodeMarten kernel: sis1: Ethernet address: 00:00:24:c1:1d:fd Jan 1 17:51:45 CNodeMarten kernel: isa0: on motherboard Jan 1 17:51:45 CNodeMarten kernel: pmtimer0 on isa0 Jan 1 17:51:45 CNodeMarten kernel: orm0: at iomem 0xc8000-0xd1fff on isa0 Jan 1 17:51:45 CNodeMarten kernel: ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 Jan 1 17:51:45 CNodeMarten kernel: ata1 at port 0x170-0x177,0x376 irq 15 on isa0 Jan 1 17:51:45 CNodeMarten kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Jan 1 17:51:45 CNodeMarten kernel: sio0: type 16550A, console Jan 1 17:51:45 CNodeMarten kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Jan 1 17:51:45 CNodeMarten kernel: sio1: type 16550A Jan 1 17:51:45 CNodeMarten kernel: Timecounters tick every 1.000 msec Jan 1 17:51:45 CNodeMarten kernel: Elan-mmcr driver: MMCR at 0xc5b90000. PPS support. Jan 1 17:51:45 CNodeMarten kernel: Elan-mmcr Soekris net45xx comBIOS ver. 1.24 20040312 Copyright (C) 2000-2004 Jan 1 17:51:45 CNodeMarten kernel: ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging disabled Jan 1 17:51:45 CNodeMarten kernel: wi1: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 Jan 1 17:51:45 CNodeMarten kernel: wi1: using RF:PRISM2.5 MAC:ISL3873 Jan 1 17:51:45 CNodeMarten kernel: wi1: Intersil Firmware: Primary (1.1.1), Station (1.7.4) Jan 1 17:51:45 CNodeMarten kernel: wi1: Ethernet address: 00:02:6f:06:d6:2d Jan 1 17:51:45 CNodeMarten kernel: wi2: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard1 Jan 1 17:51:45 CNodeMarten kernel: wi2: timeout in wi_cmd 0x0000; event status 0x0000 Jan 1 17:51:45 CNodeMarten last message repeated 2 times Jan 1 17:51:45 CNodeMarten kernel: : init failed Jan 1 17:51:45 CNodeMarten kernel: device_attach: wi2 attach returned 6 Jan 1 17:51:45 CNodeMarten kernel: ad0: 61MB at ata0-master PIO1 Jan 1 17:51:45 CNodeMarten kernel: Trying to mount root from ufs:/dev/ad0s1a Jan 1 17:51:46 CNodeMarten root: /etc/rc: WARNING: Dump device does not exist. Savecore not run. Jan 1 17:51:51 CNodeMarten named[322]: starting BIND 9.3.1 -u bind -t /var/named Jan 1 17:51:52 CNodeMarten named[322]: command channel listening on 127.0.0.1#953 Jan 1 17:51:52 CNodeMarten named[322]: zone 0.0.127.IN-ADDR.ARPA/IN: loading master file /etc/namedb/localhost.rev: file not found Jan 1 17:51:52 CNodeMarten named[322]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT/IN: loading master file /etc/namedb/localhost-v6.rev: file not found Jan 1 17:51:52 CNodeMarten named[322]: running Jan 1 17:52:35 CNodeMarten ntpd[417]: ntpd 4.2.0-a Tue Oct 11 10:04:27 CEST 2005 (1) Jan 1 17:52:35 CNodeMarten ntpd[417]: no IPv6 interfaces found Jan 1 17:52:36 CNodeMarten root: /etc/rc: WARNING: Ignoring scratch file /etc/rc.d/sshd.orig Jan 1 17:52:36 CNodeMarten ntpd[417]: configure: keyword "clientlimit" unknown, line ignored Jan 1 18:10:54 CNodeMarten ntpd[417]: kernel time sync enabled 2001 Jan 1 21:19:08 CNodeMarten login: ROOT LOGIN (root) ON ttyd0 CNodeMarten# From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 12:36:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C05A16A41F; Fri, 14 Oct 2005 12:36:25 +0000 (GMT) (envelope-from freebsd-hw@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id C837343D45; Fri, 14 Oct 2005 12:36:24 +0000 (GMT) (envelope-from freebsd-hw@epcdirect.co.uk) Received: from lfarr (l-farr.int.epcdirect.co.uk [192.168.6.200]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 26EEE6C8873; Fri, 14 Oct 2005 13:36:23 +0100 (BST) From: "Lawrence Farr" To: "'Jia-Shiun Li'" Date: Fri, 14 Oct 2005 13:36:21 +0100 Message-ID: <01a101c5d0bb$e1c05ff0$c806a8c0@lfarr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQr1fA3aWyCrkORnCM1DGZjGZBkAACuKag In-Reply-To: <1d6d20bc0510140405g46ce76aei@mail.gmail.com> X-Mailman-Approved-At: Fri, 14 Oct 2005 12:43:14 +0000 Cc: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: RE: SATA Ports not found on Asus P5LD2-VM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 12:36:25 -0000 > -----Original Message----- > From: owner-freebsd-hardware@freebsd.org > [mailto:owner-freebsd-hardware@freebsd.org] On Behalf Of Jia-Shiun Li > Sent: 14 October 2005 12:06 > To: Lawrence Farr > Cc: freebsd-current@freebsd.org; freebsd-hardware@freebsd.org > Subject: Re: SATA Ports not found on Asus P5LD2-VM > > 2005/10/11, Lawrence Farr : > > Apologies, here's the rest of it > > > > I have an Asus P5LD2-VM motheroard: > > > > > Any ideas anyone? > > You have your ICH7 configured to IDE-compatible mode, and there is > apparently driver problems with it. Try setting it to ACHI mode. ICH7 > ids was added by Soren but not tested. It would be very appreciated if > you can test both configurations and attach complete verbose dmesgs to > sos@ and current@. I have tried with all 3 settings, but only 2 of the 4 ICH7 channels show up. Verbose boot with it set to SATA mode follows below. > If you disable the ITE controller in BIOS setting then OS will not be It's got nothing connected to it. Thanks anyway. ############################## Copyright (c) 1992-2005 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 6.0-BETA2 #0: Tue Aug 23 12:45:39 BST 2005 root@nas-1.int.electronicpage.co.uk:/usr/obj/usr/src/sys/P6 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.40-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x441d> Hyperthreading: 2 logical CPUs real memory = 1072300032 (1022 MB) avail memory = 1040547840 (992 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 7 on acpi0 pci_link3: irq 3 on acpi0 pci_link4: irq 5 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 0 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pcib1: irq 11 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 10 at device 28.1 on pci0 pci2: on pcib2 em0: port 0xd800-0xd81f mem 0xcffe0000-0xcfffffff irq 10 at device 0.0 on pci2 em0: Ethernet address: 00:13:d4:46:b3:cb em0: Speed:N/A Duplex:N/A uhci0: port 0xa800-0xa81f irq 5 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 10 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb400-0xb41f irq 7 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xb800-0xb81f irq 3 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xcfeffc00-0xcfefffff irq 5 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pci1: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 atapci0: failed to enable memory mapping! ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> 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 3200395968 Hz quality 800 Timecounters tick every 1.000 msec ad0: 381554MB at ata0-master SATA150 ad2: 476940MB at ata1-master SATA150 Trying to mount root from ufs:/dev/ad0s1a Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 done All buffers synced. unmount of /dev failed (BUSY) Copyright (c) 1992-2005 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 6.0-BETA2 #0: Tue Aug 23 12:45:39 BST 2005 root@nas-1.int.electronicpage.co.uk:/usr/obj/usr/src/sys/P6 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b29000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b29174. Calibrating clock(s) ... i8254 clock: 1193162 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3200396304 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3200.40-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x441d> Hyperthreading: 2 logical CPUs real memory = 1072300032 (1022 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000003ec6dfff, 1040486400 bytes (254025 pages) avail memory = 1040547840 (992 MB) bios32: Found BIOS32 Service Directory header at 0xc00f0000 bios32: Entry = 0xf0010 (c00f0010) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x31 pnpbios: Found PnP BIOS data at 0xc00f7b00 pnpbios: Entry = f0000:879a Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io:
mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000094 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27708086) pcibios: BIOS version 2.10 Found $PIR table, 14 entries at 0xc00f7990 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 1 A 0x60 3 4 5 6 7 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 10 11 12 14 15 embedded 0 1 C 0x62 3 4 5 6 7 10 11 12 14 15 embedded 0 1 D 0x63 3 4 5 6 7 10 11 12 14 15 embedded 255 0 A 0x60 3 4 5 6 7 10 11 12 14 15 embedded 0 30 A 0x60 3 4 5 6 7 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 10 11 12 14 15 embedded 0 28 A 0x60 3 4 5 6 7 10 11 12 14 15 embedded 0 28 B 0x61 3 4 5 6 7 10 11 12 14 15 embedded 0 28 C 0x62 3 4 5 6 7 10 11 12 14 15 embedded 0 28 D 0x63 3 4 5 6 7 10 11 12 14 15 embedded 1 8 A 0x68 3 4 5 6 7 10 11 12 14 15 embedded 0 31 A 0x62 3 4 5 6 7 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 10 11 12 14 15 embedded 0 31 D 0x63 3 4 5 6 7 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 10 11 12 14 15 embedded 0 2 B 0x61 3 4 5 6 7 10 11 12 14 15 embedded 0 29 A 0x68 3 4 5 6 7 10 11 12 14 15 embedded 0 29 B 0x61 3 4 5 6 7 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 10 11 12 14 15 embedded 0 29 D 0x63 3 4 5 6 7 10 11 12 14 15 embedded 0 27 A 0x63 3 4 5 6 7 10 11 12 14 15 slot 1 3 0 A 0x60 3 4 5 6 7 10 11 12 14 15 slot 1 3 0 B 0x61 3 4 5 6 7 10 11 12 14 15 slot 1 3 0 C 0x62 3 4 5 6 7 10 11 12 14 15 slot 1 3 0 D 0x63 3 4 5 6 7 10 11 12 14 15 embedded 2 0 A 0x61 3 4 5 6 7 10 11 12 14 15 slot 1 1 9 A 0x69 3 4 5 6 7 10 11 12 14 15 slot 1 1 9 B 0x6a 3 4 5 6 7 10 11 12 14 15 slot 1 1 9 C 0x6b 3 4 5 6 7 10 11 12 14 15 slot 1 1 9 D 0x68 3 4 5 6 7 10 11 12 14 15 slot 2 1 10 A 0x6a 3 4 5 6 7 10 11 12 14 15 slot 2 1 10 B 0x6b 3 4 5 6 7 10 11 12 14 15 slot 2 1 10 C 0x68 3 4 5 6 7 10 11 12 14 15 slot 2 1 10 D 0x69 3 4 5 6 7 10 11 12 14 15 embedded 1 4 A 0x63 3 4 5 6 7 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 2 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: irq 10 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: irq 7 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 7 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 7 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: irq 3 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: irq 5 on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: irq 0 on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: irq 0 on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: irq 0 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x810 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2770, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2772, revid=0x02 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base cfd80000, size 19, enabled map[14]: type 4, range 32, base 0000a400, size 3, enabled map[18]: type 3, range 32, base d0000000, size 28, enabled map[1c]: type 1, range 32, base cfe80000, size 18, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.LNKA:0) pcib0: slot 2 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x8086, dev=0x2776, revid=0x02 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base cfe00000, size 19, enabled found-> vendor=0x8086, dev=0x27d0, revid=0x01 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=4 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 pcib0: matched entry for 0.28.INTA (src \\_SB_.LNKA:0) pcib0: slot 28 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x8086, dev=0x27d2, revid=0x01 bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=4 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 pcib0: matched entry for 0.28.INTB (src \\_SB_.LNKB:0) pcib0: slot 28 INTB routed to irq 10 via \\_SB_.LNKB found-> vendor=0x8086, dev=0x27c8, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type 4, range 32, base 0000a800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKE:0) pcib0: slot 29 INTA routed to irq 5 via \\_SB_.LNKE found-> vendor=0x8086, dev=0x27c9, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 0000b000, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.LNKB:0) pcib0: slot 29 INTB routed to irq 10 via \\_SB_.LNKB found-> vendor=0x8086, dev=0x27ca, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[20]: type 4, range 32, base 0000b400, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.LNKC:0) pcib0: slot 29 INTC routed to irq 7 via \\_SB_.LNKC found-> vendor=0x8086, dev=0x27cb, revid=0x01 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=3 map[20]: type 4, range 32, base 0000b800, size 5, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.LNKD:0) pcib0: slot 29 INTD routed to irq 3 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x27cc, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base cfeffc00, size 10, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKE:0) pcib0: slot 29 INTA routed to irq 5 via \\_SB_.LNKE found-> vendor=0x8086, dev=0x244e, revid=0xe1 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c0, revid=0x01 bus=0, slot=31, func=2 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x27da, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 map[20]: type 4, range 32, base 00000400, size 5, enabled pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pcib1: irq 11 at device 28.0 on pci0 pcib1: secondary bus 3 pcib1: subordinate bus 3 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfff00000-0xfffff pcib1: prefetched decode 0xfff00000-0xfffff pci3: on pcib1 pci3: physical bus=3 pcib2: irq 10 at device 28.1 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xcff00000-0xcfffffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x8086, dev=0x108b, revid=0x03 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=4 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base cffe0000, size 17, enabled pcib2: (null) requested memory range 0xcffe0000-0xcfffffff: good map[18]: type 4, range 32, base 0000d800, size 5, enabled pcib2: (null) requested I/O range 0xd800-0xd81f: in range pcib2: matched entry for 2.0.INTA (src \\_SB_.LNKB:0) pcib2: slot 0 INTA routed to irq 10 via \\_SB_.LNKB em0: port 0xd800-0xd81f mem 0xcffe0000-0xcfffffff irq 10 at device 0.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xcffe0000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xd800 em0: [MPSAFE] em0: bpf attached em0: Ethernet address: 00:13:d4:46:b3:cb em0: Speed:N/A Duplex:N/A uhci0: port 0xa800-0xa81f irq 5 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xa800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 10 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb400-0xb41f irq 7 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xb800-0xb81f irq 3 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xcfeffc00-0xcfefffff irq 5 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xcfeffc00 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pcib3: secondary bus 1 pcib3: subordinate bus 1 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfff00000-0xfffff pcib3: prefetched decode 0xfff00000-0xfffff pcib3: Subtractively decoded bridge. pci1: on pcib3 pci1: physical bus=1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 atapci0: failed to enable memory mapping! ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=01 ostat0=80 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=80 ostat1=00 ata1: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 3200396304 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad0: 381554MB at ata0-master SATA150 ad0: 781422768 sectors [775221C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad2: 476940MB at ata1-master SATA150 ad2: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue ad2: Intel check1 failed ad2: Adaptec check1 failed adGEOM: new disk ad2 2: LSI (v3) check1 failed ad2: LSI (v2) check1 failed ad2: FreeBSD check1 failed ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init em0: Link is up 100 Mbps Full Duplex em0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 14:09:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A86F716A41F for ; Fri, 14 Oct 2005 14:09:18 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0313443D48 for ; Fri, 14 Oct 2005 14:09:17 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5E503.dip.t-dialin.net [84.165.229.3]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j9EDppXN014705; Fri, 14 Oct 2005 15:51:52 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j9EE91xb095796; Fri, 14 Oct 2005 16:09:01 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by netchild.homeip.net (Horde MIME library) with HTTP; Fri, 14 Oct 2005 16:09:00 +0200 Message-ID: <20051014160900.cmf5q9foggowk00w@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 14 Oct 2005 16:09:00 +0200 From: Alexander Leidinger To: Milan Obuch References: <200510061321.35170.current@dino.sk> <200510131551.46397.jhb@freebsd.org> <200510140652.01440.current@dino.sk> In-Reply-To: <200510140652.01440.current@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: pcf module 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, 14 Oct 2005 14:09:18 -0000 Milan Obuch wrote: > So, the question remains - is anybody out there using pcf devices to confirm > this really works? For me it compiles and kldloads, but I have no real device > to test real functionality. I use a pcf device, but on a FreeBSD 4-stable system. I may update the machine sometime in the future... maybe in one or two months. Bze, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Real programmers don't grumble about the disadvantages of Cobol when they don't know any other language. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 15:00:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78EE016A420 for ; Fri, 14 Oct 2005 15:00:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5CB943D5A for ; Fri, 14 Oct 2005 15:00:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9EEv6ij089763; Fri, 14 Oct 2005 08:57:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 14 Oct 2005 08:58:16 -0600 (MDT) Message-Id: <20051014.085816.104604949.imp@bsdimp.com> To: B.Candler@pobox.com From: "M. Warner Losh" In-Reply-To: <20051014091004.GC18513@uk.tiscali.com> References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 14 Oct 2005 08:57:27 -0600 (MDT) Cc: max@love2party.net, freebsd-current@freebsd.org, anderson@centtech.com Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 15:00:55 -0000 In message: <20051014091004.GC18513@uk.tiscali.com> Brian Candler writes: : On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote: : > > I don't think you can measure one single interger (or 64bit) increase in face : > > of a operation that has to access backing store. Even if there is a : > > performance hit, you don't have to build your kernel with the option enabled. : > : > The one thing I'd be worried about here is that 64bit updates are : > expensive on 32bit machines if you want them to be atomic. Relative to : > backing store they probably still don't matter, but the might be : > noticable. : : I'd be grateful if you could clarify that point for me. Are you saying that : if I write : : long long foo; : ... : foo++; : : then the C compiler generates code for 'foo++' which is not thread-safe? : (And therefore I would have to protect it with a mutex or critical section) : : Or are you saying that the C compiler inserts its own code around foo++ to : turn it into a critical section, and therefore runs less efficiently than : you'd expect? You have to protect this thread-unsafe operation yourself. Warner From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:20:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F1D16A41F for ; Fri, 14 Oct 2005 16:20:41 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE34343D5C for ; Fri, 14 Oct 2005 16:20:38 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j9EGKO5i090379; Fri, 14 Oct 2005 11:20:24 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434FDAB2.7040402@centtech.com> Date: Fri, 14 Oct 2005 11:20:02 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <20051014.085816.104604949.imp@bsdimp.com> In-Reply-To: <20051014.085816.104604949.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1134/Fri Oct 14 03:07:44 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: max@love2party.net, freebsd-current@freebsd.org, B.Candler@pobox.com Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 16:20:41 -0000 M. Warner Losh wrote: > In message: <20051014091004.GC18513@uk.tiscali.com> > Brian Candler writes: > : On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote: > : > > I don't think you can measure one single interger (or 64bit) increase in face > : > > of a operation that has to access backing store. Even if there is a > : > > performance hit, you don't have to build your kernel with the option enabled. > : > > : > The one thing I'd be worried about here is that 64bit updates are > : > expensive on 32bit machines if you want them to be atomic. Relative to > : > backing store they probably still don't matter, but the might be > : > noticable. > : > : I'd be grateful if you could clarify that point for me. Are you saying that > : if I write > : > : long long foo; > : ... > : foo++; > : > : then the C compiler generates code for 'foo++' which is not thread-safe? > : (And therefore I would have to protect it with a mutex or critical section) > : > : Or are you saying that the C compiler inserts its own code around foo++ to > : turn it into a critical section, and therefore runs less efficiently than > : you'd expect? > > You have to protect this thread-unsafe operation yourself. For statistics gathering purposes though, should I worry about this, or go for 'fast and imperfect' instead of 'perfect and slow'? With filesystems, I think it's more important to leave performance high and get a notion of the statistics, rather than impact performance for perfect stats (that you may only look at occasionally anyhow). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:23:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BDE716A41F for ; Fri, 14 Oct 2005 16:23:36 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99ED943D46 for ; Fri, 14 Oct 2005 16:23:35 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j9EGNYR4090410; Fri, 14 Oct 2005 11:23:34 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434FDB70.5040701@centtech.com> Date: Fri, 14 Oct 2005 11:23:12 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <9523.1129234887@critter.freebsd.dk> In-Reply-To: <9523.1129234887@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1134/Fri Oct 14 03:07:44 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 16:23:36 -0000 Poul-Henning Kamp wrote: > In message <434EB85A.9030308@centtech.com>, Eric Anderson writes: > >>Poul-Henning Kamp wrote: > > >>>I would far to prefer to see a generic method that would work >>>on all filesystems types, rather than a ufs specific tool. >>> >>>If you added counting code to the VOP_FOO() expansions, you should >>>be able to gather statistics for all filesystem types. >>> >>>The collection could be controlled by a mount option if the impact >>>is too big. >> >>That's an idea I thought of as well, but wanted to start small, since I >>really am new to C programming. Now that I've done this part, I'll look >>at the various vop_* pieces and see if it's something in my grasp. > > > I'd prefer for us to not commit a ufs-only solution, that would be > enough to hold off a filesystem independent solution. True, I see your point. >>From what it sounds like, you'd also like to see per-mount point stats, >>but from the vfs layer, right? If that's true, then do you have any >>suggestions on how to store the statistics for each mounted fs? > > > In struct mount ? Ok - so I'd place my struct vfsstats in the mount struct, so each fs records it's own stats if the mount option is enabled. (reiterating to make sure I'm understanding correctly) Also - is it best to increment the counters at the beginning of the operation, end, or something else? For ufsstat, I placed it at the end, but for some operations, if they fail, the do not get recorded. This may be what we want - only record completed ops, or maybe we want to record all requested operations, completed or not. What are thoughts on this? Thanks.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:34:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 818D116A41F for ; Fri, 14 Oct 2005 16:34:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE91843D48 for ; Fri, 14 Oct 2005 16:34:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35445 invoked from network); 14 Oct 2005 16:04:39 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Oct 2005 16:04:39 -0000 Message-ID: <434FDE2B.8090502@freebsd.org> Date: Fri, 14 Oct 2005 18:34:51 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Eric Anderson References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <20051014.085816.104604949.imp@bsdimp.com> <434FDAB2.7040402@centtech.com> In-Reply-To: <434FDAB2.7040402@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 16:34:58 -0000 Eric Anderson wrote: > M. Warner Losh wrote: > >> In message: <20051014091004.GC18513@uk.tiscali.com> >> Brian Candler writes: >> : On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote: >> : > > I don't think you can measure one single interger (or 64bit) >> increase in face : > > of a operation that has to access backing >> store. Even if there is a : > > performance hit, you don't have to >> build your kernel with the option enabled. >> : > : > The one thing I'd be worried about here is that 64bit updates are >> : > expensive on 32bit machines if you want them to be atomic. >> Relative to >> : > backing store they probably still don't matter, but the might be >> : > noticable. >> : : I'd be grateful if you could clarify that point for me. Are you >> saying that >> : if I write >> : : long long foo; >> : ... >> : foo++; >> : : then the C compiler generates code for 'foo++' which is not >> thread-safe? >> : (And therefore I would have to protect it with a mutex or critical >> section) >> : : Or are you saying that the C compiler inserts its own code around >> foo++ to >> : turn it into a critical section, and therefore runs less efficiently >> than >> : you'd expect? >> >> You have to protect this thread-unsafe operation yourself. > > > For statistics gathering purposes though, should I worry about this, or > go for 'fast and imperfect' instead of 'perfect and slow'? With > filesystems, I think it's more important to leave performance high and > get a notion of the statistics, rather than impact performance for > perfect stats (that you may only look at occasionally anyhow). If you make it a #define macro then you can leave the choice for the compile time. Fast and lose when i++ and safe and slow when atomic_inc(&i, 1). -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:37:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 835AD16A41F for ; Fri, 14 Oct 2005 16:37:44 +0000 (GMT) (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 2B4FB43D46 for ; Fri, 14 Oct 2005 16:37:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 7B159BC66; Fri, 14 Oct 2005 16:37:42 +0000 (UTC) To: Eric Anderson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Oct 2005 11:23:12 CDT." <434FDB70.5040701@centtech.com> Date: Fri, 14 Oct 2005 18:37:42 +0200 Message-ID: <32027.1129307862@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Current Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 16:37:44 -0000 In message <434FDB70.5040701@centtech.com>, Eric Anderson writes: >Poul-Henning Kamp wrote: >>>From what it sounds like, you'd also like to see per-mount point stats, >>>but from the vfs layer, right? If that's true, then do you have any >>>suggestions on how to store the statistics for each mounted fs? >> >> >> In struct mount ? > >Ok - so I'd place my struct vfsstats in the mount struct, so each fs >records it's own stats if the mount option is enabled. (reiterating to >make sure I'm understanding correctly) Or, depending if this is easier, have the VOP_FOO() functions increment the stats if the mountpoint flag is set. >Also - is it best to increment the counters at the beginning of the >operation, end, or something else? The only difference is that at the end you can also record the return code and make a counter for "failure" if you want. -- 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 Fri Oct 14 16:44:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2975216A41F for ; Fri, 14 Oct 2005 16:44:54 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FC0C43D58 for ; Fri, 14 Oct 2005 16:44:53 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id j9EGiqOZ091627; Fri, 14 Oct 2005 09:44:53 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <434FE079.6010408@freebsd.org> Date: Fri, 14 Oct 2005 09:44:41 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antony Mawer References: <434F4846.4020101@mawer.org> In-Reply-To: <434F4846.4020101@mawer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: make installworld fails on -CURRENT from 13 Oct 2005 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 16:44:54 -0000 I just committed a fix for this. Let me know if it's still broken. Tim Antony Mawer wrote: > It looks as though there's a problem with the recent libarchive checkin > here: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libarchive/Makefile?rev=1.40&content-type=text/x-cvsweb-markup > > > When trying to upgrade a 6.0-RC1 machien to -CURRENT, I get the following: > > ===> lib/libarchive (install) > printf: not found > "/usr/src/lib/libarchive/Makefile", line 28: warning: "printf > "%d.%02d.%03d" 1 2 36" returned non-zero status > expr: not found > "/usr/src/lib/libarchive/Makefile", line 31: warning: "expr 1 + 2" > returned non-zero status > install -C -o root -g wheel -m 444 libarchive.a /usr/lib > install -C -o root -g wheel -m 444 libarchive_p.a /usr/lib > install -s -o root -g wheel -m 444 libarchive.so. /usr/lib > install: libarchive.so.: No such file or directory > *** Error code 71 > > Stop in /usr/src/lib/libarchive. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > This is on (after rebooting with the new kernel): > > FreeBSD antgproxy.gptech.com.au 7.0-CURRENT FreeBSD 7.0-CURRENT #15: Fri > Oct 14 04:22:17 EST 2005 > root@antgproxy.gptech.com.au:/usr/obj/usr/src/sys/GPROXY6 i386 > > Cheers > Antony > > > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:46:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66EC516A420 for ; Fri, 14 Oct 2005 16:46:42 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C40443D45 for ; Fri, 14 Oct 2005 16:46:41 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 5C9622205; Fri, 14 Oct 2005 12:47:03 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id D38E98B; Fri, 14 Oct 2005 12:46:58 -0400 (EDT) Received: from brian by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EQShR-0005IV-0A; Fri, 14 Oct 2005 17:46:29 +0100 Date: Fri, 14 Oct 2005 17:46:28 +0100 From: Brian Candler To: Eric Anderson Message-ID: <20051014164628.GA20338@uk.tiscali.com> References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <20051014.085816.104604949.imp@bsdimp.com> <434FDAB2.7040402@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434FDAB2.7040402@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: max@love2party.net, freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 16:46:42 -0000 On Fri, Oct 14, 2005 at 11:20:02AM -0500, Eric Anderson wrote: > For statistics gathering purposes though, should I worry about this, or > go for 'fast and imperfect' instead of 'perfect and slow'? With > filesystems, I think it's more important to leave performance high and > get a notion of the statistics, rather than impact performance for > perfect stats (that you may only look at occasionally anyhow). Losing the odd count probably isn't a problem, but I think there's the possibility of a badly wrong value if you're updating a 64-bit word in two halves. For example, it might be possible to wrap around from 00000000ffffffff to 0000000000000000 instead of 0000000100000000. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 17:01:15 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2AEC16A41F for ; Fri, 14 Oct 2005 17:01:15 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from core.inec.ru (core.inec.ru [213.148.3.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E29643D53 for ; Fri, 14 Oct 2005 17:01:15 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [213.85.81.137] (helo=[192.168.0.3]) by core.inec.ru with esmtp (Exim 4.51 (FreeBSD)) id 1EQSv6-0007cq-II for current@FreeBSD.org; Fri, 14 Oct 2005 21:00:36 +0400 Message-ID: <434FE45C.4060409@FreeBSD.org> Date: Fri, 14 Oct 2005 21:01:16 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051001) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: wlan_wep and screen flicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 17:01:16 -0000 Hi. It's quite weird and even magic, but when I've made 'kldload wlan_wep' on a notebook, my screen (in text mode) started flicker when I move a mouse cursor. 6.0-RC1 -- Sem. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 17:41:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B49E716A41F for ; Fri, 14 Oct 2005 17:41:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BEA443D66 for ; Fri, 14 Oct 2005 17:41:15 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j9EHfAmt011343; Fri, 14 Oct 2005 12:41:11 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434FEDA1.4060803@centtech.com> Date: Fri, 14 Oct 2005 12:40:49 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <20051014.085816.104604949.imp@bsdimp.com> <434FDAB2.7040402@centtech.com> <20051014164628.GA20338@uk.tiscali.com> In-Reply-To: <20051014164628.GA20338@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1134/Fri Oct 14 03:07:44 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: max@love2party.net, freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 17:41:18 -0000 Brian Candler wrote: > On Fri, Oct 14, 2005 at 11:20:02AM -0500, Eric Anderson wrote: > >>For statistics gathering purposes though, should I worry about this, or >>go for 'fast and imperfect' instead of 'perfect and slow'? With >>filesystems, I think it's more important to leave performance high and >>get a notion of the statistics, rather than impact performance for >>perfect stats (that you may only look at occasionally anyhow). > > > Losing the odd count probably isn't a problem, but I think there's the > possibility of a badly wrong value if you're updating a 64-bit word in two > halves. For example, it might be possible to wrap around from > 00000000ffffffff to 0000000000000000 instead of 0000000100000000. I suppose one could argue that this problem is no worse than using 32bit integers, except it would be right more often than not. (right?) Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 17:56:59 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E21C16A420; Fri, 14 Oct 2005 17:56:59 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC32843D5E; Fri, 14 Oct 2005 17:56:58 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9EHuahT054866; Fri, 14 Oct 2005 10:56:40 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510141756.j9EHuahT054866@gw.catspoiler.org> Date: Fri, 14 Oct 2005 10:56:36 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200510132325.j9DNPBif052696@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: mi+mx@aldan.algebra.com, freebsd-current@FreeBSD.org, re@FreeBSD.org, kris@obsecurity.org Subject: Re: 6.0 hangs (while building OOo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 17:56:59 -0000 On 13 Oct, Don Lewis wrote: > The bug is that once we have unlocked pdp, another thread can do a > lookup and overwrite dp->i_ino, so instead of getting the vnode for the > ".." directory entry, VFS_VGET() will return the vnode for a > subdirectory of the current directory, and when we relock the current > directory we'll have a lock order reversal. > > Even if this doesn't result in a deadlock, it looks like it has the > potential for mucking up lookups that involve "..". I also don't > currently see a way for this to become a vnode lock leak. I think the leak happens when dp->i_ino gets overwritten by the inode number for ".". This causes ufs_lookup() to recurse on the lock for the current directory vnode (the lock is first acquired by VFS_VGET() and then recursed by vn_lock()). This isn't expected by lookup(), which compares whether the vnode returned by VOP_LOOKUP() is the same as the directory vnode and uses this information to decide whether to call vput() or vrele(). > The fix is to preserve a copy of dp->d_ino before unlocking pdp, > and pass the saved value to VFS_VGET(). > > Index: sys/ufs/ufs/ufs_lookup.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_lookup.c,v > retrieving revision 1.77 > diff -u -r1.77 ufs_lookup.c > --- sys/ufs/ufs/ufs_lookup.c 13 Apr 2005 10:59:09 -0000 1.77 > +++ sys/ufs/ufs/ufs_lookup.c 13 Oct 2005 23:20:59 -0000 > @@ -153,6 +153,7 @@ > int flags = cnp->cn_flags; > int nameiop = cnp->cn_nameiop; > struct thread *td = cnp->cn_thread; > + u_int32_t saved_ino; > > bp = NULL; > slotoffset = -1; > @@ -557,8 +558,9 @@ > */ > pdp = vdp; > if (flags & ISDOTDOT) { > + saved_ino = dp->i_ino; > VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ > - error = VFS_VGET(pdp->v_mount, dp->i_ino, > + error = VFS_VGET(pdp->v_mount, saved_ino, > cnp->cn_lkflags, &tdp); > vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); > if (error) From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 18:12:38 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6525C16A43B; Fri, 14 Oct 2005 18:12:38 +0000 (GMT) (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 CC18143D4C; Fri, 14 Oct 2005 18:12:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9EICVB4075939; Fri, 14 Oct 2005 14:12:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9EICWJ1073387; Fri, 14 Oct 2005 14:12:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4BF5A7302F; Fri, 14 Oct 2005 14:12:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051014181232.4BF5A7302F@freebsd-current.sentex.ca> Date: Fri, 14 Oct 2005 14:12:32 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Fri, 14 Oct 2005 18:12:38 -0000 TB --- 2005-10-14 16:06:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-14 16:06:02 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-10-14 16:06:02 - cleaning the object tree TB --- 2005-10-14 16:06:19 - checking out the source tree TB --- 2005-10-14 16:06:19 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-10-14 16:06:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-14 16:13:12 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-14 16:13:12 - cd /src TB --- 2005-10-14 16:13:12 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-10-14 17:44:06 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 17:44:06 - cd /src TB --- 2005-10-14 17:44:06 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Oct 14 17:44:06 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Fri Oct 14 18:00:17 UTC 2005 TB --- 2005-10-14 18:00:17 - generating LINT kernel config TB --- 2005-10-14 18:00:17 - cd /src/sys/amd64/conf TB --- 2005-10-14 18:00:17 - /usr/bin/make -B LINT TB --- 2005-10-14 18:00:17 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 18:00:17 - cd /src TB --- 2005-10-14 18:00:17 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 14 18:00:17 UTC 2005 >>> 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 -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /src/sys/amd64/linux32/linux32_locore.s cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/amd64/linux32/linux32_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/amd64/linux32/linux32_sysent.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/amd64/linux32/linux32_sysvec.c /src/sys/amd64/linux32/linux32_sysvec.c: In function `linux_rt_sendsig': /src/sys/amd64/linux32/linux32_sysvec.c:299: warning: long unsigned int format, different type arg (arg 6) /src/sys/amd64/linux32/linux32_sysvec.c: In function `linux_sendsig': /src/sys/amd64/linux32/linux32_sysvec.c:445: warning: long unsigned int format, different type arg (arg 6) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-14 18:12:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-14 18:12:32 - ERROR: failed to build lint kernel TB --- 2005-10-14 18:12:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 18:44:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 556FF16A421 for ; Fri, 14 Oct 2005 18:44:39 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id E91CA43D62 for ; Fri, 14 Oct 2005 18:44:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:01:00 -0400 From: John Baldwin To: Andrew Gallatin Date: Fri, 14 Oct 2005 14:28:45 -0400 User-Agent: KMail/1.8.2 References: <17218.49812.271334.154595@grasshopper.cs.duke.edu> <200510131530.16376.jhb@freebsd.org> <17230.49819.985757.378764@grasshopper.cs.duke.edu> In-Reply-To: <17230.49819.985757.378764@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141428.46595.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: lockmgr: thread <..> unlocking unheld 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: Fri, 14 Oct 2005 18:44:39 -0000 On Thursday 13 October 2005 04:24 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Wednesday 05 October 2005 02:00 pm, Andrew Gallatin wrote: > > > It also seems to have started happening on a second amd64 that I just > > > upgraded from a mid-august -current to CVS cvsupped yesterday. This > > > is a UP amd64 3000+.. > > > > Can you try reverting any of the recent changes to > > amd64/include/atomic.h? The ones to change foo_ptr() to take uintptr_t > > should be fine, but maybe try reverting the changes after that (not > > using +m for example). > > Inline asm is Greek to me, and I'd be no better than a monkey typing > at making changes like that. > > Would you like me to just try reverting all of 1.38? > > Drew Yes, that would work fine. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 18:45:02 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31D8416A41F; Fri, 14 Oct 2005 18:45:02 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EB7343D45; Fri, 14 Oct 2005 18:45:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:01:00 -0400 From: John Baldwin To: Don Lewis Date: Fri, 14 Oct 2005 14:33:11 -0400 User-Agent: KMail/1.8.2 References: <200510141756.j9EHuahT054866@gw.catspoiler.org> In-Reply-To: <200510141756.j9EHuahT054866@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141433.12987.jhb@freebsd.org> Cc: mi+mx@aldan.algebra.com, freebsd-current@freebsd.org, re@freebsd.org, kris@obsecurity.org Subject: Re: 6.0 hangs (while building OOo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 18:45:02 -0000 On Friday 14 October 2005 01:56 pm, Don Lewis wrote: > On 13 Oct, Don Lewis wrote: > > The bug is that once we have unlocked pdp, another thread can do a > > lookup and overwrite dp->i_ino, so instead of getting the vnode for the > > ".." directory entry, VFS_VGET() will return the vnode for a > > subdirectory of the current directory, and when we relock the current > > directory we'll have a lock order reversal. > > > > Even if this doesn't result in a deadlock, it looks like it has the > > potential for mucking up lookups that involve "..". I also don't > > currently see a way for this to become a vnode lock leak. > > I think the leak happens when dp->i_ino gets overwritten by the inode > number for ".". This causes ufs_lookup() to recurse on the lock for the > current directory vnode (the lock is first acquired by VFS_VGET() and > then recursed by vn_lock()). This isn't expected by lookup(), which > compares whether the vnode returned by VOP_LOOKUP() is the same as the > directory vnode and uses this information to decide whether to call > vput() or vrele(). > > > The fix is to preserve a copy of dp->d_ino before unlocking pdp, > > and pass the saved value to VFS_VGET(). > > > > Index: sys/ufs/ufs/ufs_lookup.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_lookup.c,v > > retrieving revision 1.77 > > diff -u -r1.77 ufs_lookup.c > > --- sys/ufs/ufs/ufs_lookup.c 13 Apr 2005 10:59:09 -0000 1.77 > > +++ sys/ufs/ufs/ufs_lookup.c 13 Oct 2005 23:20:59 -0000 > > @@ -153,6 +153,7 @@ > > int flags = cnp->cn_flags; > > int nameiop = cnp->cn_nameiop; > > struct thread *td = cnp->cn_thread; > > + u_int32_t saved_ino; > > > > bp = NULL; > > slotoffset = -1; > > @@ -557,8 +558,9 @@ > > */ > > pdp = vdp; > > if (flags & ISDOTDOT) { > > + saved_ino = dp->i_ino; > > VOP_UNLOCK(pdp, 0, td); /* race to get the inode */ > > - error = VFS_VGET(pdp->v_mount, dp->i_ino, > > + error = VFS_VGET(pdp->v_mount, saved_ino, > > cnp->cn_lkflags, &tdp); > > vn_lock(pdp, LK_EXCLUSIVE | LK_RETRY, td); > > if (error) Sounds good to me. Good sleuthing! -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:30:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A0D216A41F; Fri, 14 Oct 2005 19:30:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2044743D67; Fri, 14 Oct 2005 19:30:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:46:46 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 14:59:01 -0400 User-Agent: KMail/1.8.2 References: <200510061321.35170.current@dino.sk> <200510131551.46397.jhb@freebsd.org> <200510140652.01440.current@dino.sk> In-Reply-To: <200510140652.01440.current@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510141459.03112.jhb@freebsd.org> Cc: Milan Obuch , joerg@freebsd.org Subject: Re: pcf module 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, 14 Oct 2005 19:30:23 -0000 X-List-Received-Date: Fri, 14 Oct 2005 19:30:23 -0000 On Friday 14 October 2005 12:51 am, Milan Obuch wrote: > On Thursday 13 October 2005 21:51, John Baldwin wrote: > > On Thursday 06 October 2005 07:21 am, Milan Obuch wrote: > > ... > > > > Then I checked pcf module and found the same behavior. If you have no > > > 'device iicbus' in kernel configuration, issuing 'kldload pcf' gives > > > link_elf: symbol iicbus_intr undefined > > > kldload: can't load pcf: No such file or directory. > > > > > > Adding 'device iibus' into kernel configuration and rebuilding kernel > > > fixes this, so it looks like symbol is just not exported. > > ... > > > > Anyway, is anybody out there using pcf? There is some work done in th= is > > > area, but not yet linked into main tree. I have not pcf hardware, so I > > > can not test anything in this area, but it would be good to make the > > > transition from older i386/isa/pcf.c to new dev/pcf/... > > > > Sounds like it is missing a 'MODULE_DEPEND(iicbus, 1, 1, 1);' line. =A0= Can > > you try adding one and seeing if it fixes the kldload of pcf? > > Bingo! > > Actually, it is 'MODULE_DEPEND(pcf_isa, iicbus, 1, 1, 1);', at least with > 6.0-RC1, after looking elsewhere I added 'MODULE_VERSION(pcf_isa, 1);' as > well. Those ones are not written literally at other places, but > nevertheless, this works. I don't think you need the MODULE_VERSION line, just the one depend, and ye= s,=20 you would need the pcf_isa part. > Still, transition from 'sys/i386/isa/pcf.c' to '/sys/dev/pcf/*' solves th= is > isue as well, because there it is already fixed. Ah, I thought you were referring to moving the driver earlier, not that it = was=20 in both places. It looks like joerg@ is the person to ask about that=20 actually as he was in charge of moving the driver over. Joerg, is there an= y=20 reason we can't just switch over to sys/dev/pcf and remove sys/i386/isa/pcf= =2Ec=20 at this point? > > With Makefile changed to > > .PATH: =A0 =A0 =A0 =A0 =A0${.CURDIR}/../../../../dev/pcf > KMOD =A0 =A0 =A0 =A0 =A0 =A0=3D pcf > SRCS =A0 =A0 =A0 =A0 =A0 =A0=3D device_if.h bus_if.h iicbus_if.h isa_if.h= \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pcf.c pcf_isa.c > > .include > > it just works. I changed directly Makefile > in /sr/src/sys/modules/i2c/controllers/pcf, just for test, so maybe this = is > not enough, however, it works. > > So, the question remains - is anybody out there using pcf devices to > confirm this really works? For me it compiles and kldloads, but I have no > real device to test real functionality. > > And the other question - is anybody out there using i2c devices at all? If > so, I would like to hear about their experiences. This area seems to be n= ot > covered anywhere. Googling for 'freebsd i2c' and similar does not reveal > anything interesting for me... =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:30:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D234316A41F for ; Fri, 14 Oct 2005 19:30:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7124D43D69 for ; Fri, 14 Oct 2005 19:30:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:46:47 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 15:02:15 -0400 User-Agent: KMail/1.8.2 References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> In-Reply-To: <20051013155511.GA1748@mail.crypta.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141502.16653.jhb@freebsd.org> Cc: Andy Hilker Subject: Re: FreeBSD 6.0-RC1 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, 14 Oct 2005 19:30:24 -0000 On Thursday 13 October 2005 11:55 am, Andy Hilker wrote: > Hi, > > > > Announcement > > > ------------ > > > > > > The release engineering team is proud to announce the availability of > > > FreeBSD 6.0. > > [...] > > > > We encourage everyone to help with testing so any final bugs can be > > > identified and worked out. Availability of ISO images is given below. > > Is it possible to include this minor patch for rc-ng scripts? It > ist present since 5.3 or earlier... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/82430 Why does the process name have []'s around it? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:30:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D934816A41F for ; Fri, 14 Oct 2005 19:30:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1735D43D69 for ; Fri, 14 Oct 2005 19:30:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:46:48 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 15:28:42 -0400 User-Agent: KMail/1.8.2 References: <434F5176.2060704@nurfuerspam.de> In-Reply-To: <434F5176.2060704@nurfuerspam.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141528.42998.jhb@freebsd.org> Cc: Martin Subject: Re: panic: RELENG_6 BETA5 in atpic_handle_intr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 19:30:26 -0000 On Friday 14 October 2005 02:34 am, Martin wrote: > Hi, > > I've seen a panic on my Thinkpad (R40) after it has been > idle for one hour at night (cpufreq and powerd is in use). > > The trace shows: > Fatal trap 1: privileged instruction fault while in kernel mode > processor eflags = resume, IOPL=0 > current process: 11 (idle) > > atpic_handle_intr() > acpi_cpu_idle() > idle_proc() > fork_exit() > fork_trampoline() > > Martin That is certainly a very weird panic, though I'd really need to see the full panic messages if you ever get a chance to reproduce it. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:30:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7A7516A41F for ; Fri, 14 Oct 2005 19:30:26 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A83843D67 for ; Fri, 14 Oct 2005 19:30:23 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:46:47 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 15:17:16 -0400 User-Agent: KMail/1.8.2 References: <434D9B4A.7080909@clearchain.com> In-Reply-To: <434D9B4A.7080909@clearchain.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141517.16934.jhb@freebsd.org> Cc: Benjamin Close Subject: Re: 6.0-RC1 Panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:30:26 -0000 On Wednesday 12 October 2005 07:24 pm, Benjamin Close wrote: > Hi All, > I can repeatedly get this panic at boot if I have my wi0 (802.11b > Lucent / Hermes chipset) card in my laptop. > > Fatal trap 18: integer divide fault while in kernel mode > instruction pointer = 0x20:0xc06474fa > stack pointer = 0x28:0xd9927c78 > frame pointer = 0x28:0xd9927c88 > 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 = 242 (netstat) > trap number = 18 > panic: integer divide fault > Uptime: 3m32s > Dumping 511 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 511MB (130794 pages) 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 > > Full Details below... Hmm, so it looks like maybe your ipfw.ko KLD doesn't have a DT_HASH section. Try doing an objdump of your ipfw.ko and see if it has a .hash. Here's the objdump from the ipfw.ko on my laptop: > objdump -h /boot/kernel.GENERIC/ipfw.ko | head /boot/kernel.GENERIC/ipfw.ko: file format elf32-i386-freebsd Sections: Idx Name Size VMA LMA File off Algn 0 .hash 00000348 00000094 00000094 00000094 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 000006f0 000003dc 000003dc 000003dc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 00000439 00000acc 00000acc 00000acc 2**0 Note the .hash as the first section. You can also try this patch which might fix the problem (though your ipfw.ko still won't load): Index: kern/link_elf.c =================================================================== RCS file: /usr/cvs/src/sys/kern/link_elf.c,v retrieving revision 1.84 diff -u -r1.84 link_elf.c --- kern/link_elf.c 28 Aug 2005 04:50:11 -0000 1.84 +++ kern/link_elf.c 14 Oct 2005 19:16:48 -0000 @@ -1019,6 +1019,12 @@ unsigned long hash; int i; + /* If we don't have a hash, bail. */ + if (ef->buckets == NULL || ef->nbuckets == 0) { + printf("link_elf_lookup_symbol: missing symbol hash table\n"); + return ENOENT; + } + /* First, search hashed global symbols */ hash = elf_hash(name); symnum = ef->buckets[hash % ef->nbuckets]; -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:30:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5A7B16A41F; Fri, 14 Oct 2005 19:30:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1353343D67; Fri, 14 Oct 2005 19:30:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 15:46:47 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 14 Oct 2005 15:27:32 -0400 User-Agent: KMail/1.8.2 References: <200510140013.j9E0DVNu052772@gw.catspoiler.org> In-Reply-To: <200510140013.j9E0DVNu052772@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141527.33406.jhb@freebsd.org> Cc: Don Lewis , emoe@cox.net Subject: Re: Kernel panic: "spec nodes went here" in 6.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: Fri, 14 Oct 2005 19:30:28 -0000 On Thursday 13 October 2005 08:13 pm, Don Lewis wrote: > On 13 Oct, Erik Moe wrote: > > This may be a known issue, but I haven't found much discussion on > > it. I'm playing with 6.0-RC1 and the kernel test suite. Within > > minutes of running the suite I get a kernel panic: "spec nodes went > > here". This seems to happen consistently. The panic happens in > > ffsext_strategy(), but it looks like the arguments to the mkdir() > > system call are missing. > > This was fixed in HEAD with sys/ufs/ffs/ffs_alloc.c 1.136. Is this scheduled to go into 6.0? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:40:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E76C16A41F; Fri, 14 Oct 2005 19:40:47 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE61143D70; Fri, 14 Oct 2005 19:40:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4/8.13.4) with ESMTP id j9EJeYoY024833; Fri, 14 Oct 2005 12:40:34 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4/8.13.4/Submit) id j9EJeYsn024832; Fri, 14 Oct 2005 12:40:34 -0700 (PDT) Date: Fri, 14 Oct 2005 12:40:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200510141940.j9EJeYsn024832@apollo.backplane.com> To: obrien@freebsd.org References: <20050926152952.GA1670@dragon.NUXI.org> <20050926160808.GB1649@dragon.NUXI.org> Cc: freebsd-current@freebsd.org Subject: Re: [PANIC] ufs_dirbad: bad dir X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 19:40:47 -0000 :Just got another one - uptime was about 10 minutes. Is one of the recent :changes to SU & FFS making this situation easier to trigger? : :-- :-- David (obrien@FreeBSD.org) This is happening on DragonFly, too. Three people (including me) have seen it. All with different hardware/hard-disk configs. It definitely is not hardware. It does not seem to be related to a crash... it happens seemingly randomly, but often during heavy directory / filesystem use (e.g. pkgsrc builds). The one crash dump I've looked at very suspiciously shows the bad buffer at filesystem block 12 (the first INDIRECT block). The contents of the buffer looks like a random filesystem block rather then a directory block. I am going to commit Tor's patch and see if the bug reports go away. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:47:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0027E16A41F; Fri, 14 Oct 2005 19:47:10 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id F332743D58; Fri, 14 Oct 2005 19:47:08 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from localhost (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id 465501940; Fri, 14 Oct 2005 21:47:07 +0200 (MET DST) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-10) id 82476-4513818B; Fri, 14 Oct 2005 21:47:06 +0200 Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP id 8A3BE193B; Fri, 14 Oct 2005 21:46:57 +0200 (MET DST) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (Postfix) with ESMTP; Fri, 14 Oct 2005 21:46:57 +0200 (MET DST) Received: (from j@localhost) by uriah.heep.sax.de (8.13.4/8.13.1/Submit) id j9EJkuwK082472; Fri, 14 Oct 2005 21:46:56 +0200 (MET DST) (envelope-from j) Date: Fri, 14 Oct 2005 21:46:56 +0200 From: Joerg Wunsch To: John Baldwin Message-ID: <20051014194656.GD29397@uriah.heep.sax.de> Mail-Followup-To: Joerg Wunsch , John Baldwin , freebsd-current@freebsd.org, Milan Obuch References: <200510061321.35170.current@dino.sk> <200510131551.46397.jhb@freebsd.org> <200510140652.01440.current@dino.sk> <200510141459.03112.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510141459.03112.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on uriah.heep.sax.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.5 tests=none autolearn=failed version=3.0.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-10; AVE: 6.32.0.8; VDF: 6.32.0.81; host: uriah.heep.sax.de) Cc: freebsd-current@freebsd.org, Milan Obuch Subject: Re: pcf module problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:47:11 -0000 As John Baldwin wrote: > Ah, I thought you were referring to moving the driver earlier, not > that it was in both places. It looks like joerg@ is the person to > ask about that actually as he was in charge of moving the driver > over. Joerg, is there any reason we can't just switch over to > sys/dev/pcf and remove sys/i386/isa/pcf.c at this point? Not at all. ISTR Nicolas Souchu once wanted to perform some ``last cleanup actions'' before actually turning the switch, and so I eventually lost track about the issue until Milan recently reminded me. I guess Nicolas did whatever needs to be done long ago, so I'm all in favor of switching. It's only that I currently don't have any real hardware for testing it anymore, that Sun E450 I've been using by that time tends to run Solaris most of the time now, and I'd need to install a FreeBSD- current on it first before I could test anything. So if anyone else wants to switch these drivers, I don't mind. If you're really waiting for me doing it, tell me so, and I'll see to give all this a final test drive on that machine once again. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:54:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABDB716A41F; Fri, 14 Oct 2005 19:54:52 +0000 (GMT) (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 3C00F43D49; Fri, 14 Oct 2005 19:54:52 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9EJsnX2085048; Fri, 14 Oct 2005 15:54:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9EJsokx020685; Fri, 14 Oct 2005 15:54:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4AF737302F; Fri, 14 Oct 2005 15:54:50 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051014195450.4AF737302F@freebsd-current.sentex.ca> Date: Fri, 14 Oct 2005 15:54:50 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Fri, 14 Oct 2005 19:54:52 -0000 TB --- 2005-10-14 18:12:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-14 18:12:32 - starting HEAD tinderbox run for i386/i386 TB --- 2005-10-14 18:12:32 - cleaning the object tree TB --- 2005-10-14 18:12:50 - checking out the source tree TB --- 2005-10-14 18:12:50 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-10-14 18:12:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-14 18:19:38 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-14 18:19:38 - cd /src TB --- 2005-10-14 18:19:38 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-14 19:23:44 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 19:23:44 - cd /src TB --- 2005-10-14 19:23:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Oct 14 19:23:44 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Fri Oct 14 19:41:00 UTC 2005 TB --- 2005-10-14 19:41:00 - generating LINT kernel config TB --- 2005-10-14 19:41:00 - cd /src/sys/i386/conf TB --- 2005-10-14 19:41:00 - /usr/bin/make -B LINT TB --- 2005-10-14 19:41:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 19:41:00 - cd /src TB --- 2005-10-14 19:41:00 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 14 19:41:00 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/linux/linux_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/linux/linux_ptrace.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/linux/linux_sysent.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/linux/linux_sysvec.c /src/sys/i386/linux/linux_sysvec.c: In function `linux_rt_sendsig': /src/sys/i386/linux/linux_sysvec.c:290: warning: long unsigned int format, int arg (arg 6) /src/sys/i386/linux/linux_sysvec.c: In function `linux_sendsig': /src/sys/i386/linux/linux_sysvec.c:432: warning: long unsigned int format, int arg (arg 6) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-14 19:54:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-14 19:54:50 - ERROR: failed to build lint kernel TB --- 2005-10-14 19:54:50 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 20:09:27 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1A9116A425; Fri, 14 Oct 2005 20:09:27 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65BE343D49; Fri, 14 Oct 2005 20:09:27 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9EK93Fh055182; Fri, 14 Oct 2005 13:09:06 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200510142009.j9EK93Fh055182@gw.catspoiler.org> Date: Fri, 14 Oct 2005 13:09:03 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200510141527.33406.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, re@FreeBSD.org, emoe@cox.net Subject: Re: Kernel panic: "spec nodes went here" in 6.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: Fri, 14 Oct 2005 20:09:28 -0000 On 14 Oct, John Baldwin wrote: > On Thursday 13 October 2005 08:13 pm, Don Lewis wrote: >> On 13 Oct, Erik Moe wrote: >> > This may be a known issue, but I haven't found much discussion on >> > it. I'm playing with 6.0-RC1 and the kernel test suite. Within >> > minutes of running the suite I get a kernel panic: "spec nodes went >> > here". This seems to happen consistently. The panic happens in >> > ffsext_strategy(), but it looks like the arguments to the mkdir() >> > system call are missing. >> >> This was fixed in HEAD with sys/ufs/ffs/ffs_alloc.c 1.136. > > Is this scheduled to go into 6.0? I think it should, but that is for to re@ and tegge@ to decide. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 20:45:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2194516A41F; Fri, 14 Oct 2005 20:45:20 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from core.inec.ru (core.inec.ru [213.148.3.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB96B43D45; Fri, 14 Oct 2005 20:45:19 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [213.85.81.137] (helo=[192.168.0.3]) by core.inec.ru with esmtp (Exim 4.51 (FreeBSD)) id 1EQWPw-00088m-2L; Sat, 15 Oct 2005 00:44:40 +0400 Message-ID: <435018E5.5050107@FreeBSD.org> Date: Sat, 15 Oct 2005 00:45:25 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051001) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sergey Matveychuk References: <434FE45C.4060409@FreeBSD.org> In-Reply-To: <434FE45C.4060409@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: wlan_wep and screen flicker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 20:45:20 -0000 Sergey Matveychuk wrote: > Hi. > > It's quite weird and even magic, but when I've made 'kldload wlan_wep' > on a notebook, my screen (in text mode) started flicker when I move a > mouse cursor. > > 6.0-RC1 Yes, looks like it's just a coincidence. Screen flicker even if I don't load the module. -- Sem. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 21:08:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64DAF16A41F for ; Fri, 14 Oct 2005 21:08:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0279D43D46 for ; Fri, 14 Oct 2005 21:08:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 17:24:49 -0400 From: John Baldwin To: Joerg Wunsch Date: Fri, 14 Oct 2005 17:09:42 -0400 User-Agent: KMail/1.8.2 References: <200510061321.35170.current@dino.sk> <200510141459.03112.jhb@freebsd.org> <20051014194656.GD29397@uriah.heep.sax.de> In-Reply-To: <20051014194656.GD29397@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141709.43782.jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Milan Obuch Subject: Re: pcf module 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, 14 Oct 2005 21:08:36 -0000 On Friday 14 October 2005 03:46 pm, Joerg Wunsch wrote: > As John Baldwin wrote: > > Ah, I thought you were referring to moving the driver earlier, not > > that it was in both places. It looks like joerg@ is the person to > > ask about that actually as he was in charge of moving the driver > > over. Joerg, is there any reason we can't just switch over to > > sys/dev/pcf and remove sys/i386/isa/pcf.c at this point? > > Not at all. > > ISTR Nicolas Souchu once wanted to perform some ``last cleanup > actions'' before actually turning the switch, and so I eventually lost > track about the issue until Milan recently reminded me. I guess > Nicolas did whatever needs to be done long ago, so I'm all in favor of > switching. > > It's only that I currently don't have any real hardware for testing it > anymore, that Sun E450 I've been using by that time tends to run > Solaris most of the time now, and I'd need to install a FreeBSD- > current on it first before I could test anything. So if anyone else > wants to switch these drivers, I don't mind. If you're really waiting > for me doing it, tell me so, and I'll see to give all this a final > test drive on that machine once again. I don't have any of the hardware myself, I'm proxying for another user who has found that pcf works better for them (well, I'm not sure if they have hardware, but it fixes a kldload issue). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 21:12:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB4E16A41F for ; Fri, 14 Oct 2005 21:12:13 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1181B43D48 for ; Fri, 14 Oct 2005 21:12:12 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 4856AB7; Fri, 14 Oct 2005 17:10:41 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 7B603617C; Fri, 14 Oct 2005 17:10:37 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EQWqS-0005UJ-SP; Fri, 14 Oct 2005 22:12:05 +0100 Date: Fri, 14 Oct 2005 22:12:04 +0100 From: Brian Candler To: Eric Anderson Message-ID: <20051014211204.GA21070@uk.tiscali.com> References: <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu> <20051014091004.GC18513@uk.tiscali.com> <20051014.085816.104604949.imp@bsdimp.com> <434FDAB2.7040402@centtech.com> <20051014164628.GA20338@uk.tiscali.com> <434FEDA1.4060803@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434FEDA1.4060803@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: max@love2party.net, freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: ufsstat - testers / feedback wanted! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 21:12:13 -0000 On Fri, Oct 14, 2005 at 12:40:49PM -0500, Eric Anderson wrote: > >Losing the odd count probably isn't a problem, but I think there's the > >possibility of a badly wrong value if you're updating a 64-bit word in two > >halves. For example, it might be possible to wrap around from > >00000000ffffffff to 0000000000000000 instead of 0000000100000000. > > I suppose one could argue that this problem is no worse than using 32bit > integers, except it would be right more often than not. (right?) Well, then it's perhaps better just to have a 32 bit counter in the first place - and the client which reads it _knows_ it has to deal with wraparound itself. If you were graphing rates of filesystem operations via SNMP, for example, that would be fine. Having a 64 bit value is nice if you want to see the total number of operations since you rebooted your machine 3 years ago - but that's arguably more for interest sake than for anything practical. Still, losing 2^32 counts when the above error occurs would make that value even less useful and potentially very misleading. Personally, I think I would err on the side of accurate counters, which can disabled entirely (e.g. via compile-time option or FS mount option), rather than having inaccurate counters. There must be lots of other cases in the kernel of stats counters (e.g. network interface stats) - how do they treat the same problem? Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 21:12:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABA7816A41F; Fri, 14 Oct 2005 21:12:14 +0000 (GMT) (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 3CB7443D48; Fri, 14 Oct 2005 21:12:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9ELCDaX049668; Fri, 14 Oct 2005 17:12:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9ELCDvm032123; Fri, 14 Oct 2005 17:12:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0A86B7302F; Fri, 14 Oct 2005 17:12:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051014211212.0A86B7302F@freebsd-current.sentex.ca> Date: Fri, 14 Oct 2005 17:12:12 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Fri, 14 Oct 2005 21:12:14 -0000 TB --- 2005-10-14 19:54:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-14 19:54:50 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-10-14 19:54:50 - cleaning the object tree TB --- 2005-10-14 19:55:20 - checking out the source tree TB --- 2005-10-14 19:55:20 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-10-14 19:55:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-14 20:01:50 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-14 20:01:50 - cd /src TB --- 2005-10-14 20:01:50 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-14 21:05:33 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 21:05:33 - cd /src TB --- 2005-10-14 21:05:33 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Oct 14 21:05:34 UTC 2005 >>> 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 [...] /src/sys/pc98/pc98/machdep.c:1879: error: invalid application of `sizeof' to incomplete type `({anonymous})' /src/sys/pc98/pc98/machdep.c:1895: error: invalid application of `sizeof' to incomplete type `({anonymous})' /src/sys/pc98/pc98/machdep.c: In function `init386': /src/sys/pc98/pc98/machdep.c:1983: error: `__pcpu' undeclared (first use in this function) /src/sys/pc98/pc98/machdep.c:2168: error: `proc0_tf' undeclared (first use in this function) /src/sys/pc98/pc98/machdep.c: At top level: /src/sys/pc98/pc98/machdep.c:154: warning: 'cpu_startup' used but never defined /src/sys/pc98/pc98/machdep.c:210: warning: 'freebsd4_sendsig' defined but not used *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-14 21:12:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-14 21:12:12 - ERROR: failed to build generic kernel TB --- 2005-10-14 21:12:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 21:20:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B88DF16A41F; Fri, 14 Oct 2005 21:20:50 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6BA43D45; Fri, 14 Oct 2005 21:20:44 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9ELKhgQ005997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 17:20:43 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9ELKcBZ013740; Fri, 14 Oct 2005 17:20:38 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17232.8486.199356.888297@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 17:20:38 -0400 (EDT) To: John Baldwin In-Reply-To: <200510141428.46595.jhb@freebsd.org> References: <17218.49812.271334.154595@grasshopper.cs.duke.edu> <200510131530.16376.jhb@freebsd.org> <17230.49819.985757.378764@grasshopper.cs.duke.edu> <200510141428.46595.jhb@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: lockmgr: thread <..> unlocking unheld 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: Fri, 14 Oct 2005 21:20:50 -0000 John Baldwin writes: > On Thursday 13 October 2005 04:24 pm, Andrew Gallatin wrote: > > John Baldwin writes: > > > On Wednesday 05 October 2005 02:00 pm, Andrew Gallatin wrote: > > > > It also seems to have started happening on a second amd64 that I just > > > > upgraded from a mid-august -current to CVS cvsupped yesterday. This > > > > is a UP amd64 3000+.. > > > > > > Can you try reverting any of the recent changes to > > > amd64/include/atomic.h? The ones to change foo_ptr() to take uintptr_t > > > should be fine, but maybe try reverting the changes after that (not > > > using +m for example). > > > > Inline asm is Greek to me, and I'd be no better than a monkey typing > > at making changes like that. > > > > Would you like me to just try reverting all of 1.38? > > > > Drew > > Yes, that would work fine. I just did a pair of buildworlds, and a portsnap fetch & update, and got 11 of those messages. So it looks like it wasn't your atomic changes. Drew From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 21:47:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 851C316A41F for ; Fri, 14 Oct 2005 21:47:10 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B1743D45 for ; Fri, 14 Oct 2005 21:47:09 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 14 Oct 2005 18:03:25 -0400 From: John Baldwin To: Andrew Gallatin Date: Fri, 14 Oct 2005 17:48:20 -0400 User-Agent: KMail/1.8.2 References: <17218.49812.271334.154595@grasshopper.cs.duke.edu> <200510141428.46595.jhb@freebsd.org> <17232.8486.199356.888297@grasshopper.cs.duke.edu> In-Reply-To: <17232.8486.199356.888297@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510141748.21113.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: lockmgr: thread <..> unlocking unheld 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: Fri, 14 Oct 2005 21:47:10 -0000 On Friday 14 October 2005 05:20 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Thursday 13 October 2005 04:24 pm, Andrew Gallatin wrote: > > > John Baldwin writes: > > > > On Wednesday 05 October 2005 02:00 pm, Andrew Gallatin wrote: > > > > > It also seems to have started happening on a second amd64 that I > > > > > just upgraded from a mid-august -current to CVS cvsupped > > > > > yesterday. This is a UP amd64 3000+.. > > > > > > > > Can you try reverting any of the recent changes to > > > > amd64/include/atomic.h? The ones to change foo_ptr() to take > > > > uintptr_t should be fine, but maybe try reverting the changes after > > > > that (not using +m for example). > > > > > > Inline asm is Greek to me, and I'd be no better than a monkey typing > > > at making changes like that. > > > > > > Would you like me to just try reverting all of 1.38? > > > > > > Drew > > > > Yes, that would work fine. > > I just did a pair of buildworlds, and a portsnap fetch & update, and > got 11 of those messages. So it looks like it wasn't your atomic > changes. > > Drew Ok, just wanted to make sure. Thanks for testing. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 22:09:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B45B16A41F for ; Fri, 14 Oct 2005 22:09:12 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4255743D45 for ; Fri, 14 Oct 2005 22:09:12 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so475034wxc for ; Fri, 14 Oct 2005 15:09:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EUv9n2DmrSY46y/jFvKbfF4x3Gl+IVhiG3arTIrnlubG37qO7z9OygwtDvcmgAlkJ5BJIqkHUFOSgDSoLUkGdGcoOlZMOyrAF1vOBRaV7Nu9ZZR3H3agcOxrJJaWcIikW6nCnX6G+/YdPywGq0XmJAyXuDrR0pOGWiBEJ3JlEmY= Received: by 10.70.69.20 with SMTP id r20mr1466920wxa; Fri, 14 Oct 2005 15:09:11 -0700 (PDT) Received: by 10.70.76.10 with HTTP; Fri, 14 Oct 2005 15:09:11 -0700 (PDT) Message-ID: <25e9cd010510141509n9815829nc5c5a6a300e6f684@mail.gmail.com> Date: Sat, 15 Oct 2005 00:09:11 +0200 From: Mischa Peters To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: FreeBSD 6.0RC1 with ICH6R 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, 14 Oct 2005 22:09:12 -0000 Hi All, I am trying to get my Raid1 rebuild root:~ # atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED root:~ # atacontrol rebuild ar0 atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error Any idea why I get input/output error? root~ # atacontrol list ATA channel 0: Master: acd0 ATA/ATAPI revision 0 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 Serial ATA v1.0 Slave: no device present ATA channel 3: Master: ad6 Serial ATA v1.0 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present Thanx!! Mischa From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 22:13:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E691916A41F for ; Fri, 14 Oct 2005 22:13:19 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 846BA43D45 for ; Fri, 14 Oct 2005 22:13:19 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so475393wxc for ; Fri, 14 Oct 2005 15:13:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XVeRJdtcHkPBp4II8Eze9fPB4MeORNwQ9eADAPOCvEu1I/qSmw7nL0RY/qhwCQWCUXMiYlz9xD8rsdYs0bnRRgikbQcAN8beWVNXsqsu6rQpbs+mz7EwMkFGprV+MMcNC42YQHWZGxjAYBTBa3kErDY7jmylATK0jUtwbKxgCM0= Received: by 10.70.104.11 with SMTP id b11mr1473617wxc; Fri, 14 Oct 2005 15:13:19 -0700 (PDT) Received: by 10.70.76.10 with HTTP; Fri, 14 Oct 2005 15:13:19 -0700 (PDT) Message-ID: <25e9cd010510141513j5d982857u2ca97fe22fe730ec@mail.gmail.com> Date: Sat, 15 Oct 2005 00:13:19 +0200 From: Mischa Peters To: freebsd-current@freebsd.org In-Reply-To: <25e9cd010510141509n9815829nc5c5a6a300e6f684@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <25e9cd010510141509n9815829nc5c5a6a300e6f684@mail.gmail.com> Subject: Re: FreeBSD 6.0RC1 with ICH6R 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, 14 Oct 2005 22:13:20 -0000 I don't normally reply to my own mail but I guess this is the problem. ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode ar0: writing of Intel MatrixRAID metadata is NOT supported yet subdisk6: detached ad6: detached ad6: 238475MB at ata3-master SATA150 ad6: Intel calc=3D87617cd3 meta=3D4430be6a No MatrixRAID metadata... :( Mischa On 10/15/05, Mischa Peters wrote: > Hi All, > > I am trying to get my Raid1 rebuild > > root:~ # atacontrol status ar0 > ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED > > root:~ # atacontrol rebuild ar0 > atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error > > Any idea why I get input/output error? > > root~ # atacontrol list > ATA channel 0: > Master: acd0 ATA/ATAPI revision 0 > Slave: no device present > ATA channel 1: > Master: no device present > Slave: no device present > ATA channel 2: > Master: ad4 Serial ATA v1.0 > Slave: no device present > ATA channel 3: > Master: ad6 Serial ATA v1.0 > Slave: no device present > ATA channel 4: > Master: no device present > Slave: no device present > ATA channel 5: > Master: no device present > Slave: no device present > > Thanx!! > > Mischa > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 22:30:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3408216A41F; Fri, 14 Oct 2005 22:30:09 +0000 (GMT) (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 B778543D45; Fri, 14 Oct 2005 22:30:08 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9EMU79T059416; Fri, 14 Oct 2005 18:30:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9EMU7tE026440; Fri, 14 Oct 2005 18:30:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 718BD7302F; Fri, 14 Oct 2005 18:30:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051014223007.718BD7302F@freebsd-current.sentex.ca> Date: Fri, 14 Oct 2005 18:30:07 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Fri, 14 Oct 2005 22:30:09 -0000 TB --- 2005-10-14 21:12:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-14 21:12:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-10-14 21:12:13 - cleaning the object tree TB --- 2005-10-14 21:12:37 - checking out the source tree TB --- 2005-10-14 21:12:37 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-10-14 21:12:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-14 21:19:55 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-14 21:19:55 - cd /src TB --- 2005-10-14 21:19:55 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-14 22:24:14 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-14 22:24:14 - cd /src TB --- 2005-10-14 22:24:14 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Oct 14 22:24:14 UTC 2005 >>> 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 -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/support.S cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/sys_machdep.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/swtch.S cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/tick.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/tlb.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/trap.c /src/sys/sparc64/sparc64/trap.c: In function `trap': /src/sys/sparc64/sparc64/trap.c:292: error: structure has no member named `ksi_trap' *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-14 22:30:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-14 22:30:07 - ERROR: failed to build generic kernel TB --- 2005-10-14 22:30:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 22:48:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 115C616A41F; Fri, 14 Oct 2005 22:48:25 +0000 (GMT) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C3343D46; Fri, 14 Oct 2005 22:48:24 +0000 (GMT) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id 4C4C5ECD43D; Sat, 15 Oct 2005 00:48:57 +0200 (CEST) Date: Sat, 15 Oct 2005 00:48:57 +0200 From: Andy Hilker To: John Baldwin Message-ID: <20051014224856.GB73118@mail.crypta.net> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> <200510141502.16653.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510141502.16653.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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, 14 Oct 2005 22:48:25 -0000 Hi, > > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/82430 > > Why does the process name have []'s around it? Thanks for your reply. >From "man ps": If the command vector cannot be located (usually because it has not been set, as is the case of system processes and/or kernel threads) the command name is printed within square brackets. I have this behaviour with mysqld, the bug reporter with clamd. Running mysqld jailed, the process name is ok and not in brackets. bye, Andy From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 23:27:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B198616A41F for ; Fri, 14 Oct 2005 23:27:05 +0000 (GMT) (envelope-from freebsd@psam.se) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD20143D45 for ; Fri, 14 Oct 2005 23:26:59 +0000 (GMT) (envelope-from freebsd@psam.se) Received: from caspian ([85.228.2.87] [85.228.2.87]) by mxfep02.bredband.com with ESMTP id <20051014232657.NUKH11792.mxfep02.bredband.com@caspian>; Sat, 15 Oct 2005 01:26:57 +0200 Received: from [127.0.0.1] ([85.228.2.90]) (authenticated user peter@psam.se) by caspian (Kerio MailServer 6.1.0); Sat, 15 Oct 2005 01:27:04 +0200 Message-ID: <43503EB8.7040509@psam.se> Date: Sat, 15 Oct 2005 01:26:48 +0200 From: Psadi User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <434E538F.80000@psam.se> <20051013.213943.05622321.imp@bsdimp.com> In-Reply-To: <20051013.213943.05622321.imp@bsdimp.com> Content-Type: multipart/mixed; boundary="------------040508070400080305000203" X-Antivirus: avast! (VPS 0541-3, 2005-10-14), Outbound message X-Antivirus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Thoshiba Tecra 8000 with 3com 3CXFE575CT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 23:27:05 -0000 This is a multi-part message in MIME format. --------------040508070400080305000203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit M. Warner Losh skrev: >In message: <434E538F.80000@psam.se> > Psadi writes: >: I had decided to try FreeBSD 6.0 on my laptop. After I installed it >: beta4 I recived alot of xl0: watchdog timeout every time I try to use >: the internet. > >Interrupts aren't being routed correctly. You need to fix that. >There's a tiny chance it is in your hardware setup, but since prior >versions work, I'd guess this is the case. You'll need to save the >dmesg from 6.0 and from 5.4 and compare the too. Sadly, the Tecra >8000 moniker was used by a lot of different laptops. Mine just works >w/o any issues. > >: At startup I see that I get CARDBUS1: Resource not specified in CIS: >: id=14, size=80 > >Ignore these. Generally they are just noise. > >: I added in pccard.conf that it should use IRQ 3,5,10,15 though when I >: look it still uses 11 > >pccard.conf is completely ignored. > >: What else can I try or do to get more info for those that needs it? > >Put the laptop in my hands, and I'll fix it :-). Otherwise, we'll >have to start with boot -v dmesgs from working and broken systems. > >Warner > > > > I have taken a dmesg -v from both a fresh installed 5.4 and 6.0RC1 I will attach them instead of posting them If there is more info needed let me know. If I try and install through ftp from the CD with FreeBSD 6.0RC1 I also get the xl0:watchdog timeout. I do not recive them at all in 5.4 Peter --------------040508070400080305000203 Content-Type: text/plain; name="dmesg6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg6.txt" Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a88000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a881a8. Calibrating clock(s) ... i8254 clock: 1193154 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 299942800 Hz CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134152192 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000007d77fff, 118829056 bytes (29011 pages) avail memory = 121733120 (116 MB) bios32: Found BIOS32 Service Directory header at 0xc00fbe90 bios32: Entry = 0xfc4c0 (c00fc4c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x1987 pnpbios: Found PnP BIOS data at 0xc00fed00 pnpbios: Entry = f0000:92c6 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 7933f351 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 pci_link1: irq 11 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 pci_link3: irq 11 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 ACPI timer: 0/8 0/6 0/6 0/4 0/6 0/5 0/6 0/6 0/6 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0 cpu0: on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71928086) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00f1320 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 11 A 0x60 11 embedded 0 11 B 0x61 11 embedded 0 9 A 0x62 11 embedded 0 4 A 0x62 11 embedded 0 4 B 0x63 11 embedded 0 13 A 0x63 11 embedded 0 5 D 0x63 11 slot 1 0 6 A 0x62 11 slot 1 0 6 B 0x63 11 slot 1 0 6 C 0x60 11 slot 1 0 6 D 0x61 11 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e0000000, size 28, enabled found-> vendor=0x10c8, dev=0x0005, revid=0x20 bus=0, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base df000000, size 24, enabled map[14]: type 1, range 32, base ff800000, size 22, enabled map[18]: type 1, range 32, base ff700000, size 20, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.LNKC:0) pcib0: slot 4 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=5, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=5, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000fe60, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=5, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 0000ffe0, size 5, enabled pcib0: matched entry for 0.5.INTD (src \\_SB_.LNKD:0) pcib0: slot 5 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=5, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type 4, range 32, base 0000fe70, size 4, enabled found-> vendor=0x1179, dev=0x0701, revid=0x23 bus=0, slot=9, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0400, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 4, range 32, base 0000ff80, size 5, enabled pcib0: matched entry for 0.9.INTA (src \\_SB_.LNKC:0) pcib0: slot 9 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x1179, dev=0x060a, revid=0x07 bus=0, slot=11, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 1, range 32, base 00000000, size 12, memory disabled pcib0: matched entry for 0.11.INTA (src \\_SB_.LNKA:0) pcib0: slot 11 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x1179, dev=0x060a, revid=0x07 bus=0, slot=11, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0480, cach --------------040508070400080305000203 Content-Type: text/plain; name="dmesg5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg5.txt" Copyright (c) 1992-2005 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 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134152192 (127 MB) avail memory = 117444608 (112 MB) npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) isab0: at device 5.0 on pci0 isa0: on isab0 atapci0: port 0xfe60-0xfe6f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 5.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xffe0-0xffff irq 11 at device 5.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 5.3 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: irq 11 at device 11.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 11 at device 11.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci0: at device 13.0 (no driver attached) acpi_lid0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: port 0x778-0x77a,0x378-0x37a irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/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 orm0: at iomem 0xe8000-0xebfff,0xc0000-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 299942793 Hz quality 800 Timecounters tick every 10.000 msec md0: Preloaded image 4423680 bytes at 0xc09dde24 cardbus1: Resource not specified in CIS: id=14, size=80 cardbus1: Resource not specified in CIS: id=18, size=80 xl0: <3Com 3c575C Fast Etherlink XL> port 0x1000-0x107f mem 0x88000000-0x8800007f,0x88000080-0x880000ff irq 11 at device 0.0 on cardbus1 miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:00:86:51:81:f8 ad0: 19077MB [38760/16/63] at ata0-master UDMA33 acd0: DVDROM at ata1-master PIO4 Mounting root from ufs:/dev/md0 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...6 4 1 1 1 0 0 done No buffers busy after final sync Uptime: 17m57s Shutting down ACPI Rebooting... Copyright (c) 1992-2005 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 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a36000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a36278. Calibrating clock(s) ... i8254 clock: 1193140 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 299942368 Hz CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134152192 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000007d7ffff, 118861824 bytes (29019 pages) avail memory = 121626624 (115 MB) bios32: Found BIOS32 Service Directory header at 0xc00fbe90 bios32: Entry = 0xfc4c0 (c00fc4c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x1987 pnpbios: Found PnP BIOS data at 0xc00fed00 pnpbios: Entry = f0000:92c6 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 7933f351 Other BIOS signatures found: wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: Power Button (fixed) ACPI timer: 0/16777214 0/6 0/16777214 0/16777186 0/6 0/6 0/6 0/7 0/16777211 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0 cpu0: on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71928086) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00f1320 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 11 A 0x60 11 embedded 0 11 B 0x61 11 embedded 0 9 A 0x62 11 embedded 0 4 A 0x62 11 embedded 0 4 B 0x63 11 embedded 0 13 A 0x63 11 embedded 0 5 D 0x63 11 slot 1 0 6 A 0x62 11 slot 1 0 6 B 0x63 11 slot 1 0 6 C 0x60 11 slot 1 0 6 D 0x61 11 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.11.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.11.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.9.0 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.4.0 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.4.1 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.13.0 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.5.3 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.6.0 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 10 11 12] 11+ low,level,sharable 0.6.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 28, enabled found-> vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base df000000, size 24, enabled map[14]: type 1, range 32, base ff800000, size 22, enabled map[18]: type 1, range 32, base ff700000, size 20, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 4, priority 12885): interrupts: 11 10 5 12 7 6 4 3 penalty: 90 90 140 5090 5090 5090 5090 5090 \\_SB_.LNKC (references 3, priority 9663): interrupts: 11 10 5 12 7 6 4 3 penalty: 90 90 140 5090 5090 5090 5090 5090 \\_SB_.LNKA (references 1, priority 3221): interrupts: 11 10 5 12 7 6 4 3 penalty: 90 90 140 5090 5090 5090 5090 5090 \\_SB_.LNKB (references 1, priority 3221): interrupts: 11 10 5 12 7 6 4 3 penalty: 90 90 140 5090 5090 5090 5090 5090 pcib0: slot 4 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x10c8, dev=0x0005, revid=0x20 bus=0, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=5, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000fe60, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=5, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffe0, size 5, enabled pcib0: matched entry for 0.5.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 4, priority 13260): interrupts: 10 11 5 12 7 6 4 3 penalty: 180 210 230 5180 5180 5180 5180 5180 \\_SB_.LNKA (references 1, priority 3315): interrupts: 10 11 5 12 7 6 4 3 penalty: 180 210 230 5180 5180 5180 5180 5180 \\_SB_.LNKB (references 1, priority 3315): interrupts: 10 11 5 12 7 6 4 3 penalty: 180 210 230 5180 5180 5180 5180 5180 pcib0: slot 5 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=5, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 0000fe70, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=5, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000ff80, size 5, enabled pcib0: matched entry for 0.9.INTA (src \\_SB_.LNKC) pcib0: slot 9 INTA is already routed to irq 11 found-> vendor=0x1179, dev=0x0701, revid=0x23 bus=0, slot=9, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0400, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 1, range 32, base 00000000, size 12, memory disabled pcib0: matched entry for 0.11.INTA (src \\_SB_.LNKA) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 1, priority 3410): interrupts: 10 5 11 12 7 6 4 3 penalty: 270 320 340 5270 5270 5270 5270 5270 \\_SB_.LNKB (references 1, priority 3410): interrupts: 10 5 11 12 7 6 4 3 penalty: 270 320 340 5270 5270 5270 5270 5270 pcib0: slot 11 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x1179, dev=0x060a, revid=0x07 bus=0, slot=11, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 1, range 32, base 00000000, size 12, memory disabled pcib0: matched entry for 0.11.INTB (src \\_SB_.LNKB) pcib0: possible interrupts: 3 4 5 6 7 10 11 12 ACPI PCI link arbitrated settings: \\_SB_.LNKB (references 1, priority 3501): interrupts: 10 5 11 12 7 6 4 3 penalty: 360 410 440 5360 5360 5360 5360 5360 pcib0: slot 11 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=0x1179, dev=0x060a, revid=0x07 bus=0, slot=11, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[10]: type 4, range 32, base 0000ee00, size 8, enabled pcib0: matched entry for 0.13.INTA (src \\_SB_.LNKD) pcib0: slot 13 INTA is already routed to irq 11 found-> vendor=0x123f, dev=0x8888, revid=0x02 bus=0, slot=13, func=0 class=04-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 pci0: at device 4.0 (no driver attached) PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 5.0 on pci0 isa0: on isab0 atapci0: port 0xfe60-0xfe6f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 5.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfe60 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x04 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xffe0-0xffff irq 11 at device 5.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xffe0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 5.3 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: irq 11 at device 11.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x060a1179 0x04800007 0x06070007 0x00820000 0x10: 0x80000000 0x04800000 0x00141400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0400010b 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x01000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x860010f0 0x00000002 0x00000000 0x0000d100 0xb0: 0x3f3f3fcf 0x0a081020 0x00010100 0x000003f1 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000008 cbb1: irq 11 at device 11.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0x060a1179 0x04800007 0x06070007 0x00820000 0x10: 0x80001000 0x04800000 0x00151500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0400020b 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x01000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x860020f0 0x00000002 0x00000000 0x0000d100 0xb0: 0x3f3f3fcf 0x0a081020 0x00010100 0x000003f1 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000008 pci0: at device 13.0 (no driver attached) acpi_lid0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 80 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x1 0x11 0x11 0x11 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP SPP ppc0: port 0x778-0x77a,0x378-0x37a irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed fe unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xe8000-0xebfff,0xc0000-0xcbfff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 299942368 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached acpi_cmbat0: battery initialization start acpi_cmbat1: battery initialization start acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times cardbus1: Resource not specified in CIS: id=14, size=80 cardbus1: Resource not specified in CIS: id=18, size=80 found-> vendor=0x10b7, dev=0x5257, revid=0x10 bus=21, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 xl0: <3Com 3c575C Fast Etherlink XL> port 0x1000-0x107f mem 0x88000000-0x8800007f,0x88000080-0x880000ff irq 11 at device 0.0 on cardbus1 xl0: using port I/O xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 11 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:00:86:51:81:f8 xl0: [MPSAFE] ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting UDMA33 on Intel PIIX4 chip ad0: ATA-5 disk at ata0-master ad0: 19077MB (39070080 sectors), 38760 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 ar: FreeBSD check1 failed ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: DVDROM drive at ata1 as master acd0: read 3445KB/s (3445KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc GEOM: new disk ad0 [0] f:00 typ:7 s(CHS):0/1/1 e(CHS):1023/4/63 s:63 l:20482812 [1] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/15/63 s:20482875 l:18587205 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 10487199744 end 10487231999 GEOM: Configure ad0s2, start 10487232000 length 9516648960 end 20003880959 [0] f:72 typ:13 s(CHS):256/97/36 e(CHS):370/10/20 s:543908729 l:1819440195 [1] f:2b typ:43 s(CHS):372/65/44 e(CHS):364/68/37 s:1922328096 l:1953784096 [2] f:20 typ:114 s(CHS):353/115/52 e(CHS):288/116/33 s:168652143 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:-1669136384 l:49835 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad0s2a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s2b, start 268435456 length 242032640 end 510468095 GEOM: Configure ad0s2c, start 0 length 9516648960 end 9516648959 GEOM: Configure ad0s2d, start 510468096 length 268435456 end 778903551 GEOM: Configure ad0s2e, start 778903552 length 268435456 end 1047339007 GEOM: Configure ad0s2f, start 1047339008 length 8469309952 end 9516648959 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/ad0s2a start_init: trying /sbin/init acpi_cmbat0: battery initialization failed, giving up acpi_cmbat1: battery initialization failed, giving up --------------040508070400080305000203-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 00:25:02 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84EC116A41F; Sat, 15 Oct 2005 00:25:02 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: from turing.cs.hmc.edu (turing.cs.hmc.edu [134.173.42.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4440E43D45; Sat, 15 Oct 2005 00:25:02 +0000 (GMT) (envelope-from nge@cs.hmc.edu) Received: by turing.cs.hmc.edu (Postfix, from userid 26983) id 6BF6A53250; Fri, 14 Oct 2005 17:25:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turing.cs.hmc.edu (Postfix) with ESMTP id 566445A92B; Fri, 14 Oct 2005 17:24:59 -0700 (PDT) Date: Fri, 14 Oct 2005 17:24:59 -0700 (PDT) From: Nate Eldredge X-X-Sender: nate@turing To: Andy Hilker In-Reply-To: <20051014224856.GB73118@mail.crypta.net> Message-ID: References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> <200510141502.16653.jhb@freebsd.org> <20051014224856.GB73118@mail.crypta.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Sat, 15 Oct 2005 00:25:02 -0000 On Sat, 15 Oct 2005, Andy Hilker wrote: > Hi, > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/82430 >> >> Why does the process name have []'s around it? > > Thanks for your reply. > >> From "man ps": > > If the command vector cannot be located (usually because it has not > been set, as is the case of system processes and/or kernel threads) > the command name is printed within square brackets. > > I have this behaviour with mysqld, the bug reporter with clamd. > Running mysqld jailed, the process name is ok and not in brackets. Do you think this is related? I don't know as to FreeBSD specifically, but on other Unices this often happens for ordinary processes when they are swapped out. The kernel normally gets argv out of the process's memory, but if it is swapped out, it doesn't want to bother to swap it in just for that. So it gives you just the command name instead. It might be that it's just coincidence, this happened to your non-jailed process but not to your jailed one. -- Nate Eldredge nge@cs.hmc.edu From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 01:43:17 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAE4316A41F for ; Sat, 15 Oct 2005 01:43:17 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id E99FE43D46 for ; Sat, 15 Oct 2005 01:43:14 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3801B1CCDD; Sat, 15 Oct 2005 14:43:13 +1300 (NZDT) Date: Sat, 15 Oct 2005 14:43:13 +1300 From: Andrew Thompson To: FreeBSD Current Message-ID: <20051015014313.GA25990@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , FreeBSD Current Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: RC1 panic on 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: Sat, 15 Oct 2005 01:43:17 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am getting this panic on RC1, I am booting disc1 to install the system. Its a HP Omnibook 4150 and no PC cards are inserted. It has 5.4 on the drive at the moment which installed fine. I have attached a couple of dmesg logs. Andrew Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Celeron (448.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 536870912 (512 MB) avail memory = 511746048 (488 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 10 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 10 on acpi0 unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported acpi_ec0: port 0x62,0x66 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0e96b0a stack pointer = 0x28:0xc1020b7c frame pointer = 0x28:0xc1020b8c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="6.0RC1-verbose" MAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000f0c00 len=000000000000f400 SMAP type=01 base=0000000000100000 len=0000000003fe8800 SMAP type=03 base=00000000040e8800 len=0000000000007400 SMAP type=04 base=00000000040efc00 len=0000000000010000 SMAP type=01 base=00000000040ffc00 len=000000001bf00400 SMAP type=02 base=00000000ffff0c00 len=000000000000f400 Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ec0000. Preloaded mfs_root "/boot/mfsroot" at 0xc0ec0180. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ec01c4. Calibrating clock(s) ... i8254 clock: 1193023 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 448054361 Hz CPU: Intel Celeron (448.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001025000 - 0x00000000040e7fff, 51130368 bytes (12483 pages) 0x0000000004100000 - 0x000000001f6c7fff, 459046912 bytes (112072 pages) avail memory = 511746048 (488 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6f10 bios32: Entry = 0xfd790 (c00fd790) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd790+0x23b pnpbios: Found PnP BIOS data at 0xc00f6f40 pnpbios: Entry = f0000:addd Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fdf50 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 8 A 0x63 10 embedded 0 4 A 0x60 10 embedded 0 4 B 0x61 10 embedded 0 18 A 0x60 10 embedded 0 18 B 0x61 10 embedded 0 17 A 0x60 10 embedded 0 17 B 0x61 10 embedded 0 17 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 D 0x63 10 embedded 0 7 D 0x63 10 embedded 0 1 A 0x60 10 embedded 1 0 A 0x60 10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 1 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low pci_link0: irq 10 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link1: irq 10 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link2: irq 10 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: info: new max delay is 150 us acpi_ec0: info: new max delay is 300 us ACPI timer: 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x8010 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0e96b0a stack pointer = 0x28:0xc1020b7c frame pointer = 0x28:0xc1020b8c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="5.4R-verbose" Copyright (c) 1992-2005 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 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a36000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a3621c. Calibrating clock(s) ... i8254 clock: 1193030 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 448055331 Hz CPU: Intel Celeron (448.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x00000000040e7fff, 55324672 bytes (13507 pages) 0x0000000004100000 - 0x000000001f6cffff, 459079680 bytes (112080 pages) avail memory = 515600384 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6f10 bios32: Entry = 0xfd790 (c00fd790) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd790+0x23b pnpbios: Found PnP BIOS data at 0xc00f6f40 pnpbios: Entry = f0000:addd Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fdf50 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 8 A 0x63 10 embedded 0 4 A 0x60 10 embedded 0 4 B 0x61 10 embedded 0 18 A 0x60 10 embedded 0 18 B 0x61 10 embedded 0 17 A 0x60 10 embedded 0 17 B 0x61 10 embedded 0 17 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 17 D 0x63 10 embedded 0 7 D 0x63 10 embedded 0 1 A 0x60 10 embedded 1 0 A 0x60 10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 4 func 1 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported unknown: memory range not supported acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_ec0: port 0x66,0x62 on acpi0 acpi_ec0: info: new max delay is 180 us acpi_ec0: info: new max delay is 240 us ACPI timer: 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x8010 unknown: not probed (disabled) acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [10] 10+ low,level,sharable 0.7.0 \\_SB_.LNKB irq 0: [10] 10+ low,level,sharable 0.7.1 \\_SB_.LNKC irq 0: [ 3 5 7 9 10 11] 0+ low,level,sharable 0.7.2 \\_SB_.LNKD irq 0: [10] 10+ low,level,sharable 0.7.3 \\_SB_.LNKA irq 0: [10] 10+ low,level,sharable 0.4.0 \\_SB_.LNKB irq 0: [10] 10+ low,level,sharable 0.4.1 \\_SB_.LNKA irq 0: [10] 10+ low,level,sharable 0.18.0 \\_SB_.LNKB irq 0: [10] 10+ low,level,sharable 0.18.1 \\_SB_.LNKD irq 0: [10] 10+ low,level,sharable 0.8.0 \\_SB_.LNKA irq 0: [10] 10+ low,level,sharable 0.17.0 \\_SB_.LNKB irq 0: [10] 10+ low,level,sharable 0.17.1 \\_SB_.LNKC irq 0: [ 3 5 7 9 10 11] 0+ low,level,sharable 0.17.2 \\_SB_.LNKD irq 0: [10] 10+ low,level,sharable 0.17.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x001f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x8c (35000 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0xac1c, revid=0x01 bus=0, slot=4, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0xac1c, revid=0x01 bus=0, slot=4, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=b, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000fcf0, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000fcc0, size 5, port disabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 10 ACPI PCI link arbitrated settings: \\_SB_.LNKC (references 2, priority 3433): interrupts: 11 9 5 10 7 3 penalty: 20 40 70 130 5020 5020 \\_SB_.LNKA (references 4, priority 520): interrupts: 10 penalty: 130 \\_SB_.LNKB (references 4, priority 520): interrupts: 10 penalty: 130 \\_SB_.LNKD (references 3, priority 390): interrupts: 10 penalty: 130 pcib0: slot 7 INTD routed to irq 10 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[90]: type 4, range 32, base 00002180, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000f800, size 8, enabled pcib0: matched entry for 0.8.INTA (src \\_SB_.LNKD) pcib0: slot 8 INTA is already routed to irq 10 found-> vendor=0x125d, dev=0x1978, revid=0x10 bus=0, slot=8, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfd000000-0xfedfffff pcib1: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [10] 10+ low,level,sharable 1.0.0 pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base fd000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xfd000000-0xfdffffff map[14]: type 4, range 32, base 0000e800, size 8, enabled pcib1: device (null) requested decoded I/O range 0xe800-0xe8ff map[18]: type 1, range 32, base fedfe000, size 12, enabled pcib1: device (null) requested decoded memory range 0xfedfe000-0xfedfefff pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA) pcib1: possible interrupts: 10 ACPI PCI link arbitrated settings: \\_SB_.LNKC (references 2, priority 3450): interrupts: 11 9 5 10 3 7 penalty: 20 40 70 180 5020 5020 \\_SB_.LNKA (references 5, priority 900): interrupts: 10 penalty: 180 \\_SB_.LNKB (references 4, priority 720): interrupts: 10 penalty: 180 pcib1: slot 0 INTA routed to irq 10 via \\_SB_.LNKA found-> vendor=0x1002, dev=0x4c4d, revid=0x64 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) cbb0: at device 4.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: matched entry for 0.4.INTA (src \\_SB_.LNKA) pcib0: slot 4 INTA is already routed to irq 10 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac1c104c 0x02100007 0x06070001 0x00824008 0x10: 0x80000000 0x020000a0 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010a 0x40: 0x000a103c 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00449061 0x00000000 0x00000000 0x01021702 0x90: 0x406602c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e210001 0x00800000 0x00000000 0x0000001f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 4.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: matched entry for 0.4.INTB (src \\_SB_.LNKB) pcib0: possible interrupts: 10 ACPI PCI link arbitrated settings: \\_SB_.LNKC (references 2, priority 3593): interrupts: 11 9 5 10 7 3 penalty: 40 80 90 490 5040 5040 \\_SB_.LNKB (references 4, priority 1960): interrupts: 10 penalty: 490 pcib0: slot 4 INTB routed to irq 10 via \\_SB_.LNKB cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac1c104c 0x02100007 0x06070001 0x00824008 0x10: 0x80001000 0x020000a0 0x20050400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740020a 0x40: 0x000a103c 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00449061 0x00000000 0x00000000 0x01021702 0x90: 0x406602c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e210001 0x00800000 0x00000000 0x0000001f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfcf0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=00 ostat1=01 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x01 err=0x04 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=01 devices=0x4 ata1: [MPSAFE] uhci0: port 0xfcc0-0xfcdf irq 10 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xfcc0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 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 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) sio0: irq maps: 0x201 0x211 0x201 0x201 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) sio1: irq maps: 0x201 0x209 0x201 0x201 sio1 port 0x158-0x15f,0x2f8-0x2ff irq 3 drq 1 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcc7ff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 e7 73 4f 4f 97 53 84 b4 0f 00 4f 0d 0e 00 00 07 80 91 87 8f 28 1f 8f b5 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 e7 73 4f 4f 97 53 84 b4 0f 00 4f 0d 0e 00 00 07 80 91 87 8f 28 1f 8f b5 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 448055331 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_cmbat1: battery initialization start acpi_ec0: info: new max delay is 790 us ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting UDMA33 on Intel PIIX4 chip ad0: ATA-4 disk at ata0-master ad0: 4645MB (9514260 sectors), 10068 C, 15 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 ar: FreeBSD check1 failed ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 1722KB/s (4134KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acpi_ec0: info: new max delay is 11000 us acpi_cmbat0: battery initialization done, tried 3 times GEOM: new disk ad0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/14/63 s:63 l:9514197 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 4871268864 end 4871301119 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad0s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s1b, start 268435456 length 376160256 end 644595711 GEOM: Configure ad0s1c, start 0 length 4871268864 end 4871268863 GEOM: Configure ad0s1d, start 644595712 length 268435456 end 913031167 GEOM: Configure ad0s1e, start 913031168 length 268435456 end 1181466623 GEOM: Configure ad0s1f, start 1181466624 length 3689802240 end 4871268863 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Linux ELF exec handler installed acpi_ec0: info: new max delay is 21000 us found-> vendor=0x115d, dev=0x0003, revid=0x03 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 dc0: port 0x1000-0x107f mem 0x88000000-0x880007ff,0x88000800-0x88000fff irq 10 at device 0.0 on cardbus0 miibus0: on dc0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 10 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:10:a4:e9:6c:cf dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] found-> vendor=0x115d, dev=0x0103, revid=0x03 bus=2, slot=0, func=1 class=07-00-02, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 1 supports D0 D1 D2 D3 current D0 sio4: irq maps: 0x305 0x705 0x305 0x305 sio4: port 0x1080-0x1087 mem 0x88000000-0x880007ff,0x88000800-0x88000fff irq 10 at device 0.1 on cardbus0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode acpi_cmbat1: battery initialization failed, giving up --Dxnq1zWXvFF0Q93v-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 07:02:46 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB30B16A420; Sat, 15 Oct 2005 07:02:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 551E843D46; Sat, 15 Oct 2005 07:02:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 13DEB1A3C19; Sat, 15 Oct 2005 00:02:46 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 04D8051309; Sat, 15 Oct 2005 03:02:40 -0400 (EDT) Date: Sat, 15 Oct 2005 03:02:39 -0400 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20051015070239.GA50577@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: alc@FreeBSD.org Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../../vm/vm_map.c:2997 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 07:02:46 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have got this panic 3 times tonight on a 12-processor sparc64 e4500, but only once did it get as far as displaying a stack trace before hanging. WITNESS was enabled (without WITNESS_SKIPSPIN) but did not report anything. panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../../vm/vm_map.c:2997 cpuid = 3 KDB: enter: panic KDB: stack backtrace: paiic:_lrocjm atoicl croc+ x 3 foBk_sxatk)bac foak_: _fink(tr ol e ) a f tr e 0x at sched_bind+0x78 boot() at boot+0x24 panic() at panic+0x1bc longjmp() at longjmp+0x44 trap() at trap+0x220 -- fast data access mmu miss tar=0xe9f72000 %o7=0xc02f8284 -- cpu_ipi_selected() at cpu_ipi_selected+0x2c ipi_selected() at ipi_selected+0x14 stop_cpus() at stop_cpus+0x1c kdb_trap() at kdb_trap+0x64 trap() at trap+0x264 -- breakpoint %o7=0xc0191f74 -- kdb_enter() at kdb_enter+0x3c panic() at panic+0x164 _mtx_lock_sleep() at _mtx_lock_sleep+0x40 _mtx_lock_flags() at _mtx_lock_flags+0xa4 _vm_map_lock_read() at _vm_map_lock_read+0x1c vm_map_lookup() at vm_map_lookup+0x1c vm_fault() at vm_fault+0x68 trap_pfault() at trap_pfault+0x1a8 trap() at trap+0x28c -- fast data access mmu miss tar=0xe9f9a000 %o7=0xc02cea68 -- vm_map_entry_splay() at vm_map_entry_splay+0x10 vm_map_find() at vm_map_find+0x34 kmem_alloc_nofault() at kmem_alloc_nofault+0x44 pmap_pinit() at pmap_pinit+0x30 vmspace_zinit() at vmspace_zinit+0x14 slab_zalloc() at slab_zalloc+0x264 uma_zone_slab() at uma_zone_slab+0x12c uma_zalloc_bucket() at uma_zalloc_bucket+0x16c uma_zalloc_arg() at uma_zalloc_arg+0x374 vmspace_alloc() at vmspace_alloc+0x14 vmspace_fork() at vmspace_fork+0x24 vm_forkproc() at vm_forkproc+0xe4 fork1() at fork1+0xd44 fork() at fork+0x10 syscall() at syscall+0x2dc -- syscall (2, FreeBSD ELF64, fork) %o7=0x110020 -- -userland() at 0x40635568 user trace: trap %o7=0x110020 pc 0x40635568, sp 0x7fdffffd721 pc 0x106890, sp 0x7fdffffd7e1 pc 0x105fe4, sp 0x7fdffffd9a1 pc 0x107428, sp 0x7fdffffdae1 pc 0x110b88, sp 0x7fdffffdbc1 pc 0x102354, sp 0x7fdffffdce1 pc 0x40227474, sp 0x7fdffffdda1 done panic: mi_switch: did not reenter debugger cpuid = 3 KDB: stack backtrace: [At this point it looped recursively panicking for 5 minutes or so before hanging]. Kris --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDUKmPWry0BWjoQKURAs9EAKDBzwbTKVHeZKEKusC0fvYoMcilJACgvpYY 1N34ERw1sNBKpu712ZKA/wk= =lA8m -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 07:32:47 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA7DC16A41F for ; Sat, 15 Oct 2005 07:32:47 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B66E43D46 for ; Sat, 15 Oct 2005 07:32:46 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 901671CCDD; Sat, 15 Oct 2005 20:32:45 +1300 (NZDT) Date: Sat, 15 Oct 2005 20:32:45 +1300 From: Andrew Thompson To: FreeBSD Current Message-ID: <20051015073245.GA27380@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , FreeBSD Current References: <20051015014313.GA25990@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051015014313.GA25990@heff.fud.org.nz> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: RC1 panic on 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: Sat, 15 Oct 2005 07:32:47 -0000 On Sat, Oct 15, 2005 at 02:43:13PM +1300, Andrew Thompson wrote: > I am getting this panic on RC1, I am booting disc1 to install the > system. Its a HP Omnibook 4150 and no PC cards are inserted. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0e96b0a > stack pointer = 0x28:0xc1020b7c > frame pointer = 0x28:0xc1020b8c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > trap number = 12 > panic: page fault The laptop boots fine without acpi. Here is the line number for the panic. (gdb) l *acpi_pci_link_lookup+0x42 0x3ffc2 is in acpi_pci_link_lookup (/usr/src/sys/modules/acpi/acpi/../../../dev/ acpica/acpi_pci_link.c:590). 585 struct acpi_pci_link_softc *sc; 586 int i; 587 588 ACPI_SERIAL_ASSERT(pci_link); 589 sc = device_get_softc(dev); 590 for (i = 0; i < sc->pl_num_links; i++) 591 if (sc->pl_links[i].l_res_index == source_index) 592 return (&sc->pl_links[i]); 593 return (NULL); 594 } From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 07:42:21 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D78ED16A425 for ; Sat, 15 Oct 2005 07:42:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FF2543D45 for ; Sat, 15 Oct 2005 07:42:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9F7euRH097120; Sat, 15 Oct 2005 01:40:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 15 Oct 2005 01:42:08 -0600 (MDT) Message-Id: <20051015.014208.89681982.imp@bsdimp.com> To: info@martenvijn.nl From: "M. Warner Losh" In-Reply-To: <1129300467.656.22.camel@localhost.localdomain> References: <1129300467.656.22.camel@localhost.localdomain> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 15 Oct 2005 01:40:57 -0600 (MDT) Cc: beheer@lijst.wirelessleiden.nl, freebsd-current@FreeBSD.ORG Subject: Re: wi2 died on 6.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: Sat, 15 Oct 2005 07:42:22 -0000 In message: <1129300467.656.22.camel@localhost.localdomain> Marten Vijn writes: : on a soekris 4521 => wi2 died while upgrading from 6.0. Beta3 to 6.0 : rc1 : : tested diffent soekri en diffent prism (senao) cards : the probleem is reproduceable. : : a booted system shows me wi1 and wi2 when pullout both cards and put : then in place after a while. I've recreated this here. Had to upgrade the BIOS in my 4521 for it to recognize my flash, and had a number of other logistical problems that have kept me from trying to fix this bug... I also sometimes saw ad0 fail to show up when my wi1 (I have not wi card in the minipci slot) failed in the same way that yours did. Warner From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 07:48:10 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF39A16A41F; Sat, 15 Oct 2005 07:48:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 530AA43D45; Sat, 15 Oct 2005 07:48:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9F7kBA7097171; Sat, 15 Oct 2005 01:46:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 15 Oct 2005 01:47:23 -0600 (MDT) Message-Id: <20051015.014723.116855931.imp@bsdimp.com> To: thompsa@freebsd.org From: "M. Warner Losh" In-Reply-To: <20051015014313.GA25990@heff.fud.org.nz> References: <20051015014313.GA25990@heff.fud.org.nz> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 15 Oct 2005 01:46:11 -0600 (MDT) Cc: current@freebsd.org Subject: Re: RC1 panic on 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: Sat, 15 Oct 2005 07:48:10 -0000 In message: <20051015014313.GA25990@heff.fud.org.nz> Andrew Thompson writes: : Hi, : : : I am getting this panic on RC1, I am booting disc1 to install the : system. Its a HP Omnibook 4150 and no PC cards are inserted. : : It has 5.4 on the drive at the moment which installed fine. I have : attached a couple of dmesg logs. Any chance you can build a 6.0RC1 kernel with debugging enabled (ddb and kdb) and get a traceback? Warner From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 08:09:48 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F5D116A41F for ; Sat, 15 Oct 2005 08:09:48 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9994B43D46 for ; Sat, 15 Oct 2005 08:09:47 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 494761CCDD; Sat, 15 Oct 2005 21:09:46 +1300 (NZDT) Date: Sat, 15 Oct 2005 21:09:46 +1300 From: Andrew Thompson To: FreeBSD Current Message-ID: <20051015080946.GA27497@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , FreeBSD Current , "M. Warner Losh" References: <20051015014313.GA25990@heff.fud.org.nz> <20051015.014723.116855931.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051015.014723.116855931.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i Cc: "M. Warner Losh" Subject: Re: RC1 panic on 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: Sat, 15 Oct 2005 08:09:48 -0000 On Sat, Oct 15, 2005 at 01:47:23AM -0600, M. Warner Losh wrote: > In message: <20051015014313.GA25990@heff.fud.org.nz> > Andrew Thompson writes: > : Hi, > : > : > : I am getting this panic on RC1, I am booting disc1 to install the > : system. Its a HP Omnibook 4150 and no PC cards are inserted. > : > : It has 5.4 on the drive at the moment which installed fine. I have > : attached a couple of dmesg logs. > > Any chance you can build a 6.0RC1 kernel with debugging enabled (ddb > and kdb) and get a traceback? Ah yes, I was on to it. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0975fc2 stack pointer = 0x28:0xc0c20ae8 frame pointer = 0x28:0xc0c20b04 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at acpi_pci_link_lookup+0x42: movl 0(%eax),%eax db> trace Tracing pid 0 tid 0 td 0xc0817c00 acpi_pci_link_lookup(c1a49780,0,25c,c078bd41,90c) at acpi_pci_link_lookup+0x42 acpi_pci_link_add_reference(c1a49780,0,c1a76400,7,2) at acpi_pci_link_add_reference+0x34 prt_attach_devices(c1985a40,c1a76400,c1985a40,c1985a40,c0c20b9c) at prt_attach_devices+0xda prt_walk_table(c1a81734,c0971720,c1a76400,c19dbe80,c1a76400) at prt_walk_table+0x40 acpi_pcib_attach(c1a76400,c1a81734,0,c0c20bc8,c0578c5e) at acpi_pcib_attach+0xfd acpi_pcib_acpi_attach(c1a76400,c1a2f050,c07c6b58,c1a76400,c1a76400) at acpi_pcib_acpi_attach+0x289 device_attach(c1a76400,c1a76400,c078bd41,90c,c0c20c34) at device_attach+0x6a device_probe_and_attach(c1a76400,c19dbc00,c0c20c54,c096d87a,c19dbe80) at device_probe_and_attach+0x111 bus_generic_attach(c19dbe80,ffffffff,64,c096d950,c19dbe80) at bus_generic_attach+0x28 acpi_probe_children(c19dbe80,c0970240,c19dbc00,0,1a4) at acpi_probe_children+0x5a acpi_attach(c19dbe80,c1a24850,c07c6b58,c19dbe80,c19dbe80) at acpi_attach+0x838 device_attach(c19dbe80,c19dbe80,c078bd41,90c,c0c20cfc) at device_attach+0x6a device_probe_and_attach(c19dbe80,c1989780,c0c20d0c,c074266a,c1989780) at device_probe_and_attach+0x111 bus_generic_attach(c1989780,c1989780,c0c20d2c,c0573d6a,c1989780) at bus_generic_attach+0x28 nexus_attach(c1989780,c1a15050,c07c6b58,c1989780,c1989780) at nexus_attach+0x1a device_attach(c1989780,c1989780,c078bd41,90c,2) at device_attach+0x6a device_probe_and_attach(c1989780,c197e950,c0c20d70,c0732dfc,c0992324) at device_probe_and_attach+0x111 root_bus_configure(c0992324,c0c20d88,c0527085,0,c1e000) at root_bus_configure+0x28 configure(0,c1e000,c1ec00,c1e000,0) at configure+0xc mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db> show locks exclusive sx ACPI PCI link r = 0 (0xc0991b40) locked @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci_link.c:604 exclusive sleep mutex Giant r = 0 (0xc0819b20) locked @ /usr/src/sys/geom/geom_kern.c:168 (gdb) l *acpi_pci_link_lookup+0x42 0x3ffc2 is in acpi_pci_link_lookup (/usr/src/sys/modules/acpi/acpi/../../../dev/ acpica/acpi_pci_link.c:590). 585 struct acpi_pci_link_softc *sc; 586 int i; 587 588 ACPI_SERIAL_ASSERT(pci_link); 589 sc = device_get_softc(dev); 590 for (i = 0; i < sc->pl_num_links; i++) 591 if (sc->pl_links[i].l_res_index == source_index) 592 return (&sc->pl_links[i]); 593 return (NULL); 594 } From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 08:33:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5E1716A421; Sat, 15 Oct 2005 08:33:56 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD4F643D58; Sat, 15 Oct 2005 08:33:55 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 3D8CA1F02; Sat, 15 Oct 2005 04:34:18 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id D68F08B; Sat, 15 Oct 2005 04:34:15 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1EQhUC-00063N-BI; Sat, 15 Oct 2005 09:33:48 +0100 Date: Sat, 15 Oct 2005 09:33:48 +0100 From: Brian Candler To: John Baldwin Message-ID: <20051015083348.GA23073@uk.tiscali.com> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> <200510141502.16653.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510141502.16653.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Andy Hilker , freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Sat, 15 Oct 2005 08:33:57 -0000 On Fri, Oct 14, 2005 at 03:02:15PM -0400, John Baldwin wrote: > > Is it possible to include this minor patch for rc-ng scripts? It > > ist present since 5.3 or earlier... > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/82430 > > Why does the process name have []'s around it? If the total length of the command line (argv strings) is longer than kern.ps_arg_cache_limit, which defaults to 256, then this is what you'll see. `ps` shows just the command name in [] and no arguments. I've noticed this with courier-imap, for example, which has a very long command line. So I've done sysctl kern.ps_arg_cache_limit=512 on my courier-imap boxes to be able to see the full line. Equally, if you want to demonstrate this to yourself for testing purposes, try setting it to something a lot smaller, and then starting some new processes. I also think that a process which is started with an empty argv[] array will be displayed in this way. See the example below, and paragraph 4.4 at http://www.faqs.org/faqs/unix-faq/faq/part4/ I don't know which case applies to clamav-milter, or maybe there's some other reason - perhaps the OP can confirm. In any case, if a script tries to locate a program's pid using 'ps' output, I think this is certainly a case it needs to deal with. Regards, Brian. ---- 8< ---------------- $ cat ert.c #include int main(void) { execl("./ert2", 0); return 127; } $ cat ert2.c #include int main(void) { sleep(20); return 0; } $ gcc -Wall -o ert ert.c $ gcc -Wall -o ert2 ert2.c $ ./ert & $ ps auxwww | grep ert brian 23247 0.0 0.1 1188 468 p2 S 9:30AM 0:00.01 [ert2] $ From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 09:09:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9E4416A41F for ; Sat, 15 Oct 2005 09:09:39 +0000 (GMT) (envelope-from freebsd@psam.se) Received: from mxfep04.bredband.com (mxfep04.bredband.com [195.54.107.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id E94CC43D45 for ; Sat, 15 Oct 2005 09:09:38 +0000 (GMT) (envelope-from freebsd@psam.se) Received: from ironport.bredband.com ([195.54.107.82] [195.54.107.82]) by mxfep04.bredband.com with ESMTP id <20051015090937.ROPW4878.mxfep04.bredband.com@ironport.bredband.com> for ; Sat, 15 Oct 2005 11:09:37 +0200 Received: from c-5702e455.04-75-76786a11.cust.bredbandsbolaget.se (HELO caspian) ([85.228.2.87]) by ironport.bredband.com with ESMTP; 15 Oct 2005 11:09:24 +0200 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,216,1125871200"; d="txt'?scan'208"; a="3222613:sNHT33243336" Received: from [127.0.0.1] ([85.228.2.90]) (authenticated user peter@psam.se) by caspian (Kerio MailServer 6.1.0); Sat, 15 Oct 2005 11:09:46 +0200 Message-ID: <4350C749.9070704@psam.se> Date: Sat, 15 Oct 2005 11:09:29 +0200 From: Psadi User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <434E538F.80000@psam.se> <20051013.213943.05622321.imp@bsdimp.com> <43503EB8.7040509@psam.se> In-Reply-To: <43503EB8.7040509@psam.se> Content-Type: multipart/mixed; boundary="------------090306040208070009070708" X-Antivirus: avast! (VPS 0541-3, 2005-10-14), Outbound message X-Antivirus-Status: Clean Cc: "M. Warner Losh" Subject: Re: Thoshiba Tecra 8000 with 3com 3CXFE575CT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 09:09:39 -0000 This is a multi-part message in MIME format. --------------090306040208070009070708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Psadi skrev: > M. Warner Losh skrev: > >> In message: <434E538F.80000@psam.se> >> Psadi writes: >> : I had decided to try FreeBSD 6.0 on my laptop. After I installed it >> : beta4 I recived alot of xl0: watchdog timeout every time I try to >> use : the internet. >> >> Interrupts aren't being routed correctly. You need to fix that. >> There's a tiny chance it is in your hardware setup, but since prior >> versions work, I'd guess this is the case. You'll need to save the >> dmesg from 6.0 and from 5.4 and compare the too. Sadly, the Tecra >> 8000 moniker was used by a lot of different laptops. Mine just works >> w/o any issues. >> >> : At startup I see that I get CARDBUS1: Resource not specified in >> CIS: : id=14, size=80 >> >> Ignore these. Generally they are just noise. >> >> : I added in pccard.conf that it should use IRQ 3,5,10,15 though when >> I : look it still uses 11 >> >> pccard.conf is completely ignored. >> >> : What else can I try or do to get more info for those that needs it? >> >> Put the laptop in my hands, and I'll fix it :-). Otherwise, we'll >> have to start with boot -v dmesgs from working and broken systems. >> >> Warner >> >> >> >> > I have taken a dmesg -v from both a fresh installed 5.4 and 6.0RC1 I > will attach them instead of posting them > > If there is more info needed let me know. > > If I try and install through ftp from the CD with FreeBSD 6.0RC1 I > also get the xl0:watchdog timeout. I do not recive them at all in 5.4 > > Peter > > > Then I try again. Dont know what I did wrong on the last try but it was 1:20AM Peter --------------090306040208070009070708 Content-Type: text/plain; name="dmesg6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg6.txt" Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134152192 (127 MB) avail memory = 121733120 (116 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) isab0: at device 5.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfe60-0xfe6f at device 5.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: irq 11 at device 5.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 5.3 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: irq 11 at device 11.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 11 at device 11.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci0: at device 13.0 (no driver attached) acpi_lid0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: port 0x378-0x37a,0x778-0x77a irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/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 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xe8000-0xebfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 umass0: USB Flash Disk, rev 2.00/2.00, addr 2 Timecounter "TSC" frequency 299942836 Hz quality 800 Timecounters tick every 1.000 msec cardbus1: Resource not specified in CIS: id=14, size=80 cardbus1: Resource not specified in CIS: id=18, size=80 xl0: <3Com 3c575C Fast Etherlink XL> port 0x1080-0x10ff mem 0x88000000-0x8800007f,0x88000080-0x880000ff irq 11 at device 0.0 on cardbus1 miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:00:86:51:81:f8 ad0: 19077MB at ata0-master UDMA33 acd0: DVDROM at ata1-master PIO4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout xl0: watchdog timeout umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached umass0: USB Flash Disk, rev 2.00/2.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 1 0 0 done All buffers synced. Uptime: 11m11s Shutting down ACPI Rebooting... Copyright (c) 1992-2005 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 6.0-RC1 #0: Sun Oct 9 20:32:57 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a88000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a881a8. Calibrating clock(s) ... i8254 clock: 1193151 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 299943254 Hz CPU: Pentium II/Pentium II Xeon/Celeron (299.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134152192 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000007d77fff, 118829056 bytes (29011 pages) avail memory = 121733120 (116 MB) bios32: Found BIOS32 Service Directory header at 0xc00fbe90 bios32: Entry = 0xfc4c0 (c00fc4c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x1987 pnpbios: Found PnP BIOS data at 0xc00fed00 pnpbios: Entry = f0000:92c6 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 7933f351 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 pci_link1: irq 11 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 pci_link3: irq 11 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 ACPI timer: 0/5 0/8 0/3 0/6 0/6 0/6 0/5 0/7 0/6 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0 cpu0: on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71928086) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00f1320 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 11 A 0x60 11 embedded 0 11 B 0x61 11 embedded 0 9 A 0x62 11 embedded 0 4 A 0x62 11 embedded 0 4 B 0x63 11 embedded 0 13 A 0x63 11 embedded 0 5 D 0x63 11 slot 1 0 6 A 0x62 11 slot 1 0 6 B 0x63 11 slot 1 0 6 C 0x60 11 slot 1 0 6 D 0x61 11 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e0000000, size 28, enabled found-> vendor=0x10c8, dev=0x0005, revid=0x20 bus=0, slot=4, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base df000000, size 24, enabled map[14]: type 1, range 32, base ff800000, size 22, enabled map[18]: type 1, range 32, base ff700000, size 20, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.LNKC:0) pcib0: slot 4 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=5, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=5, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000fe60, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=5, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 0000ffe0, size 5, enabled pcib0: matched entry for 0.5.INTD (src \\_SB_.LNKD:0) pcib0: slot 5 INTD routed to irq 11 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=5, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type 4, range 32, base 0000fe70, size 4, enabled found-> vendor=0x1179, dev=0x0701, revid=0x23 bus=0, slot=9, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0400, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 4, range 32, base 0000ff80, size 5, enabled pcib0: matched entry for 0.9.INTA (src \\_SB_.LNKC:0) pcib0: slot 9 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=0x1179, dev=0x060a, revid=0x07 bus=0, slot=11, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 1, range 32, base 00000000, size 12, memory disabled pcib0: matched entry for 0.11.INTA (src \\_SB_.LNKA:0) pcib0: slot 11 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x1179, dev=0x060a, revid=0x07 bus=0, slot=11, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[10]: type 1, range 32, base 00000000, size 12, memory disabled pcib0: matched entry for 0.11.INTB (src \\_SB_.LNKB:0) pcib0: slot 11 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=0x123f, dev=0x8888, revid=0x02 bus=0, slot=13, func=0 class=04-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000ee00, size 8, enabled pcib0: matched entry for 0.13.INTA (src \\_SB_.LNKD:0) pcib0: slot 13 INTA routed to irq 11 via \\_SB_.LNKD pci0: at device 4.0 (no driver attached) PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 5.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfe60-0xfe6f at device 5.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfe60 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x04 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: irq 11 at device 5.2 on pci0 uhci0: Lazy allocation of 0x20 bytes rid 0x20 type 4 at 0x1000 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 5.3 (no driver attached) pci0: at device 9.0 (no driver attached) cbb0: irq 11 at device 11.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x060a1179 0x04800007 0x06070007 0x00820000 0x10: 0x80000000 0x04800000 0x00141400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0400010b 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x01000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x860010f0 0x00000002 0x00000000 0x0000d100 0xb0: 0x3f3f3fcf 0x0a081020 0x00010100 0x000003f1 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000008 cbb1: irq 11 at device 11.1 on pci0 cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0x060a1179 0x04800007 0x06070007 0x00820000 0x10: 0x80001000 0x04800000 0x00151500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x0400020b 0x40: 0x00011179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000000 0x00000000 0x00000000 0x01000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x860020f0 0x00000002 0x00000000 0x0000d100 0xb0: 0x3f3f3fcf 0x0a081020 0x00010100 0x000003f1 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000008 pci0: at device 13.0 (no driver attached) acpi_lid0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 80 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x1 0x11 0x11 0x11 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP SPP ppc0: port 0x378-0x37a,0x778-0x77a irq 7 drq 3 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete unknown: status reg test failed fe unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xe8000-0xebfff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices umass0: USB Flash Disk, rev 2.00/2.00, addr 2 umass0:0:0:-1: Attached to scbus0 Device configuration finished. procfs registered Timecounter "TSC" frequency 299943254 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached battery0: battery initialization start battery1: battery initialization start acpi_acad0: acline initialization start cardbus1: Resource not specified in CIS: id=14, size=80 cardbus1: Resource not specified in CIS: id=18, size=80 found-> vendor=0x10b7, dev=0x5257, revid=0x10 bus=21, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 xl0: <3Com 3c575C Fast Etherlink XL> port 0x1080-0x10ff mem 0x88000000-0x8800007f,0x88000080-0x880000ff irq 11 at device 0.0 on cardbus1 xl0: using port I/O xl0: media options word: 40 xl0: found MII/AUTO miibus0: on xl0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 11 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:00:86:51:81:f8 xl0: [MPSAFE] ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: setting PIO4 on Intel PIIX4 chip ad0: setting UDMA33 on Intel PIIX4 chip ad0: 19077MB at ata0-master UDMA33 ad0: 39070080 sectors [38760C/16H/63S] 16 sectors/interrupt 1 depth queue ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire acd0: setting PIO4 on Intel PIIX4 chip acd0: DVDROM drive at ata1 as master acd0: read 3445KB/s (3445KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR acd0: Writes: acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-2 device pass0: Serial Number \^_ pass0: 1.000MB/s transfers ATA PseudoRAID loaded da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: Serial Number \^_ da0: 1.000MB/s transfers da0: 125MB (256000 512 byte sectors: 64H 32S/T 125C) GEOM: new disk ad0 GEOM: new disk da0 Trying to mount root from ufs:/dev/ad0s2a start_init: trying /sbin/init xl0: watchdog timeout xl0: watchdog timeout battery1: battery initialization failed, giving up battery0: battery initialization failed, giving up --------------090306040208070009070708-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 10:06:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CADC16A41F; Sat, 15 Oct 2005 10:06:34 +0000 (GMT) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B79043D45; Sat, 15 Oct 2005 10:06:33 +0000 (GMT) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id C54D6ECD481; Sat, 15 Oct 2005 12:07:03 +0200 (CEST) Date: Sat, 15 Oct 2005 12:07:03 +0200 From: Andy Hilker To: Brian Candler Message-ID: <20051015100702.GA16495@mail.crypta.net> References: <434BCDF6.3090303@samsco.org> <1129201350.13257.9.camel@myfreebsd.homeunix.org> <20051013155511.GA1748@mail.crypta.net> <200510141502.16653.jhb@freebsd.org> <20051015083348.GA23073@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051015083348.GA23073@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 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: Sat, 15 Oct 2005 10:06:34 -0000 You (Brian Candler) wrote: [...] > If the total length of the command line (argv strings) is longer than > kern.ps_arg_cache_limit, which defaults to 256, then this is what you'll > see. `ps` shows just the command name in [] and no arguments. I've noticed > this with courier-imap, for example, which has a very long command line. > > So I've done > > sysctl kern.ps_arg_cache_limit=512 Yes, this works. Thanks. bye, Andy From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 11:32:13 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 642C016A41F; Sat, 15 Oct 2005 11:32:13 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AC343D48; Sat, 15 Oct 2005 11:32:12 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 434E604000058AFD; Sat, 15 Oct 2005 13:32:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Oct 2005 13:32:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A605F566@royal64.emp.zapto.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gvinum startup problems Thread-Index: AcXNaHZDxrOwrmkoTMu3yXPVvKfWmAEEsRgg From: "Daniel Eriksson" To: Cc: Lukas Ertl Subject: RE: gvinum startup problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 11:32:13 -0000 It looks like the gvinum problems I've been having were due to some sort of metadata inconsistency. After manually setting the stale subdisks to the "up" state and then doing a 'gvinum saveconfig', gvinum now is able to pick up the array during boot just fine. What threw me off was the fact that manually loading gvinum worked fine, so when auto-loading gvinum resulted in a broken array I never considered metadata problems. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 18:58:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7844116A420; Fri, 14 Oct 2005 18:58:41 +0000 (GMT) (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 8D88143D5A; Fri, 14 Oct 2005 18:58:34 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id j9EIw72j010762; Fri, 14 Oct 2005 20:58:07 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id j9EIw7hN010760; Fri, 14 Oct 2005 20:58:07 +0200 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id j9EItr82011672; Fri, 14 Oct 2005 20:55:53 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id j9EItoLr011671; Fri, 14 Oct 2005 20:55:50 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 14 Oct 2005 20:55:50 +0200 To: "M. Warner Losh" Message-ID: <20051014185550.GA11501@saturn.kn-bremen.de> Mail-Followup-To: "M. Warner Losh" , jkim@freebsd.org, freebsd-current@freebsd.org, thierry@herbelot.com, jcoombs@gwi.net, bakul@BitBlocks.com, freebsd-emulation@freebsd.org References: <200510131210.55135.jkim@FreeBSD.org> <200510131428.21211.jkim@FreeBSD.org> <20051013200254.GA11267@saturn.kn-bremen.de> <20051013.172655.102656323.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051013.172655.102656323.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Sat, 15 Oct 2005 12:49:20 +0000 Cc: jcoombs@gwi.net, thierry@herbelot.com, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, bakul@BitBlocks.com, jkim@freebsd.org Subject: Re: Loss of ed(4) in a RC1 booted in qemu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 18:58:41 -0000 On Thu, Oct 13, 2005 at 05:26:55PM -0600, M. Warner Losh wrote: > In message: <20051013200254.GA11267@saturn.kn-bremen.de> > Juergen Lock writes: > : On Thu, Oct 13, 2005 at 02:28:18PM -0400, Jung-uk Kim wrote: > : > On Thursday 13 October 2005 12:10 pm, Jung-uk Kim wrote: > : > > QEMU emulates RTL8029: > : > > > : > > ed0: port 0xc100-0xc1ff irq 11 at device 3.0 on pci0 > : > > ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 > : > > > : > > and Warner Losh MFC'd new ed(4) right before 6.0-RC1: > : > > > : > > http://docs.freebsd.org/cgi/mid.cgi?200510081800.j98I0fRI089493 > : > > > : > > The new driver does more aggressive probing and it seems QEMU > : > > cannot handle it. > : > > : > Just for the time being, you can drop the attachment in > : > ports/emulators/qemu/files directory and rebuild qemu to get ed(4) > : > back. > : > > : > Jung-uk Kim > : > : >[patch snipped] > : > : Okay, we could add this as an option to our qemu port (`-ne2kvia' or > : something like that), anyone thinks it is necessary? (I guess this > : issue will be fixed in 6.0-R?) > > I've committed patches to -current to fix this problem. The fixes > correct a minor botch in the probing code, while also adding tolerance > for the RTL8029 that's claimed to be there to not really be there. > I've posted patches to qemu that improves that RTL8029 emulation, but > those aren't required for FreeBSD to work. RC1 won't work with qemu, > patched or unpatched, due to the minor botch. RC2 and newer will have > this problem fixed. The qemu folks can include and improve upon my > patches as they see fit in the future. > > The problem with just switching to the VIA VT86C926 is that it isn't > exactly like a NE-2000. [...] Okay, how about adding this to qemu's pkg-message then: Index: pkg-message =================================================================== RCS file: /home/ncvs/ports/emulators/qemu/pkg-message,v retrieving revision 1.9 diff -u -r1.9 pkg-message --- pkg-message 10 Sep 2005 17:04:41 -0000 1.9 +++ pkg-message 14 Oct 2005 18:49:55 -0000 @@ -25,5 +25,12 @@ (see kern/84102, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84102), using a kernel without PREEMPTION has been reported to fix this problem. (or do an ftp install instead of installing from the emulated cdrom, and -then make a new kernel.) +then make a new kernel.) [now fixed in cvs.] +- 6.0-RC1 was released with an ed driver that doesn't like qemu's emulated +RTL8029 nic, this has been fixed in the meantime but if for some reason +you need to use that version as a guest you can temporarily add the patch +in this message: http://docs.freebsd.org/cgi/mid.cgi?200510131428.21211.jkim +(not included in the port since the used VIA VT86C926 PCI ID does not +really match the emulated nic exactly, it just `happens' to work with +6.0-RC1's driver.) ==== From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 22:33:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C463416A41F for ; Fri, 14 Oct 2005 22:33:44 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32CDB43D46 for ; Fri, 14 Oct 2005 22:33:43 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.4) with ESMTP id j9EMXgkq032038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Fri, 14 Oct 2005 18:33:42 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.4/Submit) id j9EMXfMf032035; Fri, 14 Oct 2005 18:33:41 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17232.12869.659397.686840@khavrinen.csail.mit.edu> Date: Fri, 14 Oct 2005 18:33:41 -0400 To: Bruce Evans In-Reply-To: <20051015074316.T1260@epsplex.bde.org> References: <12907.1129286370@critter.freebsd.dk> <20051015074316.T1260@epsplex.bde.org> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 14 Oct 2005 18:33:42 -0400 (EDT) X-Spam-Status: No, score=0.0 required=5.0 tests=none version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Sat, 15 Oct 2005 12:49:20 +0000 Cc: current@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2005 22:33:44 -0000 [Moved to -current as this is no longer net related.] < said: > values of HZ like 1000 -- with hz > stathz it is easy to use a periodic > itimer to arrange to run about (hz - stathz) / hz of the time without ever > seeing a statclock tick. The whole point of statclock was that it was supposed to be an exponential distribution centered on stathz, not strictly periodic, precisely to prevent this problem. With the new APIC clock divider code, we should be able to do this fairly cheaply and at a higher rate than 128 Hz. It was originally developed on SPARC hardware so that architecture ought to be able to do it easily. -GAWollman From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 14:03:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C40C16A420 for ; Sat, 15 Oct 2005 14:03:50 +0000 (GMT) (envelope-from therion@ninth-art.de) Received: from mail.ninth-art.de (coruscant.ninth-art.de [81.169.134.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9655B43D45 for ; Sat, 15 Oct 2005 14:03:48 +0000 (GMT) (envelope-from therion@ninth-art.de) Received: (qmail 28713 invoked from network); 15 Oct 2005 16:03:47 +0200 Received: from 84.60.19.213 by coruscant (envelope-from , uid 201) with qmail-scanner-1.25st (clamdscan: 0.87/1134. spamassassin: 3.0.4. perlscan: 1.25st. Clear:RC:0(84.60.19.213):SA:0(-1.2/5.0):. Processed in 9.675071 secs); 15 Oct 2005 14:03:47 -0000 X-Spam-Status: No, hits=-1.2 required=5.0 Received: from dslb-084-060-019-213.pools.arcor-ip.net (HELO ?84.60.19.213?) (therion@ninth-art.de@84.60.19.213) by coruscant.ninth-art.de with AES256-SHA encrypted SMTP; 15 Oct 2005 16:03:37 +0200 Message-ID: <43510C33.80205@ninth-art.de> Date: Sat, 15 Oct 2005 16:03:31 +0200 From: Georg Bege User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051003) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: latest XFS patch doesnt work on RELENG_6 anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: therion@ninth-art.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 14:03:50 -0000 Hi I'm trying to patch my recently fetched RELENG_6 src/sys. I managed to get it to work some time ago on FreeBSD 6.0-BETA5. But now while performing make depend I get: [ more stuff cut out ] ../../../gnu/fs/xfs/xfs_iomap.c:60:23: xfs_error.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:61:24: xfs_itable.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:62:20: xfs_rw.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:63:21: xfs_acl.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:64:21: xfs_cap.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:65:21: xfs_mac.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:66:22: xfs_attr.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:67:26: xfs_buf_item.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:68:29: xfs_trans_space.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:69:23: xfs_utils.h: No such file or directory ../../../gnu/fs/xfs/xfs_iomap.c:70:23: xfs_iomap.h: No such file or directory ../../../gnu/fs/xfs/xfs_behavior.c:33:17: xfs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/i386/compile/FORTUNA. So I assume that the latest XFS patch doesnt work anymore on 6.x? I tried it also with 7-CURRENT but got the same shit above, I think its a path problem but not sure how to fix it and its just strange since it worked to me just a couple of days before. Another problem is that it isnt possible to build xfs.ko (as descriped @http://people.freebsd.org/~rodrigc/xfs/) because the /usr/src/sys/modules/xfs/Makefile is lacking completly. ( I managed to satisfy the building routine by copying another Makefile into the modules/xfs directory - so that I was able to build xfs into my last kernel ) I tried it now various times and also on a complete clean /usr/src directory while /usr/obj was completly clean too. No luck - is xfs for FreeBSD still maintained and developed? I hope that anybody can give me at least a hint what Im doing wrong. cheers Georg From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 14:08:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F157F16A420 for ; Sat, 15 Oct 2005 14:08:34 +0000 (GMT) (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 20A7543D46 for ; Sat, 15 Oct 2005 14:08:33 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EQmgs-0002km-DV for freebsd-current@freebsd.org; Sat, 15 Oct 2005 16:07:14 +0200 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Oct 2005 16:07:14 +0200 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Oct 2005 16:07:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Joshua Coombs" Date: Sat, 15 Oct 2005 10:06:22 -0400 Lines: 141 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: news Subject: 486DLC Tuning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 14:08:35 -0000 I have a 386 with a Cyrix 486DRx2-66 (clock doubled DLC) that I moved from 4.11 to 6.0. So far it's running decently, I've got more net/hd throughput than I had before, by a factor of two for net, but the box 'feels' like I'm not getting the same cpu perf I had before. Without benchmarks, I'm not in the best position to prove it, but I figured I'd try some basic tuning to see if I could improve things. Initially I've been running with the GENERIC kernel under 6.0. I had spent a fair amount of time testing the various CPU and ISA tweaks under 4.11 and had established a set that worked reliably and got me a little extra umph. My prior set was: machine i386 cpu I386_CPU cpu I486_CPU options PQ_CACHESIZE=128 options CPU_DIRECT_MAPPED_CACHE options CPU_I486_ON_386 options CYRIX_CACHE_WORKS options CYRIX_CACHE_REALLY_WORKS device isa options AUTO_EOI_1 options AUTO_EOI_2 Checking NOTES, the options haven't changes, so I tweaked the conf, built a kernel (48 hours?! Used to take 10 under 4.11, kernel's getting big) and tried it out. Panics with a kernel trap, either type 1 or type 9 just before displaying the copyright, but after it's switched to bright white text. I don't have a copy of the trap output, I'll be setting up a serial console to capture that shortly. Eventually I settled on the following setup: machine i386 cpu I486_CPU options PQ_CACHESIZE=128 options CPU_DIRECT_MAPPED_CACHE options CPU_I486_ON_386 #options CYRIX_CACHE_WORKS options CYRIX_CACHE_REALLY_WORKS #options CPU_UPGRADE_HW_CACHE device isa options AUTO_EOI_1 options AUTO_EOI_2 It seems odd that I can have CYRIX_CACHE_REALLY_WORKS but not CYRIX_CACHE_WORKS enabled. I see too possibilities, either A) You must have CYRIX_CACHE_WORKS enabled for CYRIX_CACHE_REALLY_WORKS to actually mean something, in which case shouldn't config warn about this? B) If you have both enabled, CYRIX_CACHE_WORKS overrides CYRIX_CACHE_REALLY_WORKS, and something has changed with 6.0 such that I can no longer safely use that cache. Would it be possible to get the kernel to spit out when it is honoring any of these types of options, as well as what it things the state of the cache, or whatever other cpu aspect is that you're tweaking using one of these settings? Being able to verify what's going on is always nice. Heck, just additional output showing known cache status info along with the CPUID would be handy. Joshua Coombs Copyright (c) 1992-2005 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 6.0-RC1 #3: Sat Oct 15 00:37:28 EDT 2005 root@tinbox.gwi:/usr/src/sys/i386/compile/I386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Cyrix 486DRx2 (486-class CPU) Origin = "CyrixInstead" DIR=0x2207 Stepping=2 Revision=2 real memory = 67108864 (64 MB) avail memory = 60325888 (57 MB) npx0: [FAST] npx0: on motherboard npx0: IRQ 13 interface cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xdc000-0xdffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16450 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16450 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 aha1 at port 0x330-0x333 irq 11 drq 5 on isa0 aha1: AHA-1542CF FW Rev. B.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs aha1: [GIANT-LOCKED] ed1: at port 0x240-0x25f irq 5 on isa0 ed1: Ethernet address: 00:80:c8:da:a6:f0 ed1: type NE2000 (16 bit) Timecounters tick every 10.000 msec Waiting 5 seconds for SCSI devices to settle da0 at aha1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8) da0: 4095MB (8388315 512 byte sectors: 64H 32S/T 4095C) da1 at aha1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8) da1: 8347MB (17096357 512 byte sectors: 64H 32S/T 8347C) da2 at aha1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8) da2: 8347MB (17096357 512 byte sectors: 64H 32S/T 8347C) cd0 at aha1 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Logical unit is in process of becoming ready From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 15:58:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40A7716A41F for ; Sat, 15 Oct 2005 15:58:57 +0000 (GMT) (envelope-from gunnarr@acm.org) Received: from tenno.homeunix.org (hnv9-d9badedd.pool.mediaWays.net [217.186.222.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33A6F43D6B for ; Sat, 15 Oct 2005 15:58:52 +0000 (GMT) (envelope-from gunnarr@acm.org) Received: by tenno.homeunix.org (8.12.11/8.12.8) with SMTP id j9FFwqRJ006195 for ; Sat, 15 Oct 2005 17:58:53 +0200 Date: Sat, 15 Oct 2005 17:58:51 +0200 From: Gunnar Ritter Organization: Privat. To: freebsd-current@freebsd.org Message-ID: <4351273b.bzPOAmUJEII9Q4yr%gunnarr@acm.org> References: <20050615054209.L29741@beagle.kn.op.dlr.de> <42B10804.2010308@mac.com> <20050617192332.GE13006@dragon.NUXI.org> <200506172130.36586@harrymail> In-Reply-To: <200506172130.36586@harrymail> User-Agent: nail 11.26pre 10/4/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 15:58:57 -0000 Emanuel.strobl@gmx.net (Emanuel Strobl) wrote: > Am Freitag, 17. Juni 2005 21:23 schrieb David O'Brien: > > Yes. But the issue is, why trade one piece of non-BSDL licensed code > > for another non-BSDL licensed piece of code?? What does changing from > > Groff to Solaris Troff actually buy us?? Groff is the standard in Roff. > Groff depends on c++ and is far to big for embedded systems. In fact its > bigger than the complete man pages for the OS. (~10MB). > That's why I initially posted my question and Lyndon made the OpenSolaris > suggestion. I'd like to have a simple possibility to view unformated man > pages with reasonable sized tools. Preformatting man pages is not an > option for me since packages install unformatted man pages and I don't > know a suitable way to change that. For anyone interested, I have created a portable and enhanced version of OpenSolaris nroff/troff available at . Regarding the issues mentioned on this list in June, - it can be put in a very small package as only the nroff and tbl binaries and the macro packages are required for formatting manual pages to view them on a terminal. This fits in approximately 250 KB of disk space on an i386 system. (A full installation requires approximately 2.3 MB.) - while not being compatible with groff in general, it supports long request names and similar features that occur in many manual pages today - it can handle locale-specific characters, and can create UTF-8 output - the text block limit in tbl does not prevent the ncurses terminfo page from being formatted correctly anymore. Many other enhancements for quality typesetting with troff have also been made. The "doc" macro package is currently included in its plain 4.4BSD version and does not format current BSD manual pages correctly. A contribution of an updated variant would be welcome. Gunnar From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 16:00:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8420416A41F for ; Sat, 15 Oct 2005 16:00:19 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA33E43D46 for ; Sat, 15 Oct 2005 16:00:17 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 50CE51FFACB for ; Sat, 15 Oct 2005 18:00:15 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id CCE091FFACA; Sat, 15 Oct 2005 18:00:12 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 2D95915907; Sat, 15 Oct 2005 16:00:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 18AC515906 for ; Sat, 15 Oct 2005 16:00:08 +0000 (UTC) Date: Sat, 15 Oct 2005 16:00:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Subject: mount memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 16:00:19 -0000 Hi, I had /dev/ad8s4d mounted read only to /shared and /local/building/ports/shared, then unounted /shared and did a mount -u -o rw /local/building/ports/shared *kaboom* This is HEAD of the day on amd64 running i386. bt full follows... db> where Tracing pid 1361 tid 100053 td 0xc47e9190 g_io_request(c4e42840,c4af97c0,d87c9b38,c4d6f990,e83bc8a4) at g_io_request+= 0x5f g_vfs_strategy(c4d6fa50,d87c9b38,20000000,d87c9b38,d87c9b38) at g_vfs_strat= egy+0x49 ffs_geom_strategy(c4d6fa50,d87c9b38) at ffs_geom_strategy+0xa7 bufwrite(d87c9b38,2800,c4db6800,e83bc904,c07c7799) at bufwrite+0x14a ffs_bufwrite(d87c9b38) at ffs_bufwrite+0x282 ffs_sbupdate(c4e30800,1,c4d85220,c4e30800,c08bfbcf) at ffs_sbupdate+0x15d ffs_mount(c47a8000,c47e9190,20000000,1001,c4e68dd0) at ffs_mount+0x72c vfs_domount(c47e9190,c4d85790,c4f2b660,10000,c4d85a30) at vfs_domount+0x589 vfs_donmount(c47e9190,10000,e83bcba8,c5030a80,e) at vfs_donmount+0xce kernel_mount(c4944ca0,10000,804fc38,0,fffffffe) at kernel_mount+0x6d ffs_cmount(c4944ca0,bfbfdd70,10000,c47e9190,c095c560) at ffs_cmount+0x5d mount(c47e9190,e83bcd04,c,c47e9190,e83bcd30) at mount+0x156 syscall(3b,3b,3b,804aa7b,bfbfe80c) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (21, FreeBSD ELF32, mount), eip =3D 0x280b715b, esp =3D 0xbfbfd= d4c, ebp =3D 0xbfbfdde8 --- db> show alllocks Process 1361 (mount) thread 0xc47e9190 (100053) exclusive sleep mutex Giant r =3D 1 (0xc0988360) locked @ /local/building/f= reebsd/HEAD/sys/kern/vfs_mount.c:502 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 ar= e welcome to change it and/or distribute copies of it under certain condition= s. 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=09=3D 0xdeadc112 fault code=09=09=3D supervisor read, page not present instruction pointer=09=3D 0x20:0xc062fc97 stack pointer=09 =3D 0x28:0xe83bc84c frame pointer=09 =3D 0x28:0xe83bc870 code segment=09=09=3D base 0x0, limit 0xfffff, type 0x1b =09=09=09=3D DPL 0, pres 1, def32 1, gran 1 processor eflags=09=3D interrupt enabled, resume, IOPL =3D 0 current process=09=09=3D 1361 (mount) Process 1361 (mount) thread 0xc47e9190 (100053) exclusive sleep mutex Giant r =3D 1 (0xc0988360) locked @ /local/building/f= reebsd/HEAD/sys/kern/vfs_mount.c:502 Dumping 3071 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 3071MB (786160 pages) 3055 3039 3023 3007 2991 2975 2959 2943 29= 27 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 26= 87 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 24= 47 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 22= 07 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 19= 67 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 17= 27 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 14= 87 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 12= 47 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 10= 07 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 11= 1 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 =09in pcpu.h (kgdb) bt full #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. (kgdb) #0 doadump () at pcpu.h:165 No locals. #1 0xc0494c4f in db_fncall (dummy1=3D1016, dummy2=3D0, dummy3=3D-1, dummy4= =3D0xe83bc620 "T=C6;=E8") at /local/building/freebsd/HEAD/sys/ddb/db_comman= d.c:488 =09fn_addr =3D -1067043412 =09args =3D {1, 0, 536870974, -1064828251, -398735712, -1066935919, 32, 0, = 2, -1064373152} =09nargs =3D 0 =09retval =3D 0 =09t =3D 0 #2 0xc0494a54 in db_command (last_cmdp=3D0xc096f184, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc08e5ff4, aux_cmd_tablep_end=3D0xc08e6010) at /local/building/freebsd/HEAD/sys/ddb/db_command.c:403 =09cmd =3D (struct command *) 0xc08ef5f0 =09t =3D 0 =09modif =3D "T=C6;=E8\000\000\000\000@=C6;=E8=F8\003\000\000D=C6;=E8=F8\00= 3\000\000l=C6;=E8\f\000\000\000X=C6;=E8=F8\003\000\000\\=C6;=E8\215N\202=C0= =F8\003\000\000=F8\003\000\000\r\000\000\000\204=C6;=E8\216P\202=C0l=C6;=E8= =F8\003\000\000\f\000\017\003x\000\000\000\200=FA\226=C0\f\000\000\000\230= =C6;=E8=F0jI=C0Fn\213=C0=C8gI=C0\f\000\000\000\200=FA\226=C0z_I=C0" =09addr =3D 1016 =09count =3D -1 =09have_addr =3D 0 =09result =3D 0 #3 0xc0494b1c in db_command_loop () at /local/building/freebsd/HEAD/sys/dd= b/db_command.c:454 No locals. #4 0xc0496735 in db_trap (type=3D12, code=3D0) at /local/building/freebsd/= HEAD/sys/ddb/db_main.c:221 =09jb =3D {{_jb =3D {-398735656, -398735676, -398735604, -398735348, 12, -1= 068931378, 12, -398735580, -1066936741, -1064436868, -1066936608, -39873560= 0}}} =09prev_jb =3D (void *) 0x0 =09bkpt =3D 0 #5 0xc067bd5f in kdb_trap (type=3D12, code=3D0, tf=3D0xe83bc80c) at /local= /building/freebsd/HEAD/sys/kern/subr_kdb.c:473 =09handled =3D -398735348 #6 0xc08453a8 in trap_fatal (frame=3D0xe83bc80c, eva=3D3735929106) at /loc= al/building/freebsd/HEAD/sys/i386/i386/trap.c:846 =09eflags =3D 514 =09code =3D 514 =09type =3D 12 =09ss =3D 514 =09esp =3D 0 =09softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27, ssd= _dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 0, ssd_xx1 =3D 0, ssd_def32 =3D 1, ssd_= gran =3D 1} #7 0xc0845117 in trap_pfault (frame=3D0xe83bc80c, usermode=3D0, eva=3D3735= 929106) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:766 =09va =3D 3735928832 =09vm =3D (struct vmspace *) 0x0 =09map =3D 0xc1043000 =09rv =3D 1 =09ftype =3D 1 '\001' =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 #8 0xc0844d31 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -559038242, tf_e= si =3D -559038242, tf_ebp =3D -398735248, tf_isp =3D -398735304, tf_ebx =3D= -991680448, tf_edx =3D -995125312, tf_ecx =3D 0, tf_eax =3D -995125312, tf= _trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067254633, tf_cs =3D 32, tf_efla= gs =3D 66050, tf_esp =3D -1065514915, tf_ss =3D -991680448}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:451 =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09sticks =3D 582 =09i =3D 0 =09ucode =3D 0 =09type =3D 12 =09code =3D 0 =09addr =3D -398735436 =09eva =3D 3735929106 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xc4d6fa0c, tqe_prev =3D 0xc47e9190}= , ksi_info =3D {si_signo =3D -1063725504, si_errno =3D -1063725504, si_code= =3D -1056795224, si_pid =3D 9, si_uid =3D 3896231900, si_status =3D -1064478820, si_addr= =3D 0xe83bc7e0, si_value =3D {sigval_int =3D -1066904264, sigval_ptr =3D 0= xc0685538}, si_band =3D -1064478820, _reason =3D {_fault =3D {_trapno =3D -10648316= 59}, __spare__ =3D {-1064831659, 3, -998338160, -398735360, -1066901679, 58= 2, 582}}}, ksi_flags =3D -1064171932} #9 0xc083798a in calltrap () at /local/building/freebsd/HEAD/sys/i386/i386= /exception.s:139 No locals. #10 0xc062fc97 in g_io_request (bp=3D0xc4e42840, cp=3D0xc4af97c0) at /local= /building/freebsd/HEAD/sys/geom/geom_io.c:287 =09pp =3D (struct g_provider *) 0xdeadc0de #11 0xc0632969 in g_vfs_strategy (bo=3D0xc4af97c0, bp=3D0xd87c9b38) at /loc= al/building/freebsd/HEAD/sys/geom/geom_vfs.c:106 =09cp =3D (struct g_consumer *) 0xc4af97c0 =09bip =3D (struct bio *) 0xc4af97c0 #12 0xc07c7e47 in ffs_geom_strategy (bo=3D0xc4d6fa50, bp=3D0xd87c9b38) at /= local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:1694 =09vp =3D (struct vnode *) 0xc4d6f990 =09error =3D -995125312 #13 0xc06a84e2 in bufwrite (bp=3D0xd87c9b38) at buf.h:415 =09oldflags =3D 536870912 #14 0xc07c7d96 in ffs_bufwrite (bp=3D0xd87c9b38) at /local/building/freebsd= /HEAD/sys/ufs/ffs/ffs_vfsops.c:1663 =09newbp =3D (struct buf *) 0xc4db6800 #15 0xc07c7799 in ffs_sbupdate (mp=3D0xc4e30800, waitfor=3D1) at buf.h:401 =09fs =3D (struct fs *) 0xc4db6800 =09sbbp =3D (struct buf *) 0xd87ca058 =09bp =3D (struct buf *) 0xd87c9b38 =09blks =3D 5 =09space =3D (void *) 0xc4e78800 =09i =3D 0 =09size =3D 10240 =09error =3D -995125312 =09allerror =3D 0 #16 0xc07c52b4 in ffs_mount (mp=3D0xc47a8000, td=3D0xc47e9190) at /local/bu= ilding/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:264 =09devvp =3D (struct vnode *) 0xc4d6f990 =09ump =3D (struct ufsmount *) 0xc4e30800 =09fs =3D (struct fs *) 0xc4db6800 =09error =3D 0 =09flags =3D -995125312 =09accessmode =3D 38848 =09ndp =3D {ni_dirp =3D 0x20
, ni_segflg =3D 33= 04240832, ni_startdir =3D 0xe83bc9e0, ni_rootdir =3D 0xc065a484, ni_topdir = =3D 0xe83bc9fc, ni_vp =3D 0xc065a697, ni_dvp =3D 0xc09288c0, ni_pathlen =3D 32, ni_next = =3D 0xc4f2b6c0 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD= =DE=DE=C0=AD=DE=DE=C0=AD=DE=C0\210\222=C0", ni_loopcnt =3D 3299671232, ni_c= nd =3D { cn_nameiop =3D 3302513200, cn_flags =3D 3896232464, cn_thread =3D 0xc06= b298b, cn_cred =3D 0xc4f2b6c0, cn_lkflags =3D -990726176, cn_pnbuf =3D 0xe8= 3bca2c "P=CB;=E8=D97k=C0", cn_nameptr =3D 0xe83bca2c "P=CB;=E8=D97k=C0", cn_namelen =3D -106671804= 5, cn_consume =3D -995319008}} =09export =3D {ex_flags =3D -1064478820, ex_root =3D 3230135637, ex_anon = =3D {cr_version =3D 3, cr_uid =3D 3296629136, cr_ngroups =3D -13936, cr_gro= ups =3D {3228065617, 582, 582, 3230795364, 3238324744, 2273, 3230488476, 3896232372, 3227894052= , 3238324744, 1, 3230359632, 300, 32, 3304240832, 3238320000}, _cr_unused1 = =3D 0xe83bc9dc}, ex_addr =3D 0xc07d8f99, ex_addrlen =3D 8 '\b', ex_mask =3D 0x0, ex_maskle= n =3D 220 '=DC', ex_indexfile =3D 0xc07d9004 "=E9"} =09fspec =3D 0xc4d85220 "/dev/ad8s4d" #17 0xc06b37d9 in vfs_domount (td=3D0xc47e9190, fstype=3D0xc4d85790 "ufs", = fspath=3D0xc4f2b660 "/local/building/ports/shared", fsflags=3D65536, fsdata= =3D0xc4d85a30) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:739 =09vp =3D (struct vnode *) 0xc4e68dd0 =09mp =3D (struct mount *) 0xc47a8000 =09vfsp =3D (struct vfsconf *) 0xc4d85790 =09error =3D 0 =09flag =3D 4097 =09kern_flag =3D 536870912 =09va =3D {va_type =3D 3896232724, va_mode =3D 34830, va_nlink =3D -16259, = va_uid =3D 3238325064, va_gid =3D 0, va_fsid =3D 3230488476, va_fileid =3D = -1056646968, va_size =3D 13874459946760067200, va_blocksize =3D -398734580, va_atime = =3D {tv_sec =3D -1066904264, tv_nsec =3D -1064567857}, va_mtime =3D {tv_sec= =3D -998338008, tv_nsec =3D -1063746720}, va_ctime =3D {tv_sec =3D -1064567857, tv_nsec= =3D -398734556}, va_birthtime =3D {tv_sec =3D -1066904264, tv_nsec =3D -10= 64567857}, va_gen =3D 3231220576, va_flags =3D 502, va_rdev =3D 3896232768, va_bytes= =3D 13879309793755683937, va_filerev =3D 13878253506681930592, va_vaflags = =3D 3231220576, va_spare =3D 502} =09nd =3D {ni_dirp =3D 0xc4f2b660 "/local/building/ports/shared", ni_segflg= =3D UIO_SYSSPACE, ni_startdir =3D 0x0, ni_rootdir =3D 0xc4afdbb0, ni_topdi= r =3D 0x0, ni_vp =3D 0xc4e68dd0, ni_dvp =3D 0xc4e72660, ni_pathlen =3D 1, ni_next = =3D 0xc4b00c1c "", ni_loopcnt =3D 0, ni_cnd =3D {cn_nameiop =3D 0, cn_flags= =3D 49220, cn_thread =3D 0xc47e9190, cn_cred =3D 0xc4d7d600, cn_lkflags =3D 2, cn_= pnbuf =3D 0xc4b00c00 "/local/building/ports/shared", cn_nameptr =3D 0xc4b00= c16 "shared", cn_namelen =3D 6, cn_consume =3D 0}} #18 0xc06b30ae in vfs_donmount (td=3D0xc47e9190, fsflags=3D65536, fsoptions= =3D0xe83bcba8) at /local/building/freebsd/HEAD/sys/kern/vfs_mount.c:503 =09optlist =3D (struct vfsoptlist *) 0xc4d85a30 =09fstype =3D 0xc4d85790 "ufs" =09fspath =3D 0xc4f2b660 "/local/building/ports/shared" =09error =3D 0 =09fstypelen =3D 4 =09fspathlen =3D 29 #19 0xc06b51a5 in kernel_mount (ma=3D0xc4944ca0, flags=3D65536) at pcpu.h:1= 62 =09auio =3D {uio_iov =3D 0xc5030a80, uio_iovcnt =3D 14, uio_offset =3D -428= 1713091747787516, uio_resid =3D -398734252, uio_segflg =3D UIO_SYSSPACE, ui= o_rw =3D 3298053280, uio_td =3D 0xc08af5f7} =09error =3D 0 #20 0xc07c5581 in ffs_cmount (ma=3D0xc4944ca0, data=3D0x0, flags=3D65536, t= d=3D0xc47e9190) at /local/building/freebsd/HEAD/sys/ufs/ffs/ffs_vfsops.c:38= 2 =09args =3D {fspec =3D 0x804fc38
, export = =3D {ex_flags =3D 0, ex_root =3D 4294967294, ex_anon =3D {cr_version =3D 67= 1547392, cr_uid =3D 3217022356, cr_ngroups =3D 1, cr_groups =3D {671428755, 1,= 671519704, 3217022388, 671429097, 671555648, 134525800, 3217022436, 671429= 053, 671519704, 671920428, 3217022436, 671421185, 671537220, 1, 134523472}, _cr_unu= sed1 =3D 0xbfbfddf8}, ex_addr =3D 0x80493d7, ex_addrlen =3D 1 '\001', ex_ma= sk =3D 0x28070100, ex_masklen =3D 48 '0', ex_indexfile =3D 0x804fc29
}} =09error =3D -995125312 #21 0xc06b323e in mount (td=3D0xc47e9190, uap=3D0xe83bcd04) at /local/build= ing/freebsd/HEAD/sys/kern/vfs_mount.c:566 =09fstype =3D 0xc4acab20 "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=DE =EC\221=C0\0= 01" =09vfsp =3D (struct vfsconf *) 0xc095c560 =09ma =3D (struct mntarg *) 0xc4944ca0 =09error =3D 0 #22 0xc08456be in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134523515, tf_e= si =3D -1077942260, tf_ebp =3D -1077944856, tf_isp =3D -398733980, tf_ebx = =3D -1077944800, tf_edx =3D 65536, tf_ecx =3D 3, tf_eax =3D 21, tf_trapno = =3D 12, tf_err =3D 2, tf_eip =3D 671838555, tf_cs =3D 51, tf_eflags =3D 582= , tf_esp =3D -1077945012, tf_ss =3D 59}) at /local/building/freebsd/HEAD/sys/i386/i386/trap.c:1001 =09params =3D 0xbfbfdd50
=09callp =3D (struct sysent *) 0xc091be5c =09td =3D (struct thread *) 0xc47e9190 =09p =3D (struct proc *) 0xc47e7880 =09orig_tf_eflags =3D 582 =09sticks =3D 0 =09error =3D 0 =09narg =3D 4 =09args =3D {134523511, -1077944800, 65536, -1077944976, -1064615375, 802, = -998338160, -1067119640} =09code =3D 21 =09ksi =3D {ksi_link =3D {tqe_next =3D 0xe83bcd38, tqe_prev =3D 0x0}, ksi_i= nfo =3D {si_signo =3D 672388232, si_errno =3D 672088533, si_code =3D 0, si_= pid =3D 0, si_uid =3D 0, si_status =3D -998344576, si_addr =3D 0xc47e78e8, si_value =3D {sigval_= int =3D 802, sigval_ptr =3D 0x322}, si_band =3D -1064615375, _reason =3D {_= fault =3D { _trapno =3D -398734076}, __spare__ =3D {-398734076, -1067073244, -9= 98344472, -998344576, 0, -398734044, -1067119649}}}, ksi_flags =3D -1063746= 720} #23 0xc08379df in Xint0x80_syscall () at /local/building/freebsd/HEAD/sys/i= 386/i386/exception.s:200 No locals. #24 0x00000033 in ?? () No symbol table info available. --=20 Bjoern A. Zeeb=09=09=09=09bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 16:22:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F29B16A41F for ; Sat, 15 Oct 2005 16:22:56 +0000 (GMT) (envelope-from pure32bits@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0869243D49 for ; Sat, 15 Oct 2005 16:22:51 +0000 (GMT) (envelope-from pure32bits@gmail.com) Received: by xproxy.gmail.com with SMTP id t6so84843wxc for ; Sat, 15 Oct 2005 09:22:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Im8R++gNRvFWZjPjIjhtcoZdgyMdpnfQ1eUj4tpNo6hrnP5yDZXa7BnZCiLfRWe/snNcbHFZ4FNMFIts8jzCppzuI0rwoUXRP/2UegNMtgYa2i1HYABJ2ib/6pZMDPKR8V1CXAvZRceuQD+BlLJ8D21KGODJOArr5vKknYJtasM= Received: by 10.70.34.1 with SMTP id h1mr1649046wxh; Sat, 15 Oct 2005 09:22:51 -0700 (PDT) Received: by 10.70.36.17 with HTTP; Sat, 15 Oct 2005 09:22:51 -0700 (PDT) Message-ID: <91a8768e0510150922p2456b373l4bb6411002f59a8c@mail.gmail.com> Date: Sat, 15 Oct 2005 18:22:51 +0200 From: Pure32 Bits To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Driver for nforce* does not work properly. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 16:22:56 -0000 I downloaded FreeBSD 6.0 rc1, installed it with no problem... When i configure my build-in NIC, nForce2, everything works fine. But i start getting some errors like the following: "nve0: device timeout" Anyone has a solution for that? From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 16:28:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB64516A41F; Sat, 15 Oct 2005 16:28:15 +0000 (GMT) (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 13AD343D49; Sat, 15 Oct 2005 16:28:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9FGSDtk049292; Sat, 15 Oct 2005 12:28:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9FGSEGd073848; Sat, 15 Oct 2005 12:28:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CC6317302F; Sat, 15 Oct 2005 12:28:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051015162813.CC6317302F@freebsd-current.sentex.ca> Date: Sat, 15 Oct 2005 12:28:13 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha 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, 15 Oct 2005 16:28:16 -0000 TB --- 2005-10-15 15:07:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-15 15:07:32 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-10-15 15:07:32 - cleaning the object tree TB --- 2005-10-15 15:07:58 - checking out the source tree TB --- 2005-10-15 15:07:58 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-10-15 15:07:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-15 15:14:52 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-15 15:14:52 - cd /src TB --- 2005-10-15 15:14:52 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-15 16:19:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 16:19:05 - cd /src TB --- 2005-10-15 16:19:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Oct 15 16:19:05 UTC 2005 >>> 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 [...] awk -f /src/sys/modules/joy/../../conf/kmod_syms.awk joy.kld export_syms | xargs -J% objcopy % joy.kld ld -Bshareable -d -warn-common -o joy.ko.debug joy.kld objcopy --strip-debug joy.ko.debug joy.ko ===> kbdmux (all) cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /obj/alpha/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/obj/alpha/src/sys/GENERIC -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /src/sys/modules/kbdmux/../../dev/kbdmux/kbdmux.c /src/sys/modules/kbdmux/../../dev/kbdmux/kbdmux.c: In function `kbdmux_modevent': /src/sys/modules/kbdmux/../../dev/kbdmux/kbdmux.c:1286: warning: implicit declaration of function `kbd_detach' /src/sys/modules/kbdmux/../../dev/kbdmux/kbdmux.c:1286: warning: nested extern declaration of `kbd_detach' *** Error code 1 Stop in /src/sys/modules/kbdmux. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/alpha/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-15 16:28:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-15 16:28:13 - ERROR: failed to build generic kernel TB --- 2005-10-15 16:28:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 16:33:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F160216A420 for ; Sat, 15 Oct 2005 16:33:39 +0000 (GMT) (envelope-from m.boyarov@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ED3543D4C for ; Sat, 15 Oct 2005 16:33:38 +0000 (GMT) (envelope-from m.boyarov@gmail.com) Received: by qproxy.gmail.com with SMTP id q12so508887qbq for ; Sat, 15 Oct 2005 09:33:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WTUHVOk1B3ijo7aYk7Yrc1qvBdEePW8u29GGY4ctqrpURA5cMg9OG6SYpHlIS/62BCiFu+gL6falvsf3t9ALLZWn/cBt4RMgowlchtco+BdptP1l7tizC/Hyr+jJDmGtcbc0NS/cxuFEfcdCM2FDdYKijZ+LloAc5q8H2mwg4bE= Received: by 10.65.188.8 with SMTP id q8mr593476qbp; Sat, 15 Oct 2005 09:33:38 -0700 (PDT) Received: by 10.64.251.8 with HTTP; Sat, 15 Oct 2005 09:33:38 -0700 (PDT) Message-ID: <87c7bb540510150933w35058cc6i5fe2a11854515f62@mail.gmail.com> Date: Sat, 15 Oct 2005 19:33:38 +0300 From: Max Boyarov To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: mgetty and 6.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: Sat, 15 Oct 2005 16:33:40 -0000 Hello! I have strange problens after upgrading system from BETA5 to RC1. After upgrade i view messages in mgetty log and on serial console and mgett= y does not work 10/15 18:59:04 ad1 mgetty: interim release 1.1.33-Apr10 10/15 18:59:05 ad1 mod: cannot make /dev/cuad1 stdin: Bad file descriptor 10/15 18:59:05 ad1 open device /dev/cuad1 failed: Bad file descriptor 10/15 18:59:05 ad1 cannot get terminal line dev=3Dcuad1, exiting: Bad file descriptor -- 10/15 18:59:18 ad1 mgetty: interim release 1.1.33-Apr10 10/15 18:59:19 ad1 mod: cannot make /dev/cuad1 stdin: Bad file descriptor 10/15 18:59:19 ad1 open device /dev/cuad1 failed: Bad file descriptor 10/15 18:59:19 ad1 cannot get terminal line dev=3Dcuad1, exiting: Bad file descriptor system sources be cvsup'ed 14/10/2005 and mgetty installed from ports What can i do to solve this problem ? -- // Max N. Boyarov // 2:450/262 @ FidoNet From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 18:23:48 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B454D16A41F; Sat, 15 Oct 2005 18:23:48 +0000 (GMT) (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 2BFF843D46; Sat, 15 Oct 2005 18:23:48 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9FINl5e013340; Sat, 15 Oct 2005 14:23:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9FINkoQ053561; Sat, 15 Oct 2005 14:23:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CE9A47302F; Sat, 15 Oct 2005 14:23:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051015182346.CE9A47302F@freebsd-current.sentex.ca> Date: Sat, 15 Oct 2005 14:23:46 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Sat, 15 Oct 2005 18:23:49 -0000 TB --- 2005-10-15 16:28:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-15 16:28:14 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-10-15 16:28:14 - cleaning the object tree TB --- 2005-10-15 16:28:50 - checking out the source tree TB --- 2005-10-15 16:28:50 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-10-15 16:28:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-15 16:35:46 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-15 16:35:46 - cd /src TB --- 2005-10-15 16:35:46 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries TB --- 2005-10-15 18:07:27 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 18:07:27 - cd /src TB --- 2005-10-15 18:07:27 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Oct 15 18:07:27 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Sat Oct 15 18:23:46 UTC 2005 TB --- 2005-10-15 18:23:46 - generating LINT kernel config TB --- 2005-10-15 18:23:46 - cd /src/sys/amd64/conf TB --- 2005-10-15 18:23:46 - /usr/bin/make -B LINT TB --- 2005-10-15 18:23:46 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 18:23:46 - cd /src TB --- 2005-10-15 18:23:46 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 15 18:23:46 UTC 2005 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/amd64/conf; PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/amd64/src/sys/LINT /src/sys/amd64/conf/LINT /src/sys/amd64/conf/LINT: unknown option "SX_DEBUG" *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-15 18:23:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-15 18:23:46 - ERROR: failed to build lint kernel TB --- 2005-10-15 18:23:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 18:34:27 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDB1B16A420; Sat, 15 Oct 2005 18:34:27 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC1C43D48; Sat, 15 Oct 2005 18:34:27 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9FIYRSf049201; Sat, 15 Oct 2005 18:34:27 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9FIYRi8049200; Sat, 15 Oct 2005 18:34:27 GMT (envelope-from csjp) Date: Sat, 15 Oct 2005 18:34:27 +0000 From: "Christian S.J. Peron" To: Robert Watson Message-ID: <20051015183426.GA48081@freefall.freebsd.org> References: <200509220113.06667.lofi@freebsd.org> <20050929221041.H34322@fledge.watson.org> <200509292335.52277.lofi@freebsd.org> <200510120041.03079.lofi@freebsd.org> <20051012150600.O48006@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051012150600.O48006@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Cc: jeff@FreeBSD.org, freebsd-current@FreeBSD.org, Michael Nottebrock Subject: Re: UFS_EXTATTR(_AUTOSTART) broken on 6.0-BETA5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 18:34:28 -0000 On Wed, Oct 12, 2005 at 03:21:00PM +0100, Robert Watson wrote: > > Could you try the attached patch? It appears to work for me here, and > I've committed it as ufs_extattr.c:1.82 in HEAD due to a high confidence > it's the right fix. I will MFC it for 6.x if it also works for you. > > Given that extended attributes seem to be getting little testing with UFS1 > at this point, I'd appreciate it if you could exercise them as much as > possible in testing so we can try to catch any other bugs that may have > crept in as the infrastructure around this code changed. > Robert, Sorry for the long delay on testing this patch, but I have not been in the Province and have been away from my lab. Although I think it's critical that this patch be merged to RELENG_6, it does not appear to solve the problem that I was working on in kern/86550. Kind regards -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer FreeBSD Security Team From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 18:38:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FEA916A41F; Sat, 15 Oct 2005 18:38:12 +0000 (GMT) (envelope-from jdoolittle@kingsquarry.net) Received: from imf22aec.mail.bellsouth.net (imf22aec.mail.bellsouth.net [205.152.59.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A09743D46; Sat, 15 Oct 2005 18:38:11 +0000 (GMT) (envelope-from jdoolittle@kingsquarry.net) Received: from ibm67aec.bellsouth.net ([68.209.160.53]) by imf22aec.mail.bellsouth.net with ESMTP id <20051015183810.IVVS28829.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net>; Sat, 15 Oct 2005 14:38:10 -0400 Received: from saturn.kingsquarry.net ([68.209.160.53]) by ibm67aec.bellsouth.net with ESMTP id <20051015183806.WNKW1915.ibm67aec.bellsouth.net@saturn.kingsquarry.net>; Sat, 15 Oct 2005 14:38:06 -0400 Received: from localhost (localhost.kingsquarry.net [127.0.0.1]) by localhost.kingsquarry.net (Postfix) with ESMTP id 00C1A60DF; Sat, 15 Oct 2005 14:02:22 -0400 (EDT) Received: from saturn.kingsquarry.net ([127.0.0.1]) by localhost (saturn.kingsquarry.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 78103-04-6; Sat, 15 Oct 2005 14:02:20 -0400 (EDT) Received: from [127.0.0.1] (mars.kingsquarry.net [192.168.1.71]) by saturn.kingsquarry.net (Postfix) with ESMTP id 8EB3F60F8; Sat, 15 Oct 2005 14:02:20 -0400 (EDT) Message-ID: <43514425.6020405@kingsquarry.net> Date: Sat, 15 Oct 2005 14:02:13 -0400 From: Jeff Doolittle User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sos@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at kingsquarry.net Cc: Subject: 6.0-RC1 & ASUS P4R800-V/Sis 180 RAID (FAIL) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 18:38:12 -0000 Søren, This post is almost identical to my original request for help on 10/13. I've upgrade one of my machines from 5.4-stable to 6.0-RC1 and the Sis 180 RAID mirror is no longer recognized. The worked perfectly in 5.4.... Attached below is the output from the dmesg based on a World / Generic kernel cvsup'd today: ======================================== Copyright (c) 1992-2005 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 6.0-RC1 #0: Sat Oct 15 13:32:44 EDT 2005 root@mercury.kingsquarry.net:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.86-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x441d> Hyperthreading: 2 logical CPUs real memory = 535756800 (510 MB) avail memory = 514928640 (491 MB) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: Power Button (fixed) pci_link0: irq 0 on acpi0 pci_link1: irq 0 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 0 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) skc0: port 0xe400-0xe4ff mem 0xe1000000-0xe1003fff irq 19 at device 13.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:11:2f:9e:f6:f0 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ohci0: mem 0xe1004000-0xe1004fff irq 19 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe1005000-0xe1005fff irq 19 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: (0x1002) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe1006000-0xe1006fff irq 19 at device 19.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: (0x1002) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 20.1 on pci0 ata0: on atapci0 ata1: on atapci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pci2: on pcib2 fwohci0: port 0xc000-0xc07f mem 0xe0000000-0xe00007ff irq 17 at device 9.0 on pci2 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:00:a2:7f:e5 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:a2:7f:e5 fwe0: Ethernet address: 02:e0:18:a2:7f:e5 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci1: port 0xc400-0xc407,0xc800-0xc803,0xcc00-0xcc07,0xd000-0xd003,0xd400-0xd40f irq 18 at device 10.0 on pci2 ata2: on atapci1 ata3: on atapci1 pci0: at device 20.5 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model VersaPad, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xcc000-0xcffff,0xd0000-0xd3fff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 3006859935 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA100 ad2: DMA limited to UDMA33, device found non-ATA66 cable ad2: 76319MB at ata1-master UDMA33 acd0: CDROM at ata1-slave PIO3 Trying to mount root from ufs:/dev/ad0s1a ======================================== As you can see the SiS 180 is recognized and it's associated SATA controllers (ata2 /ata3) but the ar0 device is never created. I've checked UPDATING but didn't see any comments about existing RAID support being removed so I assume there must be a bug. Thank you! - Jeff From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 18:46:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EED16A41F for ; Sat, 15 Oct 2005 18:46:38 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7E6C43D48 for ; Sat, 15 Oct 2005 18:46:37 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from [192.168.1.10] (stu160022.student.earlham.edu [159.28.160.22]) (authenticated bits=0) by quark.cs.earlham.edu (8.13.4/8.13.3) with ESMTP id j9FIkWCA069599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Oct 2005 13:46:32 -0500 (EST) (envelope-from skylar@cs.earlham.edu) Message-ID: <43514E7C.3000108@cs.earlham.edu> Date: Sat, 15 Oct 2005 13:46:20 -0500 From: Skylar Thompson Organization: Earlham College Computer Science Department User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Coombs References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig084792D87E7ADE0F118A7E58" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (quark.cs.earlham.edu [159.28.230.3]); Sat, 15 Oct 2005 13:46:33 -0500 (EST) X-Virus-Scanned: ClamAV 0.87/1134/Fri Oct 14 03:07:44 2005 on quark.cs.earlham.edu X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.52 on 159.28.230.3 X-Spam-Status: No, score=0.0 required=8.0 tests=none autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on quark.cs.earlham.edu Cc: freebsd-current@freebsd.org Subject: Re: 486DLC Tuning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: skylar@cs.earlham.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 18:46:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig084792D87E7ADE0F118A7E58 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joshua Coombs wrote: > I have a 386 with a Cyrix 486DRx2-66 (clock doubled DLC) that I moved > from 4.11 to 6.0. So far it's running decently, I've got more net/hd > throughput than I had before, by a factor of two for net, but the box > 'feels' like I'm not getting the same cpu perf I had before. Without > benchmarks, I'm not in the best position to prove it, but I figured > I'd try some basic tuning to see if I could improve things. I know SMPng introduces different locking semantics that (for now) reduce CPU performance, but I'm not sure if that only affects SMP boxen or if it also affects uniprocessor boxen as well. -- -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --------------enig084792D87E7ADE0F118A7E58 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.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDUU6Bsc4yyULgN4YRAkVzAJ4uhSw+vuFjfgK79SFCj/cb2cC5WgCaAmdq 5o00hB5wHiuNw2VGlX0uMHo= =c1Un -----END PGP SIGNATURE----- --------------enig084792D87E7ADE0F118A7E58-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 18:54:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7662316A41F for ; Sat, 15 Oct 2005 18:54:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54A743D4C for ; Sat, 15 Oct 2005 18:54:14 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9FIr7Vh006240; Sat, 15 Oct 2005 12:53:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 15 Oct 2005 12:54:19 -0600 (MDT) Message-Id: <20051015.125419.47698820.imp@bsdimp.com> To: freebsd@psam.se From: "M. Warner Losh" In-Reply-To: <4350C749.9070704@psam.se> References: <20051013.213943.05622321.imp@bsdimp.com> <43503EB8.7040509@psam.se> <4350C749.9070704@psam.se> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 15 Oct 2005 12:53:07 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: Thoshiba Tecra 8000 with 3com 3CXFE575CT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 18:54:15 -0000 Please try this patch. I think we've had a minor regression in our PCI BIOS routed interrupts. Also, please try w/o ACPI enabled to see if that changes things. With acpi enabled, I'm not sure this patch will do anything for you. If it does with acpi disabled, it gives a real strong clue what to look for in the acpi code. We used to always route the interrupt, even when the bios said it had one, now it looks like we do that less agressively. Warner Index: pci_pir.c =================================================================== RCS file: /home/ncvs/src/sys/i386/pci/pci_pir.c,v retrieving revision 1.119 diff -u -r1.119 pci_pir.c --- pci_pir.c 8 Sep 2005 17:07:12 -0000 1.119 +++ pci_pir.c 15 Oct 2005 18:51:07 -0000 @@ -348,6 +348,9 @@ irq, entry->pe_bus, entry->pe_device, pin + 'A', pci_link->pl_id); pci_link->pl_irq = irq; + if (!pci_link->pl_routed) + pci_pir_biosroute(entry->pe_bus, entry->pe_device, 0, + pin - 1, pci_link->pl_irq); pci_link->pl_routed = 1; return; } From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 18:55:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75A6116A420; Sat, 15 Oct 2005 18:55:37 +0000 (GMT) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CE4243D4C; Sat, 15 Oct 2005 18:55:37 +0000 (GMT) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9FItbEh049838; Sat, 15 Oct 2005 18:55:37 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9FItalJ049837; Sat, 15 Oct 2005 18:55:36 GMT (envelope-from kan) Date: Sat, 15 Oct 2005 18:55:36 +0000 From: Alexander Kabaev To: Georg Bege Message-ID: <20051015185536.GA49570@freefall.freebsd.org> References: <43510C33.80205@ninth-art.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43510C33.80205@ninth-art.de> User-Agent: Mutt/1.4.2.1i Cc: Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: latest XFS patch doesnt work on RELENG_6 anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 18:55:37 -0000 On Sat, Oct 15, 2005 at 04:03:31PM +0200, Georg Bege wrote: > Hi > > I'm trying to patch my recently fetched RELENG_6 src/sys. > I managed to get it to work some time ago on FreeBSD 6.0-BETA5. > > But now while performing make depend I get: > > [ more stuff cut out ] [ even more stuff cut out ] > So I assume that the latest XFS patch doesnt work anymore on 6.x? Apparently it doesn't. I re-rolled snapshot and uploaded it to http://people.freebsd.org/~kan/xfs/xfs-snap20051015.tar.gz. It should compile on FreeBSD 6.0 and -current just fine. The module Makefile is included this time too. Please give it a try. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 20:06:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7470716A41F; Sat, 15 Oct 2005 20:06:19 +0000 (GMT) (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 0B7FD43D46; Sat, 15 Oct 2005 20:06:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j9FK6IYD018370; Sat, 15 Oct 2005 16:06:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9FK6IRR094554; Sat, 15 Oct 2005 16:06:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B6CFA7302F; Sat, 15 Oct 2005 16:06:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051015200617.B6CFA7302F@freebsd-current.sentex.ca> Date: Sat, 15 Oct 2005 16:06:17 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Sat, 15 Oct 2005 20:06:19 -0000 TB --- 2005-10-15 18:23:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-15 18:23:47 - starting HEAD tinderbox run for i386/i386 TB --- 2005-10-15 18:23:47 - cleaning the object tree TB --- 2005-10-15 18:24:21 - checking out the source tree TB --- 2005-10-15 18:24:21 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-10-15 18:24:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-15 18:30:58 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-15 18:30:58 - cd /src TB --- 2005-10-15 18:30:58 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-15 19:34:57 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 19:34:57 - cd /src TB --- 2005-10-15 19:34:57 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Oct 15 19:34:58 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Sat Oct 15 19:53:01 UTC 2005 TB --- 2005-10-15 19:53:01 - generating LINT kernel config TB --- 2005-10-15 19:53:01 - cd /src/sys/i386/conf TB --- 2005-10-15 19:53:01 - /usr/bin/make -B LINT TB --- 2005-10-15 19:53:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 19:53:01 - cd /src TB --- 2005-10-15 19:53:01 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 15 19:53:01 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/pci/pci_pir.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/i386/svr4/svr4_locore.s cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/svr4/svr4_machdep.c /src/sys/i386/svr4/svr4_machdep.c: In function `svr4_sendsig': /src/sys/i386/svr4/svr4_machdep.c:418: error: argument "ksi" doesn't match prototype /src/sys/compat/svr4/svr4_signal.h:142: error: prototype declaration /src/sys/i386/svr4/svr4_machdep.c:432: error: invalid type argument of `->' /src/sys/i386/svr4/svr4_machdep.c:433: error: invalid type argument of `->' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-15 20:06:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-15 20:06:17 - ERROR: failed to build lint kernel TB --- 2005-10-15 20:06:17 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 21:42:56 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8688616A41F; Sat, 15 Oct 2005 21:42:56 +0000 (GMT) (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 2042F43D46; Sat, 15 Oct 2005 21:42:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id j9FLgsfs062836; Sat, 15 Oct 2005 17:42:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j9FLgs56023118; Sat, 15 Oct 2005 17:42:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 837257302F; Sat, 15 Oct 2005 17:42:54 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051015214254.837257302F@freebsd-current.sentex.ca> Date: Sat, 15 Oct 2005 17:42:54 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Sat, 15 Oct 2005 21:42:56 -0000 TB --- 2005-10-15 20:06:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-10-15 20:06:17 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-10-15 20:06:17 - cleaning the object tree TB --- 2005-10-15 20:06:43 - checking out the source tree TB --- 2005-10-15 20:06:43 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-10-15 20:06:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-10-15 20:13:17 - building world (CFLAGS=-O2 -pipe) TB --- 2005-10-15 20:13:17 - cd /src TB --- 2005-10-15 20:13:17 - /usr/bin/make -B buildworld >>> 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 TB --- 2005-10-15 21:16:57 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 21:16:57 - cd /src TB --- 2005-10-15 21:16:57 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Oct 15 21:16:57 UTC 2005 >>> 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 >>> Kernel build for GENERIC completed on Sat Oct 15 21:31:35 UTC 2005 TB --- 2005-10-15 21:31:35 - generating LINT kernel config TB --- 2005-10-15 21:31:35 - cd /src/sys/pc98/conf TB --- 2005-10-15 21:31:35 - /usr/bin/make -B LINT TB --- 2005-10-15 21:31:35 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-10-15 21:31:35 - cd /src TB --- 2005-10-15 21:31:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 15 21:31:35 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/pci/pci_pir.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/i386/svr4/svr4_locore.s cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/i386/svr4/svr4_machdep.c /src/sys/i386/svr4/svr4_machdep.c: In function `svr4_sendsig': /src/sys/i386/svr4/svr4_machdep.c:418: error: argument "ksi" doesn't match prototype /src/sys/compat/svr4/svr4_signal.h:142: error: prototype declaration /src/sys/i386/svr4/svr4_machdep.c:432: error: invalid type argument of `->' /src/sys/i386/svr4/svr4_machdep.c:433: error: invalid type argument of `->' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-10-15 21:42:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-10-15 21:42:54 - ERROR: failed to build lint kernel TB --- 2005-10-15 21:42:54 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 22:45:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7796A16A41F for ; Sat, 15 Oct 2005 22:45:53 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail21.syd.optusnet.com.au (mail21.syd.optusnet.com.au [211.29.133.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0BDF43D48 for ; Sat, 15 Oct 2005 22:45:52 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail21.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9FMjnk9004091 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 16 Oct 2005 08:45:50 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9FMjlHh014744; Sun, 16 Oct 2005 08:45:49 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9FMjlhq014743; Sun, 16 Oct 2005 08:45:47 +1000 (EST) (envelope-from pjeremy) Date: Sun, 16 Oct 2005 08:45:47 +1000 From: Peter Jeremy To: Joshua Coombs Message-ID: <20051015224547.GF7346@cirb503493.alcatel.com.au> 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@freebsd.org Subject: Re: 486DLC Tuning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2005 22:45:53 -0000 On Sat, 2005-Oct-15 10:06:22 -0400, Joshua Coombs wrote: >I have a 386 with a Cyrix 486DRx2-66 (clock doubled DLC) that I moved >from 4.11 to 6.0. So far it's running decently, I've got more net/hd >throughput than I had before, by a factor of two for net, but the box >'feels' like I'm not getting the same cpu perf I had before. Without >benchmarks, I'm not in the best position to prove it, but I figured >I'd try some basic tuning to see if I could improve things. I suspect your box would be happier running 4.x than 6.x >machine i386 >cpu I386_CPU >cpu I486_CPU According to NOTES: # I386_CPU is mutually exclusive with the other CPU types. # I386_CPU is deprecated and will be removed in 6.0-RELEASE. >It seems odd that I can have CYRIX_CACHE_REALLY_WORKS but not >CYRIX_CACHE_WORKS enabled. This code only functionally affects src/sys/i386/i386/initcpu.c (though CYRIX_CACHE_REALLY_WORKS also disables a 'CPU cache:' message). There has been no change in this code between 4-STABLE and 7-CURRENT. All I can suggest is for you to study the code in conjunction with a Cyrix system programming manual to understand what the effect of the options is. -- Peter Jeremy