From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 06:07:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9ED316A4CE for ; Sun, 19 Dec 2004 06:07:59 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB0F043D1D for ; Sun, 19 Dec 2004 06:07:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 6578FF1A75 for ; Sat, 18 Dec 2004 22:07:59 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00737-01 for ; Sat, 18 Dec 2004 22:07:57 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9EC1EF1C35 for ; Sat, 18 Dec 2004 21:35:15 -0800 (PST) From: Sean McNeil To: current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rauquezPBE+VXOwzZ8UM" Date: Sat, 18 Dec 2004 21:35:15 -0800 Message-Id: <1103434515.1158.10.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at mcneil.com Subject: reboot without any info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 06:08:00 -0000 --=-rauquezPBE+VXOwzZ8UM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This happens with a world/kernel and a portupgrade -frR totem built Today: =46rom rom a user account, I did a gdb `which totem` and then an r. This caused a reboot. This brings up a couple of questions I have. 1) I do not get crash dumps. I have dumpdev=3D/dev/ad4s1b dumpon_enable=3D"YES" savecore_enable=3D"YES" and in my kernel I have makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug = symbols options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. Are these options OK? Should I remove/add something to get it working? 2) I have a firewire port on this machine and several others. Can I use the dconschat on a Linux, Windows, or macos box? Anyone have a version for any of these? I see under google someone asked this back in June, but there there was never any response. Sean --=-rauquezPBE+VXOwzZ8UM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBxRMTyQsGN30uGE4RAuuTAKDiO9PpbqAal44wgq33HIIzZQTnOwCfVRYZ PQtLMiSt1F0F84g6/yOsQq8= =nNh0 -----END PGP SIGNATURE----- --=-rauquezPBE+VXOwzZ8UM-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 07:32:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D1C816A4CE for ; Sun, 19 Dec 2004 07:32:35 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51DCE43D41 for ; Sun, 19 Dec 2004 07:32:35 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id iBJ7WSHC066183 for ; Sat, 18 Dec 2004 23:32:32 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200412190732.iBJ7WSHC066183@gw.catspoiler.org> Date: Sat, 18 Dec 2004 23:32:28 -0800 (PST) From: Don Lewis To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: vnode lock assertion violation in devfs_fixup() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 07:32:35 -0000 I updated my 6-CURRENT machine to today's source, and when I rebooted with the new kernel, I got this lock assertion failure: kern_symlink = 0 Trying to mount root from ufs:/dev/da0s1a kernel_vmount = 0 KDB: stack backtrace: vfs_badlock(c26f3ac8,c08eff00,c26f3ac8,0,c22854c0) at vfs_badlock+0x61 assert_vop_locked(c26f3ac8,c084ed5a,c26f3ac8,e32c4c20,c0676ad9) at assert_vop_lo cked+0x80 vop_unlock_pre(e32c4c08,c08ef780,c26f3ac8,10000,c2285450) at vop_unlock_pre+0x3c vput(c26f3ac8,c2285450,c247d620,c26f4000,c08ef780) at vput+0x89 vfs_mountroot_try(c26ad800,c084280d,204,c05fda98,c2284dc8) at vfs_mountroot_try+ 0x3ad vfs_mountroot(c2285450,c2284dc8,0,e32c4d14,c0632efa) at vfs_mountroot+0x1db start_init(0,e32c4d48,0,c05fda98,0) at start_init+0x4b fork_exit(c05fda98,0,e32c4d48) at fork_exit+0x7e fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe32c4d7c, ebp = 0 --- VOP_UNLOCK: 0xc26f3ac8 is not locked but should be KDB: enter: lock violation [thread pid 1 tid 100003 ] Stopped at kdb_enter+0x2c: leave db> My kernel is built with the DEBUG_VFS_LOCKS option. My November 22nd kernel doesn't have this problem. I'm guessing it is a bug in the recent mountroot changes. The vput() call is actually in devfs_fixup(): mp->mnt_vnodecovered = vp; vp->v_mountedhere = mp; mtx_lock(&mountlist_mtx); TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); mtx_unlock(&mountlist_mtx); VOP_UNLOCK(vp, 0, td); vfs_unbusy(mp, td); VREF(vp); ---> vput(vp); vput(dvp); vput() is supposed to be called with the vnode lock held and it releases the lock, which won't work too well because the vnode was just unlocked 3 lines earlier. vput() also decrements the vnode reference count, but why are we incrementing the reference count on the line above? I suspect that the VREF()/vput() sequence should just go away. In any case, if I just continue from the debugger, the system boots up normally. From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 13:02:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A417C16A4CE for ; Sun, 19 Dec 2004 13:02:53 +0000 (GMT) Received: from portpc-design.spb.ru (ns2.portpc-design.spb.ru [195.161.118.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C01E43D2F for ; Sun, 19 Dec 2004 13:02:52 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [83.237.61.243] (ppp83-237-61-243.pppoe.mtu-net.ru [83.237.61.243]) (authenticated bits=0) by portpc-design.spb.ru (8.13.2/8.13.2) with ESMTP id iBJD2ljL081884; Sun, 19 Dec 2004 16:02:48 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <41C57BF2.2080902@mcsi.pp.ru> Date: Sun, 19 Dec 2004 16:02:42 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041112 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= References: <12004.1102850755@critter.freebsd.dk> <41BDBE43.1000809@club-internet.fr> In-Reply-To: <41BDBE43.1000809@club-internet.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Poul-Henning Kamp cc: freebsd-current@freebsd.org Subject: Re: [TEST] NTFS patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 13:02:53 -0000 Jean-Sébastien Pédron wrote: > Poul-Henning Kamp wrote: > >> Here is a combined patch for the two problems that's been >> reported against NTFS after my mount changes. >> >> Please test & report. > > > With mmap(2), it doesn't panic() anymore, but the content of a file > copied with cp(1) is wrong. > > Here is a small test case: > > ---------------- > # mount > [...] > /dev/ad2s1 on /mnt/ntfs (ntfs, local, read-only) > > # cat /mnt/ntfs/printenv.pl > #!c:/Perl/bin/Perl.exe > ## > ## printenv -- demo CGI program which just prints its environment > ## > > print "Content-type: text/plain\n\n"; > foreach $var (sort(keys(%ENV))) { > $val = $ENV{$var}; > $val =~ s|\n|\\n|g; > $val =~ s|"|\\"|g; > print "${var}=\"${val}\"\n"; > } > > # cp /mnt/ntfs/printenv.pl . > > # xxd -l 64 printenv.pl > 0000000: eb52 904e 5446 5320 2020 2000 0201 0000 .R.NTFS ..... > 0000010: 0000 0000 00f8 0000 3f00 ff00 3f00 0000 ........?...?... > 0000020: 0000 0000 8000 8000 9920 0600 0000 0000 ......... ...... > 0000030: 2000 0000 0000 0000 4c10 0300 0000 0000 .......L....... > > # xxd -l 64 /dev/ad2s1 > 0000000: eb52 904e 5446 5320 2020 2000 0201 0000 .R.NTFS ..... > 0000010: 0000 0000 00f8 0000 3f00 ff00 3f00 0000 ........?...?... > 0000020: 0000 0000 8000 8000 9920 0600 0000 0000 ......... ...... > 0000030: 2000 0000 0000 0000 4c10 0300 0000 0000 .......L....... > ---------------- > > This is with today's CVS. The NTFS file system was prepared under > Windows 2000 SP4. > > In this example, the perl script is ok on the file system, but mmap(2) > return data from he beginning of the file system, not the file. > > From sys/fs/ntfs/ntfs_vnops.c, ntfs_bmap(): > > if (ap->a_bop != NULL) > *ap->a_bop = &ntmp->ntm_devvp->v_bufobj; > if (ap->a_bnp != NULL) > *ap->a_bnp = ap->a_bn; > > The logical block number isn't converted (because it expects > ntfs_strategy() to be called), and bstrategy() will call directly the > device strategy function with the wrong block number. > > Am I the only one to see this behaviour ? No. Me too. Kernel as of Dec 17, mounting WinXP partition. Poul-Henning, are there any new patches to test? -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 14:06:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE64816A4CE for ; Sun, 19 Dec 2004 14:06:31 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-155-73-249.jan.bellsouth.net [68.155.73.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id D889443D2F for ; Sun, 19 Dec 2004 14:06:30 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 4E987210D4; Sun, 19 Dec 2004 08:06:29 -0600 (CST) Date: Sun, 19 Dec 2004 08:06:28 -0600 From: "Matthew D. Fuller" To: Jerry Bell Message-ID: <20041219140628.GJ1378@over-yonder.net> References: <20041218091739.GC97121@cirb503493.alcatel.com.au> <200412181025.iBIAPBOU003187@peedub.jennejohn.org> <4476.24.98.86.57.1103375522.squirrel@24.98.86.57> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4476.24.98.86.57.1103375522.squirrel@24.98.86.57> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.6i-fullermd.2 cc: freebsd-current@freebsd.org Subject: Re: Multiple hard disk failures - coincidence ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 14:06:31 -0000 On Sat, Dec 18, 2004 at 08:12:02AM -0500 I heard the voice of Jerry Bell, and lo! it spake thus: > > I've started adding so form of cooling to all of my hard drives and > I've not lost one since (and I used to lose MANY). Many people > underestimate the effect that heat has on components. I heartily second the motion. I get all twitchy when I see people put hard drives in a system without a fan directly on them; some of 'em even put drives in places where there's no circulation at all! Y'know, the one part of the system with very delicate and very moving parts, and that's the piece they decide to cool the least! I always put my drives in these: and they've worked wonders. The increase in density (3 drives in 2 HH slots) is a nice plus, too; and with the fan, the density doesn't blow out the heat as well. Not the cheapest such things out there, but they're built like a tank and I haven't had a fan out of 'em die on me yet. The only thing I'd change about 'em if I could would be to adjust the way the front metal piece holds the filter on, so you can get it out to clean without having to pull the front of the case off. It's easy enough to hack together such a mechanism for home use of course, but I was thinking something more suitable for colos. Of course, it means I need to be more careful to get cases with lots of exposed 5.25" bays; I never use the infernal[0] 3.5"ers, except on specialty cases that already have a big fan in front of 'em. [0] Yes, that's what I really mean 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 13:27:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 722BE16A4CE for ; Sun, 19 Dec 2004 13:27:53 +0000 (GMT) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08EF943D39 for ; Sun, 19 Dec 2004 13:27:53 +0000 (GMT) (envelope-from tmseck@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-247-105.netcologne.de [213.196.247.105]) by smtp2.netcologne.de (Postfix) with SMTP id 035E745F1 for ; Sun, 19 Dec 2004 14:27:51 +0100 (MET) Received: (qmail 901 invoked by uid 1001); 19 Dec 2004 13:28:12 -0000 Date: Sun, 19 Dec 2004 14:27:50 +0100 From: Thomas-Martin Seck To: freebsd-current@freebsd.org Message-ID: <20041219132750.GA883@laurel.tmseck.homedns.org> Mail-Followup-To: freebsd-current@freebsd.org, noackjr@alumni.rice.edu References: <20041210155518.O63382@carver.gumbysoft.com> <20041211155825.16409.qmail@laurel.tmseck.homedns.org> <55260.69.53.57.66.1102966067.squirrel@69.53.57.66> <20041214190732.GA689@laurel.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041214190732.GA689@laurel.tmseck.homedns.org> User-Agent: Mutt/1.4.2.1i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms X-Mailman-Approved-At: Sun, 19 Dec 2004 14:57:21 +0000 Subject: Re: FreeBSD sound distortion problems with SB Live! fixed with PREEMPTION X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 13:27:53 -0000 * Thomas-Martin Seck (tmseck-lists@netcologne.de): > * Jon Noack (noackjr@alumni.rice.edu): > > > Thomas-Martin Seck wrote: > > [Sound slowdown on an es137x system] > > > Try my es137x patch: > > http://www.noacks.org/freebsd/es137x.diff > > > > Among other things, it incorporates: > > * Locking and INTR_MPSAFE (PR kern/59349) > > * S/PDIF output (PR kern/68594) > > > > Thanks, I'll try it out over the weekend! I tried it out and it "works for me" in all scenarios that were problematic before. Thanks! From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 18:31:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F7DA16A4CE for ; Sun, 19 Dec 2004 18:31:48 +0000 (GMT) Received: from bombadil.mebtel.net (bombadil.mebtel.net [64.40.67.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B9DC43D1D for ; Sun, 19 Dec 2004 18:31:47 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from localhost (localhost [127.0.0.1]) by bombadil.mebtel.net (Postfix) with ESMTP id B397C2085D2 for ; Sun, 19 Dec 2004 13:31:46 -0500 (EST) Received: from bombadil.mebtel.net ([127.0.0.1]) by localhost (bombadil [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02167-05 for ; Sun, 19 Dec 2004 13:31:46 -0500 (EST) Received: from lorne.arm.org (66-79-79-182.dsl.mebtel.net [66.79.79.182]) by bombadil.mebtel.net (Postfix) with ESMTP id 3E9462085B6 for ; Sun, 19 Dec 2004 13:31:46 -0500 (EST) Received: from lorne.arm.org (localhost [127.0.0.1]) by lorne.arm.org (8.13.1/8.12.9) with ESMTP id iBJIVjmx099019 for ; Sun, 19 Dec 2004 13:31:45 -0500 (EST) (envelope-from dlt@lorne.arm.org) Received: (from dlt@localhost) by lorne.arm.org (8.13.1/8.13.1/Submit) id iBJIVjlx099016; Sun, 19 Dec 2004 13:31:45 -0500 (EST) (envelope-from dlt) Date: Sun, 19 Dec 2004 13:31:45 -0500 (EST) Message-Id: <200412191831.iBJIVjlx099016@lorne.arm.org> From: Derek Tattersall To: current@FreeBSD.org X-Virus-Scanned: by amavisd-new at mebtel.net Subject: Buildworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2004 18:31:48 -0000 I have rebuilt current last Sunday and today. Last Sunday, buildworld failed with default make.conf. I found it would build with CFLAGS=-O -pipe . It failed building insn-attrtab with an internal compiler error. Today, after cvsup'ing this morning, it would not build with default make.conf. Switching to the above CFLAGS, it fails building c_common.c with the same internal compiler error. /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c: In function ` c_common_nodes_and_builtins': /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:3465: internal compiler error: in control_flow_insn_p, at cfgbuild.c:130 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I have not submitted a report to gcc because I am not confident that this is really a compiler problem. Before last week, buildworld worked (or didn't) quite straightforwardly. This problem has me completely baffled. Hardware is ASUS A7V with AMD Athlon XP 2800+. It seems like vanilla hardware. Memtest86 run for 1-2 hours shows no problems with the memory. The CPU is not overclocked, (1650 Mhz). 1 gig of Crucial pc2700 memory. -- Derek Tattersall dlt@mebtel.net dlt666@yahoo.com From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 20:17:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D69F516A4CE for ; Sun, 19 Dec 2004 20:17:20 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA1543D54 for ; Sun, 19 Dec 2004 20:17:20 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) iBJKHI8W099503; Sun, 19 Dec 2004 15:17:18 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)iBJKH94J099499; Sun, 19 Dec 2004 15:17:18 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 19 Dec 2004 15:17:09 -0500 (EST) From: Andre Guibert de Bruet To: Sean McNeil In-Reply-To: <1103434515.1158.10.camel@server.mcneil.com> Message-ID: <20041219150157.O19917@alpha.siliconlandmark.com> References: <1103434515.1158.10.camel@server.mcneil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: reboot without any info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 20:17:21 -0000 On Sat, 18 Dec 2004, Sean McNeil wrote: > This happens with a world/kernel and a portupgrade -frR totem built > Today: > > From rom a user account, I did a gdb `which totem` and then an r. This > caused a reboot. > > This brings up a couple of questions I have. > > 1) I do not get crash dumps. I have Your lack of any text at the console before the reboot indicates that a hardware problem (Overheating CPU, defective memory, overheating ata drives) is likely to be the cause of your woes. > dumpdev=/dev/ad4s1b > dumpon_enable="YES" > savecore_enable="YES" You forgot to specify dumpdir, the target directory for your core dump. I don't recall the existance of savecore_enable and it doesn't seem to be documented in /etc/defaults/rc.conf, either. Having unused options in rc.conf will, of course, not stop your dump from happening... > and in my kernel I have > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > > Are these options OK? Should I remove/add something to get it working? If you are suspecting bad behavior in your kernel, you probabaly should enable INVARIANTS and WITNESS as well. As I previously stated, at this point, you should probably start by examining the hardware FreeBSD is running on. In the future, I suggest that you paste the output of a `uname -a` with any bug reports as well as URL for the dmesg of the machine. It helps track things a bit better. :-) Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 20:44:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B33016A4CE; Sun, 19 Dec 2004 20:44:02 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E223943D1F; Sun, 19 Dec 2004 20:44:01 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id iBJKhr0n047218; Sun, 19 Dec 2004 12:43:53 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id iBJKhqmi047217; Sun, 19 Dec 2004 12:43:52 -0800 (PST) (envelope-from obrien) Date: Sun, 19 Dec 2004 12:43:52 -0800 From: "David O'Brien" To: Matt Rowley Message-ID: <20041219204352.GA42665@dragon.nuxi.com> References: <20041211004038.GC50516@dragon.nuxi.com> <11A4B937C9C745F2DD5B75EC@elric.arin.net> <20041217081458.GB10368@dan.emsphone.com> <41C30321.5060209@freebsd.org> <22C3670E71A83C719BAC25E9@elric.arin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22C3670E71A83C719BAC25E9@elric.arin.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Dan Nelson cc: freebsd-current@freebsd.org cc: Scott Long Subject: Re: FreeBSD 5.3 and Adaptec raidutils (again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2004 20:44:02 -0000 On Fri, Dec 17, 2004 at 11:50:10AM -0500, Matt Rowley wrote: > >>Yes; you can work around it by declaring a temp variable, assigning it > >>the value of attachedTo, making whatever modification is necessary, > >>then assigning attachedTo=temp. Do this every time you get that error. > >>You /might/ also be able to just remove the PACKed attribute from the > >>attachedTo field, but that will cause havoc if the struct is supposed > >>to line up with something generated by the card. > >> > > > >I'd highly recommend against removing the packed attribute. > > :) It does compile, when you remove packed. After commenting out the > unneeded semaphore union struct in basic.hh, the whole thing compiles. The > resulting raidutil binary spews out the same error as the one from the > current binary port about "Engine connect failed: COMPATIBILITY number"... > but that's to be expected. Can you post a patch to the sources? We should make the port build from source, but it never rose high enough on my priority list. Is anyone interested in working with me in updating the port? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Dec 19 20:53:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD95616A4CE for ; Sun, 19 Dec 2004 20:53:45 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F33E43D1F for ; Sun, 19 Dec 2004 20:53:45 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 1C6BFF2088; Sun, 19 Dec 2004 12:53:45 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04813-02; Sun, 19 Dec 2004 12:53:42 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 87A1FF1EE7; Sun, 19 Dec 2004 12:53:42 -0800 (PST) From: Sean McNeil To: Andre Guibert de Bruet In-Reply-To: <20041219150157.O19917@alpha.siliconlandmark.com> References: <1103434515.1158.10.camel@server.mcneil.com> <20041219150157.O19917@alpha.siliconlandmark.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k7UaGwZn3W9gKUkExuWY" Date: Sun, 19 Dec 2004 12:53:42 -0800 Message-Id: <1103489622.5226.6.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at mcneil.com cc: current@freebsd.org Subject: Re: reboot without any info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 19 Dec 2004 20:53:46 -0000 --=-k7UaGwZn3W9gKUkExuWY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-12-19 at 15:17 -0500, Andre Guibert de Bruet wrote: > On Sat, 18 Dec 2004, Sean McNeil wrote: >=20 > > This happens with a world/kernel and a portupgrade -frR totem built > > Today: > > > > From rom a user account, I did a gdb `which totem` and then an r. This > > caused a reboot. > > > > This brings up a couple of questions I have. > > > > 1) I do not get crash dumps. I have >=20 > Your lack of any text at the console before the reboot indicates that a=20 > hardware problem (Overheating CPU, defective memory, overheating ata=20 > drives) is likely to be the cause of your woes. I think everyone has hardware fault on the brain right now. Please note that the system works perfectly - even under extreme load - until the moment I run totem in the debugger. Then it is instant. I would never consider this behavior as hardware related. > > dumpdev=3D/dev/ad4s1b > > dumpon_enable=3D"YES" > > savecore_enable=3D"YES" >=20 > You forgot to specify dumpdir, the target directory for your core dump. I= =20 > don't recall the existance of savecore_enable and it doesn't seem to be=20 > documented in /etc/defaults/rc.conf, either. Having unused options in=20 > rc.conf will, of course, not stop your dump from happening... dumpdir is set as /var/crash in /etc/defaults/rc.conf. So that cannot be it. And yes, savecore_enable cannot hurt if not needed. > > and in my kernel I have > > > > makeoptions DEBUG=3D-g # Build kernel with gdb(1) de= bug symbols > > options KDB # Enable kernel debugger suppor= t. > > options DDB # Support DDB. > > options GDB # Support remote GDB. > > > > Are these options OK? Should I remove/add something to get it working? >=20 > If you are suspecting bad behavior in your kernel, you probabaly should=20 > enable INVARIANTS and WITNESS as well. As I previously stated, at this=20 > point, you should probably start by examining the hardware FreeBSD is=20 > running on. I can turn these on. I will do that. The suggestion that this is hardware related is ludicrous, though. > In the future, I suggest that you paste the output of a `uname -a` with=20 > any bug reports as well as URL for the dmesg of the machine. It helps=20 > track things a bit better. :-) Here is the uname: FreeBSD server.mcneil.com 6.0-CURRENT FreeBSD 6.0-CURRENT #29: Sat Dec 18 19:39:10 PST 2004 root@server.mcneil.com:/usr/obj/usr/src/sys/AMD64 amd64 and here is dmesg: Copyright (c) 1992-2004 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-CURRENT #29: Sat Dec 18 19:39:10 PST 2004 root@server.mcneil.com:/usr/obj/usr/src/sys/AMD64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (2000.08-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0xfc0 Stepping =3D 0 Features=3D0x78bfbff AMD Features=3D0xe0500800 real memory =3D 2147418112 (2047 MB) avail memory =3D 2064875520 (1969 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) 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_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xd7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) fwohci0: port 0xd400-0xd47f mem 0xcfffb800-0xcfffbfff irq 17 at device 6.0 on pci0 fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:11:06:00:00:00:75:68 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S100, max_rec 2 bytes. fwohci0: max_rec 2 -> 2048 firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:06:00:75:68 fwe0: Ethernet address: 02:11:06:00:75:68 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) dc0: port 0xd000-0xd0ff mem 0xcfffb400-0xcfffb7ff irq 19 at device 8.0 on pci0 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:03:6d:1a:b1:9b dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] re0: port 0xcc00-0xccff mem 0xcfffb300-0xcfffb3ff irq 16 at device 11.0 on pci0 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:0c:76:e9:2c:58 atapci0: port 0xd800-0xd8ff,0xdc00-0xdc0f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec0= 0-0xec07 irq 20 at device 15.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 uhci0: port 0xbc00-0xbc1f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc000-0xc01f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci2: port 0xc400-0xc41f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc800-0xc81f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 ehci0: mem 0xcfffb100-0xcfffb1ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: single transaction translator uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pcm0: port 0xb800-0xb8ff irq 22 at device 17.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci_link0: irq 11 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 12 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 0 on acpi0 acpi_button1: 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 ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xe0000-0xe0fff 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 2000084231 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, rule-based forwarding enabled, default to deny, logging disabled ad0: 117246MB [238216/16/63] at ata0-master UDMA133 ad1: 117246MB [238216/16/63] at ata0-slave UDMA133 ata1-slave: DMA limited to UDMA33, non-ATA66 cable or device acd0: DVDR at ata1-master UDMA33 acd1: DVDROM at ata1-slave UDMA33 ad4: 76319MB [155061/16/63] at ata2-master SATA150 ar0: 117246MB [14946/255/63] status: READY subdisks: disk0 READY on ad0 at ata0-master disk1 READY on ad1 at ata0-slave ums0: at uhub1 port 2 (addr 2) disconnected ums0: detached ucom0: at uhub3 port 2 (addr 2) disconnected All threads purged from cuaU0 All threads purged from ttyU0 ucom0: detached ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [746112 x 2048 byte records] cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present kern_symlink =3D 0 Trying to mount root from ufs:/dev/ad4s1a kernel_vmount =3D 0 Cheers, Sean --=-k7UaGwZn3W9gKUkExuWY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBxepWyQsGN30uGE4RAsBMAKCnhkNQbmjRW1n1sIHH3thXr2a3kwCdFY8L CKZzaHp9IRKSffXwvLy5kiM= =JyXc -----END PGP SIGNATURE----- --=-k7UaGwZn3W9gKUkExuWY-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 00:27:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EF2F16A4CE for ; Mon, 20 Dec 2004 00:27:17 +0000 (GMT) Received: from teby.sfina.com (teby.sfina.com [216.194.67.3]) by mx1.FreeBSD.org (Postfix) with SMTP id D12C843D3F for ; Mon, 20 Dec 2004 00:27:16 +0000 (GMT) (envelope-from freebsd-current@sfina.com) Received: (qmail 5982 invoked from network); 20 Dec 2004 00:23:23 -0000 Received: from unknown (HELO sfina.com) (127.0.0.1) by 0 with SMTP; 20 Dec 2004 00:23:23 -0000 Received: from c207.134.49-168.clta.globetrotter.net ([207.134.49.168]) (SquirrelMail authenticated user yuv01@sfina.com) by teby.sfina.com with HTTP; Mon, 20 Dec 2004 01:23:23 +0100 (CET) Message-ID: <4955.207.134.49.168.1103502203.squirrel@teby.sfina.com> Date: Mon, 20 Dec 2004 01:23:23 +0100 (CET) From: "Yuval Levy" To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Spam Problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 00:27:17 -0000 Hi all I am not sure if there is awareness of a spam problem with this list. While spam might be off topic, it is a nuisance to all of us so I allow myself to post my findings here in the hope that it will help the list identify and get rid of the problem. I subscribed to this list with a unique alias (freebsd-current@sfina.com) that I used for this specific list only. I do this with every mailing list I subscribe to, so to insulate the spam problem should it arise by diverting the alias to /dev/null. On my mail server all of the alias in use are collected into a single mailbox for reading. Recently I received some spams to freebsd-current@sfina.com. This happened after I used that alias to post to the list. My suspicion is that a spammer is subscribed to this list and uses his subscription to harvest email addresses. Whenever a user posts a messages, his email address is published to all the list in the From header. It does not take much to parse incoming messages from the list to harvest addresses. Is anybody else aware of this problem? Has there been any thought about a possible solution? Thanks Yuval From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 00:43:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48A7C16A4CE for ; Mon, 20 Dec 2004 00:43:23 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8D6C43D58 for ; Mon, 20 Dec 2004 00:43:22 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.1/8.13.1) with ESMTP id iBK0hMoB001583; Sun, 19 Dec 2004 16:43:22 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.1/8.13.1/Submit) id iBK0hMOm001582; Sun, 19 Dec 2004 16:43:22 -0800 (PST) (envelope-from david) Date: Sun, 19 Dec 2004 16:43:22 -0800 (PST) From: David Wolfskill Message-Id: <200412200043.iBK0hMOm001582@bunrab.catwhisker.org> To: freebsd-current@sfina.com In-Reply-To: <4955.207.134.49.168.1103502203.squirrel@teby.sfina.com> cc: current@freebsd.org Subject: Re: Spam Problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: postmaster@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: Mon, 20 Dec 2004 00:43:23 -0000 >Date: Mon, 20 Dec 2004 01:23:23 +0100 (CET) >From: "Yuval Levy" Note: the topic is off-topic for freebsd-current. I am posting back to the list solely to help prevent an onslaught of off=-topic responses. I have provided a hint (Reply-To:) to mail clients that wish to make use of it. -- postmaster >I am not sure if there is awareness of a spam problem with this list. >While spam might be off topic, it is a nuisance to all of us so I allow >myself to post my findings here in the hope that it will help the list >identify and get rid of the problem. If you have concerns about mail issues for FreeBSD.org, please feel free to contact postmaster@freebsd.org. Please do not try to hijack technical mailing lists that are intended for other purposes. The freebsd-curreent@freebsd.org list is one example of such a list where "spam" (per se) is off-topic. >I subscribed to this list with a unique alias (freebsd-current@sfina.com) >that I used for this specific list only. I do this with every mailing list >I subscribe to, so to insulate the spam problem should it arise by >diverting the alias to /dev/null. On my mail server all of the alias in >use are collected into a single mailbox for reading. >Recently I received some spams to freebsd-current@sfina.com. This happened >after I used that alias to post to the list. You do realize, of course, that posts to freebsd-current@ are archived in a publicly-accessible manner by the FreeBSD project, and are also gatewayed to other facilities that are searchable via Web search engines or to USENET newsgroups? >My suspicion is that a spammer is subscribed to this list and uses his >subscription to harvest email addresses. That could be, but it's rather more complicated than necessary to accomplish the foul deed. Recall Occam's Razor. >Whenever a user posts a messages, his email address is published >to all the list in the From header. It does not take much to parse >incoming messages from the list to harvest addresses. Yes.... >Is anybody else aware of this problem? Of course. >Has there been any thought about a possible solution? I'm sure there has. I suggest you consider adjusting your filter so that mail to the list-specific address in question is less likely to be considered spam if it is relayed via mx2.freebsd.org, and considered more likely otherwise. (You might want to consider the message less likely to be spam if it appears to be in reply to a message you wrote, but thta could get complicated.) Now, everyone: please do not continue this discussion on any of the freebsd.org technical mailing lists. If you must continue it on a list, I nominate freebsd-chat. Peace, david (current hat: postmaster@freebsd.org) -- David H. Wolfskill david@catwhisker.org I resent spammers because spam is a DoS attack on my time. See http://www.catwhisker.org/~david/publickey.gpg for public key. From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 01:34:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1E5116A4CE for ; Mon, 20 Dec 2004 01:34:31 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EDE843D1D for ; Mon, 20 Dec 2004 01:34:31 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) iBK1YTOS001976; Sun, 19 Dec 2004 20:34:29 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)iBK1YNdp001973; Sun, 19 Dec 2004 20:34:29 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 19 Dec 2004 20:34:23 -0500 (EST) From: Andre Guibert de Bruet To: Sean McNeil In-Reply-To: <1103489622.5226.6.camel@server.mcneil.com> Message-ID: <20041219194045.S99984@alpha.siliconlandmark.com> References: <1103434515.1158.10.camel@server.mcneil.com> <1103489622.5226.6.camel@server.mcneil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: reboot without any info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 01:34:31 -0000 On Sun, 19 Dec 2004, Sean McNeil wrote: > On Sun, 2004-12-19 at 15:17 -0500, Andre Guibert de Bruet wrote: >> On Sat, 18 Dec 2004, Sean McNeil wrote: >> >>> This happens with a world/kernel and a portupgrade -frR totem built >>> Today: >>> >>> From rom a user account, I did a gdb `which totem` and then an r. This >>> caused a reboot. [snip] > I think everyone has hardware fault on the brain right now. Please note > that the system works perfectly - even under extreme load - until the > moment I run totem in the debugger. Then it is instant. I would never > consider this behavior as hardware related. I would suggest hooking up a serial or firewire console on this machine and logging any output. If nothing relevant turns up, you may wish to try and reproduce the problem while running gdb under strace or truss (I am not familiar with the status of these programs under AMD64. YMMV) while logged at a serial console. Regards, | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 05:42:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9413A16A4CE for ; Mon, 20 Dec 2004 05:42:11 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFFD843D45 for ; Mon, 20 Dec 2004 05:42:10 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iBK5f7E4005281 for ; Mon, 20 Dec 2004 16:11:08 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Mon, 20 Dec 2004 16:12:04 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iBK5ZSQ27384 for ; Mon, 20 Dec 2004 16:05:28 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK369RQZ; Mon, 20 Dec 2004 16:05:12 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iBK5aJW5038589 for ; Mon, 20 Dec 2004 16:06:19 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iBK5aJlQ038588 for freebsd-current@freebsd.org; Mon, 20 Dec 2004 16:06:19 +1030 (CST) (envelope-from wilkinsa) Date: Mon, 20 Dec 2004 16:06:19 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20041220053619.GO36954@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: [buildworld failure] "/usr/src/Makefile.inc1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 05:42:11 -0000 FreeBSD 5.3-STABLE #12: Thu Nov 18 16:30:58 CST 2004 # sudo make buildworld Password: "/usr/src/Makefile.inc1", line 117: CPUTYPE global should be set with ?=. *** Error code 1 Stop in /usr/src. My CPUTYPE is set to I686_CPU - aW From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 06:23:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C55816A4CE for ; Mon, 20 Dec 2004 06:23:53 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1821443D4C for ; Mon, 20 Dec 2004 06:23:51 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBK6NliV037224; Mon, 20 Dec 2004 16:53:47 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 20 Dec 2004 16:53:28 +1030 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1488347.b9YHmtegtK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412201653.42932.doconnor@gsoft.com.au> X-Spam-Score: -3.3 () PGP_SIGNATURE_2,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Lack of success with if_ndis comes with matching funny carbus messages. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 06:23:53 -0000 --nextPart1488347.b9YHmtegtK Content-Type: multipart/mixed; boundary="Boundary-01=_g/mxBSTgWaCSo8L" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_g/mxBSTgWaCSo8L Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, A guy at work got an Alloy WLT24501 Cardbus WiFi adadpter=20 (http://www.alloy.com.au/products/wlt245401.html) and I am trying to get it working (I have an Intel Pro 2100 mini-PCI) I have a kernel cvs from the 9th of December and I obtained the following=20 driver "http://www.alloy.com.au/web_download/Wireless/54Mb/WLT245401_VP/WLT= 245401VP_Ver. 1.20.zip" I copied FW1130.BIN FwRad16.bin and FwRad17.bin to /compat/ndis and ran the= =20 following commands to build the driver.. ndiscvt -i TNET1130.INF -s tnet1130.sys -n wlt -o ndis_driver_data.h make kldload ./if_ndis.ko Before the kldload I inserted the card.. Dec 20 16:09:33 inchoate kernel: Status is 0x30000820 Dec 20 16:09:33 inchoate kernel: cbb0: card inserted: event=3D0x00000000, s= tate=3D30000820 Dec 20 16:09:33 inchoate kernel: cbb0: cbb_power: 3V Dec 20 16:09:33 inchoate kernel: pcib2: device cardbus0 requested decoded m= emory range 0xf6000000-0xfbffffff Dec 20 16:09:33 inchoate kernel: cardbus0: Expecting link target, got 0x8 Dec 20 16:09:33 inchoate kernel: cardbus0: Resource not specified in CIS: i= d=3D10, size=3D2000 Dec 20 16:09:33 inchoate kernel: cardbus0: Resource not specified in CIS: i= d=3D14, size=3D20000 Dec 20 16:09:33 inchoate kernel: pcib2: device cardbus0 requested decoded m= emory range 0xf6000000-0xfbffffff Dec 20 16:09:33 inchoate kernel: found-> vendor=3D0x104c, dev=3D0x90= 66, revid=3D0x00 Dec 20 16:09:33 inchoate kernel: bus=3D3, slot=3D0, func=3D0 Dec 20 16:09:33 inchoate kernel: class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 Dec 20 16:09:33 inchoate kernel: cmdreg=3D0x0000, statreg=3D0x0210, cacheln= sz=3D8 (dwords) Dec 20 16:09:33 inchoate kernel: lattimer=3D0xa8 (5040 ns), mingnt=3D0x00 (= 0 ns), maxlat=3D0x00 (0 ns) Dec 20 16:09:33 inchoate kernel: intpin=3Da, irq=3D11 Dec 20 16:09:33 inchoate kernel: powerspec 2 supports D0 D1 D2 D3 current= D0 Dec 20 16:09:33 inchoate kernel: cardbus0: at device 0.0 (no driv= er attached) Dec 20 16:09:33 inchoate kernel: pci3:0:0: Transition from D0 to D3 Dec 20 16:09:33 inchoate kernel: cbb0: cbb_power: 0V Dec 20 16:09:33 inchoate kernel: cbb0: CardBus card activation failed Dec 20 16:09:33 inchoate kernel: Status is 0x30000086 I removed it, loaded the driver and reinstered.. Dec 20 16:18:46 inchoate kernel: Status is 0x30000920 Dec 20 16:18:46 inchoate kernel: cbb0: card inserted: event=3D0x00000000, s= tate=3D30000920 Dec 20 16:18:46 inchoate kernel: cbb0: cbb_power: 3V Dec 20 16:18:46 inchoate kernel: pcib2: device cardbus0 requested decoded m= emory range 0xf6000000-0xfbffffff Dec 20 16:18:46 inchoate kernel: cardbus0: Expecting link target, got 0x8 Dec 20 16:18:46 inchoate kernel: cardbus0: Resource not specified in CIS: i= d=3D10, size=3D2000 Dec 20 16:18:46 inchoate kernel: cardbus0: Resource not specified in CIS: i= d=3D14, size=3D20000 Dec 20 16:18:46 inchoate kernel: pcib2: device cardbus0 requested decoded m= emory range 0xf6000000-0xfbffffff Dec 20 16:18:46 inchoate kernel: found-> vendor=3D0x104c, dev=3D0x90= 66, revid=3D0x00 Dec 20 16:18:46 inchoate kernel: bus=3D3, slot=3D0, func=3D0 Dec 20 16:18:46 inchoate kernel: class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 Dec 20 16:18:46 inchoate kernel: cmdreg=3D0x0000, statreg=3D0x0210, cacheln= sz=3D8 (dwords) Dec 20 16:18:46 inchoate kernel: lattimer=3D0xa8 (5040 ns), mingnt=3D0x00 (= 0 ns), maxlat=3D0x00 (0 ns) Dec 20 16:18:46 inchoate kernel: intpin=3Da, irq=3D11 Dec 20 16:18:46 inchoate kernel: powerspec 2 supports D0 D1 D2 D3 current= D0 Dec 20 16:18:46 inchoate kernel: wlt0: mem 0xf6040000-0xf605ffff,0xf6060000-0xf6061fff irq 11 at device 0.= 0 on cardbus0 Dec 20 16:18:46 inchoate kernel: pcib2: device wlt0 requested decoded memor= y range 0xf6040000-0xf605ffff Dec 20 16:18:46 inchoate kernel: pcib2: device wlt0 requested decoded memor= y range 0xf6060000-0xf6061fff Dec 20 16:18:46 inchoate kernel: wlt0: [MPSAFE] Dec 20 16:18:46 inchoate kernel: wlt0: NDIS API version: 5.1 Dec 20 16:18:49 inchoate kernel: wlt0: bpf attached Dec 20 16:18:49 inchoate kernel: wlt0: Ethernet address: 00:00:8c:00:50:de Dec 20 16:18:49 inchoate kernel: wlt0: bpf attached I then did.. ifconfig wlt0 ssid citilan up mode 11b media autoselect=20 After a minute or so of polling with wicontrol wlt0 -L an AP showed up, but ifconfig did not show it associated, nor did a 'link up' message get displayed by the kernel. While sitting in the same location I unloaded the driver and loaded the one for the mini-PCI adapter - it worked and associat= ed straight away. I have not tried the acx driver from wlan.kewl.org as it hasn't been update= d=20 for the new 802.11 stuff that was committed, and I haven't had time to go b= ack to before then and play around. Attached is a boot -v dmesg with cbb and cardbus debugging on. =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=_g/mxBSTgWaCSo8L Content-Type: text/plain; charset="us-ascii"; name="wlt-log.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="wlt-log.txt" Copyright (c) 1992-2004 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. =46reeBSD 6.0-CURRENT #2: Mon Dec 20 15:44:52 CST 2004 darius@inchoate.localdomain:/usr/obj/usr/src/sys/INCHOATE Preloaded elf kernel "/boot/kernel/kernel" at 0xc0970000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc0970158. Preloaded elf module "/boot/kernel/if_bfe.ko" at 0xc0970204. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc09702b0. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc097035c. Preloaded elf module "/boot/kernel/sound.ko" at 0xc0970408. Preloaded elf module "/boot/kernel/ugen.ko" at 0xc09704b4. Preloaded elf module "/boot/kernel/usb.ko" at 0xc0970560. Preloaded elf module "/boot/kernel/ums.ko" at 0xc0970608. Preloaded elf module "/boot/kernel/umass.ko" at 0xc09706b0. Preloaded elf module "/boot/kernel/umodem.ko" at 0xc097075c. Preloaded elf module "/boot/kernel/ucom.ko" at 0xc0970808. Preloaded elf module "/boot/kernel/random.ko" at 0xc09708b4. Preloaded elf module "/boot/kernel/sbp.ko" at 0xc0970960. Preloaded elf module "/boot/kernel/firewire.ko" at 0xc0970a08. Preloaded elf module "/boot/modules/nvidia.ko" at 0xc0970ab8. Preloaded elf module "/boot/kernel/if_fwip.ko" at 0xc0970b64. Preloaded elf module "/boot/kernel/if_fwe.ko" at 0xc0970c10. Preloaded elf module "/boot/kernel/wlan.ko" at 0xc0970cbc. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0970d68. Calibrating clock(s) ... i8254 clock: 1193177 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1398819595 Hz CPU: Intel(R) Pentium(R) M processor 1400MHz (1398.82-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x695 Stepping =3D 5 Features=3D0xa7e9f9bf real memory =3D 536535040 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f67efff, 514170880 bytes (125530 pages) avail memory =3D 515796992 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry =3D 0xffe90 (c00ffe90) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0xc97e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry =3D f0000:e2f4 Rev =3D 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> mem: Pentium Pro MTRR support enabled random: null: io: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000eac4 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D33408086) pcibios: BIOS version 2.10 =46ound $PIR table, 9 entries at 0xc00fc590 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 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 0 31 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 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 0 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 1 B 0x63 none embedded 2 3 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 B 0x63 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 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 atpic: Programming IRQ9 as level/low 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_tz0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 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 11 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 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 11 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 9 10 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 9 10 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 9 10 11 pci_link4: irq 11 on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 3, range 32, base e0000000, size 27, enabled found-> vendor=3D0x8086, dev=3D0x3340, revid=3D0x03 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x3341, revid=3D0x03 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x00 (0 ns) map[20]: type 4, range 32, base 0000bf80, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LNKA:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LNKA found-> vendor=3D0x8086, dev=3D0x24c2, revid=3D0x01 bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type 4, range 32, base 0000bf40, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.PCI0.LNKD:0) pcib0: slot 29 INTB routed to irq 11 via \\_SB_.PCI0.LNKD found-> vendor=3D0x8086, dev=3D0x24c4, revid=3D0x01 bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type 4, range 32, base 0000bf20, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.PCI0.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \\_SB_.PCI0.LNKC found-> vendor=3D0x8086, dev=3D0x24c7, revid=3D0x01 bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[10]: type 1, range 32, base f4fffc00, size 10, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.PCI0.LNKH:0) pcib0: slot 29 INTD routed to irq 11 via \\_SB_.PCI0.LNKH found-> vendor=3D0x8086, dev=3D0x24cd, revid=3D0x01 bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D11 powerspec 2 supports D0 D3 current D0 found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0x81 bus=3D0, slot=3D30, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x8080, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24cc, revid=3D0x01 bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x010f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[20]: type 4, range 32, base 0000bfa0, size 4, enabled found-> vendor=3D0x8086, dev=3D0x24ca, revid=3D0x01 bus=3D0, slot=3D31, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 map[10]: type 4, range 32, base 0000b800, size 8, enabled map[14]: type 4, range 32, base 0000bc40, size 6, enabled map[18]: type 1, range 32, base f4fff800, size 9, enabled map[1c]: type 1, range 32, base f4fff400, size 8, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LNKB:0) pci_link1: Picked IRQ 9 with weight 0 pcib0: slot 31 INTB routed to irq 9 via \\_SB_.PCI0.LNKB found-> vendor=3D0x8086, dev=3D0x24c5, revid=3D0x01 bus=3D0, slot=3D31, func=3D5 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000b400, size 8, enabled map[14]: type 4, range 32, base 0000b080, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LNKB:0) pcib0: slot 31 INTB routed to irq 9 via \\_SB_.PCI0.LNKB found-> vendor=3D0x8086, dev=3D0x24c6, revid=3D0x01 bus=3D0, slot=3D31, func=3D6 class=3D07-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D3 current D0 agp0: mem 0xe0000000-0xe7ffffff at device = 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 128M 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 0xd0000000-0xdfffffff pci1: on pcib1 pci1: physical bus=3D1 map[10]: type 1, range 32, base fc000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xfc000000-0xfcffffff map[14]: type 3, range 32, base d0000000, size 28, enabled pcib1: device (null) requested decoded memory range 0xd0000000-0xdfffffff pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKA found-> vendor=3D0x10de, dev=3D0x0324, revid=3D0xa1 bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0027, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x05 (1250 ns), maxlat=3D0x01 (250 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 nvidia0: mem 0xd0000000-0xdfffffff,0xfc000000-0xfcfffff= f irq 11 at device 0.0 on pci1 nvidia0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xfc000000 nvidia0: Reserved 0x10000000 bytes for rid 0x14 type 3 at 0xd0000000 nvidia0: [GIANT-LOCKED] uhci0: port 0xbf80-0xbf9f irq 1= 1 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf80 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 0xbf40-0xbf5f irq 1= 1 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf40 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 ums0: Logitech USB-PS/2 Trackball, rev 1.00/2.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci2: port 0xbf20-0xbf3f irq 1= 1 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf20 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 ehci0: mem 0xf4fffc00-0xf4ffffff irq 11= at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf4fffc00 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: single transaction translator uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xefff pcib2: memory decode 0xf6000000-0xfbffffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: physical bus=3D2 map[10]: type 1, range 32, base faffe000, size 13, enabled pcib2: device (null) requested decoded memory range 0xfaffe000-0xfaffffff pcib2: matched entry for 2.0.INTA (src \\_SB_.PCI0.LNKC:0) pcib2: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKC found-> vendor=3D0x14e4, dev=3D0x4401, revid=3D0x01 bus=3D2, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=3D0x104c, dev=3D0xac44, revid=3D0x02 bus=3D2, slot=3D1, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x07 (1750 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base faffd800, size 11, enabled pcib2: device (null) requested decoded memory range 0xfaffd800-0xfaffdfff map[14]: type 1, range 32, base faff8000, size 14, enabled pcib2: device (null) requested decoded memory range 0xfaff8000-0xfaffbfff pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKD found-> vendor=3D0x104c, dev=3D0x8029, revid=3D0x00 bus=3D2, slot=3D1, func=3D1 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0116, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 (1000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base faffc000, size 12, enabled pcib2: device (null) requested decoded memory range 0xfaffc000-0xfaffcfff pcib2: matched entry for 2.3.INTA (src \\_SB_.PCI0.LNKB:0) pcib2: slot 3 INTA routed to irq 9 via \\_SB_.PCI0.LNKB found-> vendor=3D0x8086, dev=3D0x1043, revid=3D0x04 bus=3D2, slot=3D3, func=3D0 class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0116, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x22 (8500 ns) intpin=3Da, irq=3D9 powerspec 2 supports D0 D3 current D0 bfe0: mem 0xfaffe000-0xfaffffff irq 11 at = device 0.0 on pci2 bfe0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xfaffe000 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: bpf attached bfe0: Ethernet address: 00:0d:56:b3:99:6e bfe0: [MPSAFE] cbb0: at device 1.0 on pci2 pcib2: device cbb0 requested decoded memory range 0xf6000000-0xfbffffff cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf6000000 cbb0: Found memory at f6000000 cbb0: Secondary bus is 0 cbb0: Setting primary bus to 2 cbb0: Secondary bus set to 3 subbus 4 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKD cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac44104c 0x02100007 0x06070002 0x00822008=20 0x10: 0xf6000000 0x020000a0 0x20040302 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b=20 0x40: 0x016a1028 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x28405061 0x00000000 0x001f0000 0x012c1202=20 0x90: 0x606482c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 fwohci0: vendor=3D104c, dev=3D8029 fwohci0: <1394 Open Host Controller Interface> mem 0xfaff8000-0xfaffbfff,0x= faffd800-0xfaffdfff irq 11 at device 1.1 on pci2 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfaffd800 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 43:4f:c0:00:08:17:a4:38 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 43:4f:c0:00:08:17:a4:38 @ 0xfffe00000000, S400, ma= xrec 2048 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 42:4f:c0:17:a4:38 fwe0: bpf attached fwe0: Ethernet address: 42:4f:c0:17:a4:38 fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) pci2: at device 3.0 (no driver attached) pci2:3:0: Transition from D0 to D3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x1= 77,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 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=3D03 ostat0=3D50 ostat1=3D00 ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0-slave: stat=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 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=3D03 ostat0=3D50 ostat1=3D00 ata1-master: stat=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1-slave: stat=3D0x00 err=3D0x04 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x4 ata1: [MPSAFE] pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff40= 0-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 9 at device 31.5 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xb800 pcm0: Reserved 0x40 bytes for rid 0x14 type 4 at 0xbc40 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features headphone, 20 bit DAC, 20 bit ADC, 5 bit master volume= , SigmaTel 3D Enhancement pcm0: Primary codec extended features variable rate PCM, reserved 1, AMAP, = reserved 4 pcm0: sndbuf_setmap 1f1fe000, 4000; 0xdd5ee000 -> 1f1fe000 pcm0: sndbuf_setmap 1f1fa000, 4000; 0xdd5f2000 -> 1f1fa000 pci0: at device 31.6 (no driver attached) pci0:31:6: Transition from D0 to D3 pci_link5: on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 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 9 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 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:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: flags 0x2000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00002000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0xa01 0xa11 0xa01 0xa01 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77b,0x378-0x37f 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 sio1: irq maps: 0xa01 0xa09 0xa01 0xa01 sio1 port 0x280-0x287,0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A npx0: [FAST] npx0: on motherboard npx0: INT 16 interface ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it vga: vga0 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 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xcf800-0xcffff,0xc0000-0xcf7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff 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 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Timecounter "TSC" frequency 1398819595 Hz quality 800 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_cmbat0: battery initialization done, tried 1 times acpi_cmbat1: battery initialization start cpu0: Performance states changed Status is 0x30000006 ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: setting PIO4 on Intel ICH4 chip ata0-master: setting UDMA100 on Intel ICH4 chip ad0: ATA-6 disk at ata0-master ad0: 57231MB (117210240 sectors), 116280 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 (probe0:ata0:0:0:0): error 22 (probe0:ata0:0:0:0): Unretryable Error (probe1:ata0:0:1:0): error 22 (probe1:ata0:0:1:0): Unretryable Error GEOM: new disk ad0 ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x42 cable=3D40pin ata1-master: setting PIO4 on Intel ICH4 chip ata1-master: setting UDMA33 on Intel ICH4 chip acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 2755KB/s (2755KB/s), 2048KB buffer, UD= MA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 48013 Hz, will use 48000 Hz (probe1:ata1:0:1:0): error 22 (probe1:ata1:0:1:0): Unretryable Error (probe9:ata0:0:0:0): error 22 (probe9:ata0:0:0:0): Unretryable Error (probe10:ata0:0:1:0): error 22 (probe10:ata0:0:1:0): Unretryable Error (probe1:ata1:0:1:0): error 22 (probe1:ata1:0:1:0): Unretryable Error (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error ums0: at uhub1 port 1 (addr 2) disconnected ums0: detached (probe2:sbp0:0:0:0): error 22 (probe2:sbp0:0:0:0): Unretryable Error (probe3:sbp0:0:1:0): error 22 (probe3:sbp0:0:1:0): Unretryable Error (probe5:sbp0:0:3:0): error 22 (probe5:sbp0:0:3:0): Unretryable Error (probe7:sbp0:0:5:0): error 22 (probe7:sbp0:0:5:0): Unretryable Error (probe4:sbp0:0:2:0): error 22 (probe4:sbp0:0:2:0): Unretryable Error (probe6:sbp0:0:4:0): error 22 (probe6:sbp0:0:4:0): Unretryable Error (probe8:sbp0:0:6:0): error 22 (probe8:sbp0:0:6:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: <_NEC DVD_RW ND-5500A 1.51> Removable CD-ROM SCSI-0 device=20 pass0: Serial Number [ pass0: 33.000MB/s transfers GEOM: new disk cd0 (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: <_NEC DVD_RW ND-5500A 1.51> Removable CD-ROM SCSI-0 device=20 cd0: Serial Number [ cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error kern_symlink =3D 0 Trying to mount root from ufs:/dev/ad0s3a kernel_vmount =3D 0 start_init: trying /sbin/init ums0: Logitech USB-PS/2 Trackball, rev 1.00/2.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted procfs registered linprocfs registered Status is 0x30000820 cbb0: card inserted: event=3D0x00000000, state=3D30000820 cbb0: cbb_power: 3V pcib2: device cardbus0 requested decoded memory range 0xf6000000-0xfbffffff cardbus0: Expecting link target, got 0x8 cardbus0: Resource not specified in CIS: id=3D10, size=3D2000 cardbus0: Resource not specified in CIS: id=3D14, size=3D20000 pcib2: device cardbus0 requested decoded memory range 0xf6000000-0xfbffffff found-> vendor=3D0x104c, dev=3D0x9066, revid=3D0x00 bus=3D3, slot=3D0, func=3D0 class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 cardbus0: at device 0.0 (no driver attached) pci3:0:0: Transition from D0 to D3 cbb0: cbb_power: 0V cbb0: CardBus card activation failed --Boundary-01=_g/mxBSTgWaCSo8L-- --nextPart1488347.b9YHmtegtK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBxm/u5ZPcIHs/zowRAqLUAJ9lNt3RTVK3NZZ0HMqDq3EQNLV62gCgk87+ ZOWuQcW0z6uvOxMWXTxz79c= =+2Jf -----END PGP SIGNATURE----- --nextPart1488347.b9YHmtegtK-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 07:02:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DAC216A4CE for ; Mon, 20 Dec 2004 07:02:53 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC84443D41 for ; Mon, 20 Dec 2004 07:02:52 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so97966rnz for ; Sun, 19 Dec 2004 23:02:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=prvs7E6ka3IlvulJRqs9GInv9Z7G3FDIF7mg9z+7ewQ8PF+N8VsZh5nH5cVuxc1ZhL/76lJm8BXUI+sH27n9cVMnErY8xtQ0XcPkN8aFHom844bUWRVjS/YuAI06LDgrpCqi+HMo+8GBN4/aZYBqTxRAQzt0L1MIc3SPIdWdIBI= Received: by 10.38.25.1 with SMTP id 1mr351946rny; Sun, 19 Dec 2004 23:02:52 -0800 (PST) Received: by 10.38.8.31 with HTTP; Sun, 19 Dec 2004 23:02:52 -0800 (PST) Message-ID: Date: Mon, 20 Dec 2004 15:02:52 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org In-Reply-To: <20041220053619.GO36954@squash.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041220053619.GO36954@squash.dsto.defence.gov.au> Subject: Re: [buildworld failure] "/usr/src/Makefile.inc1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2004 07:02:53 -0000 On Mon, 20 Dec 2004 16:06:19 +1030, Wilkinson, Alex wrote: > My CPUTYPE is set to I686_CPU > > - aW Which is not a correct value. Please refer to /usr/share/examples/etc/make.conf for correct values. Cheers, -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 07:12:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C34E16A4CE for ; Mon, 20 Dec 2004 07:12:01 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A7143D2F for ; Mon, 20 Dec 2004 07:12:00 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iBK7Av6j014278 for ; Mon, 20 Dec 2004 17:40:57 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Mon, 20 Dec 2004 17:41:53 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iBK768Q32532 for ; Mon, 20 Dec 2004 17:36:08 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK369VQ3; Mon, 20 Dec 2004 17:35:53 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iBK7706G039045 for ; Mon, 20 Dec 2004 17:37:00 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iBK770u1039044 for freebsd-current@freebsd.org; Mon, 20 Dec 2004 17:37:00 +1030 (CST) (envelope-from wilkinsa) Date: Mon, 20 Dec 2004 17:37:00 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20041220070659.GY36954@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20041220053619.GO36954@squash.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Subject: Re: [buildworld failure] "/usr/src/Makefile.inc1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 07:12:01 -0000 0n Mon, Dec 20, 2004 at 03:02:52PM +0800, Jiawei Ye wrote: >On Mon, 20 Dec 2004 16:06:19 +1030, Wilkinson, Alex > wrote: >> My CPUTYPE is set to I686_CPU >> >> - aW >Which is not a correct value. Please refer to >/usr/share/examples/etc/make.conf for correct values. Sorry, I should have said that I have CPUTYPE=p4 defined in /etc/make.conf. - aW From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 07:15:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DAE816A4CE for ; Mon, 20 Dec 2004 07:15:01 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46A5743D31 for ; Mon, 20 Dec 2004 07:15:01 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so98194rnz for ; Sun, 19 Dec 2004 23:15:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=JzwCHGvPy7b0sh3r6gFDSud2AYsatCyYfp4E1LqgMwdw8F+OGca2AWowMbQG3PKC9Is3Y1jFwi12O4/y59oG4tlAytfnTCxMwKL7+LilAtY+zPsCkKnijicEtBEcrfdsh4o5RxA35ONzCwqUOeeA7NZIk2u8ealbg4CaNgEYl9Y= Received: by 10.38.25.1 with SMTP id 1mr353982rny; Sun, 19 Dec 2004 23:15:00 -0800 (PST) Received: by 10.38.8.31 with HTTP; Sun, 19 Dec 2004 23:15:00 -0800 (PST) Message-ID: Date: Mon, 20 Dec 2004 15:15:00 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org In-Reply-To: <20041220070659.GY36954@squash.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041220053619.GO36954@squash.dsto.defence.gov.au> <20041220070659.GY36954@squash.dsto.defence.gov.au> Subject: Re: [buildworld failure] "/usr/src/Makefile.inc1" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2004 07:15:01 -0000 On Mon, 20 Dec 2004 17:37:00 +1030, Wilkinson, Alex wrote: > 0n Mon, Dec 20, 2004 at 03:02:52PM +0800, Jiawei Ye wrote: > > Sorry, I should have said that I have CPUTYPE=p4 defined in > /etc/make.conf. > > - aW What about changing it to CPUTYPE?=p4 ? -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 07:26:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8827E16A4CE for ; Mon, 20 Dec 2004 07:26:04 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 564C443D48 for ; Mon, 20 Dec 2004 07:26:04 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id EFDA4F211A; Sun, 19 Dec 2004 23:26:01 -0800 (PST) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07616-02; Sun, 19 Dec 2004 23:26:01 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id D11A3F20FD; Sun, 19 Dec 2004 23:26:00 -0800 (PST) From: Sean McNeil To: Andre Guibert de Bruet In-Reply-To: <20041219194045.S99984@alpha.siliconlandmark.com> References: <1103434515.1158.10.camel@server.mcneil.com> <20041219150157.O19917@alpha.siliconlandmark.com> <1103489622.5226.6.camel@server.mcneil.com> <20041219194045.S99984@alpha.siliconlandmark.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4oFkvO7xwSMSo6gIh5wG" Date: Sun, 19 Dec 2004 23:26:00 -0800 Message-Id: <1103527560.7749.1.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at mcneil.com cc: current@freebsd.org Subject: Re: reboot without any info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 07:26:04 -0000 --=-4oFkvO7xwSMSo6gIh5wG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-12-19 at 20:34 -0500, Andre Guibert de Bruet wrote: > On Sun, 19 Dec 2004, Sean McNeil wrote: > > On Sun, 2004-12-19 at 15:17 -0500, Andre Guibert de Bruet wrote: > >> On Sat, 18 Dec 2004, Sean McNeil wrote: > >> > >>> This happens with a world/kernel and a portupgrade -frR totem built > >>> Today: > >>> > >>> From rom a user account, I did a gdb `which totem` and then an r. Th= is > >>> caused a reboot. >=20 > [snip] >=20 > > I think everyone has hardware fault on the brain right now. Please not= e > > that the system works perfectly - even under extreme load - until the > > moment I run totem in the debugger. Then it is instant. I would never > > consider this behavior as hardware related. >=20 > I would suggest hooking up a serial or firewire console on this machine=20 > and logging any output. If nothing relevant turns up, you may wish to try= =20 > and reproduce the problem while running gdb under strace or truss (I am=20 > not familiar with the status of these programs under AMD64. YMMV) while=20 > logged at a serial console. Yes, I agree this is the best approach. Does anyone have a dconschat that works under MacOSX, Linux, or Windows? --=-4oFkvO7xwSMSo6gIh5wG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBxn6IyQsGN30uGE4RAuxTAJkBVgMGvKtHhp+/JMWZDyrd2VdVGACfZSQu /0wjXwRUi9z/tiwPv0r6UpY= =ZdZP -----END PGP SIGNATURE----- --=-4oFkvO7xwSMSo6gIh5wG-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 08:46:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ED9916A4CE for ; Mon, 20 Dec 2004 08:46:39 +0000 (GMT) Received: from wasley.bl.mmtr.or.jp (wasley.bl.mmtr.or.jp [210.228.173.142]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D1F243D1F for ; Mon, 20 Dec 2004 08:46:38 +0000 (GMT) (envelope-from rushani@bl.mmtr.or.jp) Received: (qmail 24675 invoked from network); 20 Dec 2004 17:46:31 +0900 Received: from unknown (HELO localhost) (210.165.212.57) by wasley.bl.mmtr.or.jp with SMTP; 20 Dec 2004 17:46:31 +0900 Date: Mon, 20 Dec 2004 17:46:08 +0900 (JST) Message-Id: <20041220.174608.63062245.rushani@bl.mmtr.or.jp> To: gbergling@0xfce3.net From: Hideyuki KURASHINA In-Reply-To: <20041218141228.GA65853@spot.0xfce3.net> References: <20041218141228.GA65853@spot.0xfce3.net> X-URL: http://www.rushani.jp/ X-PGP-Public-Key: http://www.rushani.jp/rushani.asc X-PGP-Fingerprint: A052 6F98 6146 6FE3 91E2 DA6B F2FA 2088 439A DC57 X-RC5-72-Stats: http://stats.distributed.net/participant/psummary.php?project_id=8&id=432320 X-Mailer: Mew version 4.1.52 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: imp@bsdimp.com Subject: Re: [PATCH] add missing device id for pccard bridge O2Micro OZ711M1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 08:46:39 -0000 Hi, >>> On Sat, 18 Dec 2004 15:12:28 +0100, Gordon Bergling said: > Hi folks, > > only a cosmetic change. ;) > > The following patches add the device id for the O2Micro OZ711M1 pccard > bridge. The manual page will be updated with the second patch. > > This patches were tested with on HEAD. > > http://www.0xfce3.net/media/20041218-pccbb.patch > http://www.0xfce3.net/media/20041218-man.patch Per reading /usr/src/share/misc/pci_vendors, your patch looks fine. I suggest you sending a PR so that our PCI-CardBus Bridge maintainer can track your change. Thanks, -- rushani From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 09:39:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC4816A4CE for ; Mon, 20 Dec 2004 09:39:24 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E07843D4C for ; Mon, 20 Dec 2004 09:39:23 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) iBK9dJiP006611 for ; Mon, 20 Dec 2004 04:39:19 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)iBK9dJSI006608 for ; Mon, 20 Dec 2004 04:39:19 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Mon, 20 Dec 2004 04:39:19 -0500 (EST) From: Andre Guibert de Bruet To: current@freebsd.org Message-ID: <20041220042053.N99984@alpha.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Subject: iir(4) control device permissions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 09:39:24 -0000 Hi, The iir(4) device driver creates its control device entry with a permissions mask of 644 (root:operator). The standard permissions mask for SCSI/RAID control device node entries seems to be 600 (root:operator). Could the following patch be committed? http://bling.properkernel.com/freebsd/iir_ctrl.c.perm.patch Regards, | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 11:04:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F4A316A4D1 for ; Mon, 20 Dec 2004 11:04:16 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id DEE6143D4C for ; Mon, 20 Dec 2004 11:04:14 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 34830 invoked from network); 20 Dec 2004 11:04:13 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 20 Dec 2004 11:04:13 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBKB4C0N087806; Mon, 20 Dec 2004 12:04:12 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBKB4Coo087805; Mon, 20 Dec 2004 12:04:12 +0100 (CET) (envelope-from pho) Date: Mon, 20 Dec 2004 12:04:11 +0100 From: Peter Holm To: John Baldwin Message-ID: <20041220110411.GA87750@peter.osted.lan> References: <20041112123343.GA12048@peter.osted.lan> <200411191710.19215.jhb@FreeBSD.org> <20041206135934.GA24238@peter.osted.lan> <200412161521.44026.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412161521.44026.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: bmilekic@FreeBSD.org cc: jeffr@FreeBSD.org cc: jroberson@chesapeake.net Subject: Re: Freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 11:04:16 -0000 On Thu, Dec 16, 2004 at 03:21:44PM -0500, John Baldwin wrote: > On Monday 06 December 2004 08:59 am, Peter Holm wrote: > > On Fri, Nov 19, 2004 at 05:10:19PM -0500, John Baldwin wrote: > > > On Friday 19 November 2004 02:59 am, Peter Holm wrote: > > > > On Mon, Nov 15, 2004 at 03:46:15PM -0500, John Baldwin wrote: > > > > > On Friday 12 November 2004 07:33 am, Peter Holm wrote: > > > > > > GENERIC HEAD from Nov 11 08:05 UTC > > > > > > > > > > > > The following stack traces etc. was done before my first > > > > > > cup of coffee, so it's not so informative as it could have been :-( > > > > > > > > > > > > The test box appeared to have been frozen for more than 6 hours, > > > > > > but was pingable. > > > > > > > > > > > > http://www.holm.cc/stress/log/cons86.html > > > > > > > > > > A weak guess is that you have the system in some sort of livelock due > > > > > to fork()? Have you tried running with 'debug.mpsafevm=1' set from > > > > > the loader? > > > > > > > > > > -- > > > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > > > > > OK, I've got some more info: > > > > > > > > http://www.holm.cc/stress/log/cons88.html > > > > > > > > Looks like a spin in uma_zone_slab() when slab_zalloc() fails? > > > > > > Yes, I think if you specify M_WAITOK, then that might happen. > > > slab_zalloc() can fail if any of the init functions fail for example, in > > > which case it would loop forever. You can try this hack (though it may > > > very well be wrong) to return failure if that is what is triggering: > > > > > > Index: uma_core.c > > > =================================================================== > > > RCS file: /usr/cvs/src/sys/vm/uma_core.c,v > > > retrieving revision 1.110 > > > diff -u -r1.110 uma_core.c > > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > > +++ uma_core.c 19 Nov 2004 22:08:26 -0000 > > > @@ -1998,6 +1998,10 @@ > > > */ > > > if (flags & M_NOWAIT) > > > flags |= M_NOVM; > > > + > > > + /* XXXHACK */ > > > + if (flags & M_WAITOK) > > > + break; > > > } > > > return (slab); > > > } > > > > > > -- > > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > > > > I instrumented the code with this: > > $ cvs diff -u > > cvs diff: Diffing . > > Index: uma_core.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > > retrieving revision 1.110 > > diff -u -r1.110 uma_core.c > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > +++ uma_core.c 6 Dec 2004 13:49:36 -0000 > > @@ -1926,6 +1926,7 @@ > > { > > uma_slab_t slab; > > uma_keg_t keg; > > + int i; > > > > keg = zone->uz_keg; > > > > @@ -1943,7 +1944,8 @@ > > > > slab = NULL; > > > > - for (;;) { > > + for (i = 0;;i++) { > > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > > /* > > * Find a slab with some space. Prefer slabs that are > > partially * used over those that are totally full. This helps to reduce > > > > and now during test of Jeff Roberson's "SMP FFS" patch the assert > > triggered: http://www.holm.cc/stress/log/cons92.html > > Hmm. Does the hack patch above make the hang go away or does it just break > things worse? > I have been testing your patch for quite a while. If it's OK for m_getcl with M_TRYWAIT to return NULL, your patch reviled a missing test for NULL in kern/uipc_socket.c:750 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc0647d77 stack pointer = 0x10:0xcfa9cbf0 frame pointer = 0x10:0xcfa9cc38 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 = 67417 (net) [thread pid 67417 tid 100890 ] Stopped at sosend+0x227: movl $0,0x1c(%eax) db> where Tracing pid 67417 tid 100890 td 0xc1ae8000 sosend(c3454dec,0,cfa9cc90,0,0) at sosend+0x227 soo_write(c1db9374,cfa9cc90,c1aa6180,0,c1ae8000) at soo_write+0x2d dofilewrite(3,bfbfe740,400,ffffffff,ffffffff) at dofilewrite+0x99 write(c1ae8000,cfa9cd14,3,d,246) at write+0x48 syscall(2f,bfbf002f,bfbf002f,3,bfbfe740) at syscall+0x128 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0x280bfbf7, esp = 0xbfbfe71c, ebp = 0xbfbfeb68 --- -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 12:25:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A98416A4CE; Mon, 20 Dec 2004 12:25:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D7B43D49; Mon, 20 Dec 2004 12: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 9094D1FF9A8; Mon, 20 Dec 2004 13:25:07 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 8D2BB1FF90C; Mon, 20 Dec 2004 13:25:05 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id DFA8F1575A; Mon, 20 Dec 2004 12:23:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id D3F22156BB; Mon, 20 Dec 2004 12:23:39 +0000 (UTC) Date: Mon, 20 Dec 2004 12:23:39 +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=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD net mailing list Subject: Re: mem leak in mii ? (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 12:25:10 -0000 Hi, haven't had any feedback on this.... Can someone please review? Also answers to the questions would be welcome. Thanks. ---------- Forwarded message ---------- Date: Tue, 23 Nov 2004 19:31:10 +0000 (UTC) From: Bjoern A. Zeeb To: John Baldwin Cc: Bjoern A. Zeeb , freebsd-current@FreeBSD.org Subject: Re: mem leak in mii ? On Mon, 22 Nov 2004, John Baldwin wrote: Hi, hope you won't get it twice; the first one didn't seem to go out... > On Friday 19 November 2004 06:49 pm, Bjoern A. Zeeb wrote: > > Hi, > > > > in sys/dev/mii/mii.c there are two calls to malloc for ivars; > > see for example mii_phy_probe: .. > > Where is the free for this malloc ? I cannot find it. > > > > analogous: miibus_probe ? > > It's a leak. It should be free'd when the miibus device is destroyed. Here's > a possible fix: could you please review this one ? Should plug both of the memleaks; also for more error cases. notes: * mii doesn't ssem to be very error corrective and reporting; as others currently also seem to be debugging problems with undetectable PHYs I added some error handling in those places that I touched anyway. * in miibus_probe in the loop there is the possibility - and the comment above the functions also talks about this - that we find more than one PHY ? I currrently doubt that but I don't know for sure. As device_add_child may return NULL we cannot check for that; I had seen some inconsistency while debugging the BMSR_MEDIAMASK check so I added the count variable for this to have a reliable state. * all PHY drivers currently seem to use mii_phy_detach for device_detach. If any implements his own function it will be responsible for freeing the ivars allocated in miibus_probe. This should perhaps be documented somewhere ? patch can also be found at http://sources.zabbadoz.net/freebsd/patchset/mii-memleaks.diff Index: mii.c =================================================================== RCS file: /local/mirror/FreeBSD/r/ncvs/src/sys/dev/mii/mii.c,v retrieving revision 1.20 diff -u -p -r1.20 mii.c --- mii.c 15 Aug 2004 06:24:40 -0000 1.20 +++ mii.c 23 Nov 2004 17:08:58 -0000 @@ -111,7 +111,7 @@ miibus_probe(dev) struct mii_attach_args ma, *args; struct mii_data *mii; device_t child = NULL, parent; - int bmsr, capmask = 0xFFFFFFFF; + int count = 0, bmsr, capmask = 0xFFFFFFFF; mii = device_get_softc(dev); parent = device_get_parent(dev); @@ -145,12 +145,26 @@ miibus_probe(dev) args = malloc(sizeof(struct mii_attach_args), M_DEVBUF, M_NOWAIT); + if (args == NULL) { + device_printf(dev, "%s: memory allocation failure, " + "phyno %d", __func__, ma.mii_phyno); + continue; + } bcopy((char *)&ma, (char *)args, sizeof(ma)); child = device_add_child(dev, NULL, -1); + if (child == NULL) { + free(args, M_DEVBUF); + device_printf(dev, "%s: device_add_child failed", + __func__); + continue; + } device_set_ivars(child, args); + count++; + /* XXX should we break here or is it really possible + * to find more then one PHY ? */ } - if (child == NULL) + if (count == 0) return(ENXIO); device_set_desc(dev, "MII bus"); @@ -173,12 +187,15 @@ miibus_attach(dev) */ mii->mii_ifp = device_get_softc(device_get_parent(dev)); v = device_get_ivars(dev); + if (v == NULL) + return (ENXIO); ifmedia_upd = v[0]; ifmedia_sts = v[1]; + device_set_ivars(dev, NULL); + free(v, M_DEVBUF); ifmedia_init(&mii->mii_media, IFM_IMASK, ifmedia_upd, ifmedia_sts); - bus_generic_attach(dev); - return(0); + return (bus_generic_attach(dev)); } int @@ -186,8 +203,14 @@ miibus_detach(dev) device_t dev; { struct mii_data *mii; + void *v; bus_generic_detach(dev); + v = device_get_ivars(dev); + if (v != NULL) { + device_set_ivars(dev, NULL); + free(v, M_DEVBUF); + } mii = device_get_softc(dev); ifmedia_removeall(&mii->mii_media); mii->mii_ifp = NULL; @@ -305,12 +328,15 @@ mii_phy_probe(dev, child, ifmedia_upd, i int bmsr, i; v = malloc(sizeof(vm_offset_t) * 2, M_DEVBUF, M_NOWAIT); - if (v == 0) { + if (v == NULL) return (ENOMEM); - } v[0] = ifmedia_upd; v[1] = ifmedia_sts; *child = device_add_child(dev, "miibus", -1); + if (*child == NULL) { + free(v, M_DEVBUF); + return (ENXIO); + } device_set_ivars(*child, v); for (i = 0; i < MII_NPHY; i++) { @@ -324,14 +350,22 @@ mii_phy_probe(dev, child, ifmedia_upd, i } if (i == MII_NPHY) { + device_set_ivars(dev, NULL); + free(v, M_DEVBUF); device_delete_child(dev, *child); *child = NULL; return(ENXIO); } - bus_generic_attach(dev); + i = bus_generic_attach(dev); - return(0); + v = device_get_ivars(*child); + if (v != NULL) { + device_set_ivars(*child, NULL); + free(v, M_DEVBUF); + } + + return (i); } /* Index: mii_physubr.c =================================================================== RCS file: /local/mirror/FreeBSD/r/ncvs/src/sys/dev/mii/mii_physubr.c,v retrieving revision 1.21 diff -u -p -r1.21 mii_physubr.c --- mii_physubr.c 29 May 2004 18:09:10 -0000 1.21 +++ mii_physubr.c 23 Nov 2004 17:07:30 -0000 @@ -522,7 +522,13 @@ int mii_phy_detach(device_t dev) { struct mii_softc *sc; + void *args; + args = device_get_ivars(dev); + if (args != NULL) { + device_set_ivars(dev, NULL); + free(args, M_DEVBUF); + } sc = device_get_softc(dev); mii_phy_down(sc); sc->mii_dev = NULL; -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 06:59:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAB5E16A4CF for ; Mon, 20 Dec 2004 06:59:22 +0000 (GMT) Received: from web40702.mail.yahoo.com (web40702.mail.yahoo.com [66.218.78.159]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A21F43D54 for ; Mon, 20 Dec 2004 06:59:22 +0000 (GMT) (envelope-from darren780@yahoo.com) Received: (qmail 35074 invoked by uid 60001); 20 Dec 2004 06:59:22 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=EJrwMEx9ShnZJCS0j9z+zpI6wLO+KfWA2lD5HOWALR663PK/ml4+T24dq9GMLUZE98PWI5AoQLkT+iTbF8bOyZj+qc2dBJMy7bf/hlqO9okPeRnNpEftZugMC5VRpNkGcBiIgk3X+zZmvQcYVIQTDv+vn7eT7rhZA6Lfmd5iYgs= ; Message-ID: <20041220065922.35072.qmail@web40702.mail.yahoo.com> Received: from [199.126.133.199] by web40702.mail.yahoo.com via HTTP; Sun, 19 Dec 2004 22:59:22 PST Date: Sun, 19 Dec 2004 22:59:22 -0800 (PST) From: "Mr. Darren" To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 20 Dec 2004 12:54:06 +0000 Subject: pci dma error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 06:59:22 -0000 I have a diamond mx400 and I get the following error Maestro: DMA buffer beyond 256MB (busaddr 0x1ed50000 size 81920) Couldn't allocate Maestro memory I am informed on some linux sites that this problem is related to having more than 250megs of ram. they claimed the problem was fixed by manually setting a dma.. I'm not sure how to do this in freebsd. ps. please get back to me off the list as well, I am not currently subscribed. __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 14:29:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03DE516A4CE for ; Mon, 20 Dec 2004 14:29:11 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F59F43D5C for ; Mon, 20 Dec 2004 14:29:11 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id AE745D13F; Mon, 20 Dec 2004 09:29:10 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id E647D62B5; Mon, 20 Dec 2004 09:29:04 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16838.57775.192107.913226@canoe.dclg.ca> Date: Mon, 20 Dec 2004 09:29:03 -0500 To: freebsd-current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid Subject: sio hanging again. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 14:29:12 -0000 I have a current from yesterday evening and my serial (sio ... regular, builtin 16550A) hangs the machine when I use it. In particular, I'm running pilot-xfer. I believe that I use 115200 as my speed. The machine hangs hard with no messages on the console and no response anywhere. Another odd (possibly unreated) thing is that "tail -f" on a log file is exiting. I don't have a rule for it, but in my case it's reproducable where: process A is >& to the log file. A then spawns several 'B' processes using popen(). A loops to read output from all B using kqueue() and reports much of this to the logfile. When B's exit, tail -f on A's output exits. Odd. Now I just noticed that my tail -f log on a running "make -j4 buildworld >& log" exited as well. Double-odd. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 15:36:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C916916A4CE for ; Mon, 20 Dec 2004 15:36:49 +0000 (GMT) Received: from conversation.bsdunix.ch (genox.ch [82.220.17.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B77ED43D1D for ; Mon, 20 Dec 2004 15:36:48 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) (authenticated bits=0)iBKFXbCn077764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Dec 2004 16:33:37 +0100 (CET) (envelope-from freebsdlists@bsdunix.ch) Date: Mon, 20 Dec 2004 16:33:37 +0100 (CET) From: Thomas Vogt X-X-Sender: turbo@conversation.bsdunix.ch To: freebsd-current@freebsd.org Message-ID: <20041220163250.L77759@conversation.bsdunix.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, SARE_FROM_SPAM_WORD3 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on conversation.bsdunix.ch Subject: Support for Adaptec 21610SA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 15:36:50 -0000 Hi Is Adaptec 21610SA controller (16 port sata wiht raid) supported in 5.3/5-stable or -current? I didn't find any information in the hardware relase note. regards Thomas Vogt From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 16:31:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2F6816A4CE for ; Mon, 20 Dec 2004 16:31:54 +0000 (GMT) Received: from moya.lambermont.dyndns.org (j226018.upc-j.chello.nl [24.132.226.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9416C43D2F for ; Mon, 20 Dec 2004 16:31:54 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: from localhost (localhost [127.0.0.1]) by moya.lambermont.dyndns.org (Postfix) with ESMTP id 0B71C36402; Mon, 20 Dec 2004 17:31:53 +0100 (CET) Received: from moya.lambermont.dyndns.org ([127.0.0.1])port 10024) with ESMTP id 73118-08; Mon, 20 Dec 2004 17:31:52 +0100 (CET) Received: by moya.lambermont.dyndns.org (Postfix, from userid 1001) id 9A84636401; Mon, 20 Dec 2004 17:31:52 +0100 (CET) Date: Mon, 20 Dec 2004 17:31:52 +0100 To: David Gilbert Message-ID: <20041220163152.GH45927@moya.lambermont.dyndns.org> References: <16838.57775.192107.913226@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16838.57775.192107.913226@canoe.dclg.ca> User-Agent: Mutt/1.4.2.1i From: hans@lambermont.dyndns.org (Hans Lambermont) X-Virus-Scanned: by amavisd-new-20030616.p5 at lambermont.dyndns.org cc: freebsd-current@freebsd.org Subject: Re: sio hanging again. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 16:31:55 -0000 David Gilbert wrote: > I have a current from yesterday evening and my serial (sio > ... regular, builtin 16550A) hangs the machine when I use it. In > particular, I'm running pilot-xfer. I believe that I use 115200 as my > speed. The machine hangs hard with no messages on the console and no > response anywhere. I reported the same behaviour on Dec 1, see http://docs.freebsd.org/cgi/mid.cgi?20041201112503.GA23154 No answers yet. -- Hans From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 19:42:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62AEF16A4CF; Mon, 20 Dec 2004 19:42:18 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F1D43D2F; Mon, 20 Dec 2004 19:42:18 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id iBKJgHUA013512; Mon, 20 Dec 2004 11:42:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Dec 2004 11:42:17 -0800 Message-ID: <00CDF9AA240E204FA6E923BD35BC643607C47915@bcs-mail.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: build failure in usr.sbin Thread-Index: AcTmzAMGUJa3xt99SW+IqbxrXTJllg== From: "Li, Qing" To: , X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 Subject: build failure in usr.sbin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 19:42:18 -0000 -- Qing cc -O2 -fno-strict-aliasing -pipe -DUSE_INET6 -DIPL_NAME=3D\"/dev/ipl\" -DIPFILTER_LOG -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet=20 -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter -I/usr/src/usr.sbin/ipftest/../../contrib/ipfilter =20 -c /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c: In function `nat_log': /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: `rulen' undeclared (first use in this function) /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: (Each undeclared identifier is reported only once /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: for each function it appears in.) /usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet/ip_nat.c:29 04: error: `np' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/usr.sbin/ipftest. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 19:47:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE4416A4CE for ; Mon, 20 Dec 2004 19:47:46 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 6999843D5D for ; Mon, 20 Dec 2004 19:47:45 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 83923 invoked from network); 20 Dec 2004 19:47:43 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 20 Dec 2004 19:47:43 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBKJlhU4089634 for ; Mon, 20 Dec 2004 20:47:43 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBKJlhtC089633 for current@freebsd.org; Mon, 20 Dec 2004 20:47:43 +0100 (CET) (envelope-from pho) Date: Mon, 20 Dec 2004 20:47:42 +0100 From: Peter Holm To: current@freebsd.org Message-ID: <20041220194742.GA89598@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 19:47:46 -0000 During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) at netisr_processqueue+0xf swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at ithread_loop+0x19e fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e fork_trampoline() at fork_trampoline+0x8 http://www.holm.cc/stress/log/cons96.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 20:10:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F6E916A4CF for ; Mon, 20 Dec 2004 20:10:58 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AB7543D1D for ; Mon, 20 Dec 2004 20:10:57 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81675 invoked from network); 20 Dec 2004 19:58:41 -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 ; 20 Dec 2004 19:58:41 -0000 Message-ID: <41C73202.1050704@freebsd.org> Date: Mon, 20 Dec 2004 21:11:46 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Holm References: <20041220194742.GA89598@peter.osted.lan> In-Reply-To: <20041220194742.GA89598@peter.osted.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 20:10:58 -0000 Peter Holm wrote: > During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > at netisr_processqueue+0xf > swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > ithread_loop+0x19e > fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > fork_trampoline() at fork_trampoline+0x8 > > http://www.holm.cc/stress/log/cons96.html Interesting. Can you specify what kind of test was running at the time of panic? -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 20:19:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07B4E16A4CE; Mon, 20 Dec 2004 20:19:55 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAD1943D2D; Mon, 20 Dec 2004 20:19:54 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 767BB4A9D4; Mon, 20 Dec 2004 14:19:54 -0600 (CST) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 09618-01-8; Mon, 20 Dec 2004 14:19:54 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id 0F3B14A9C8; Mon, 20 Dec 2004 14:19:54 -0600 (CST) Date: Mon, 20 Dec 2004 14:19:53 -0600 From: Alan Cox To: Brian Fundakowski Feldman , rwatson@freebsd.org Message-ID: <20041220201953.GI1362@cs.rice.edu> References: <20041211224850.GV17820@cs.rice.edu> <20041214000620.GA94951@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <20041214000620.GA94951@green.homeunix.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: Alan Cox cc: current@freebsd.org Subject: Re: panic: sbflush_locked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 20:19:55 -0000 --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 13, 2004 at 07:06:20PM -0500, Brian Fundakowski Feldman wrote: > On Sat, Dec 11, 2004 at 04:48:50PM -0600, Alan Cox wrote: > > I just got the following panic for a second time in the last three days > > doing a "make -jN buildworld". This is a with a recent copy of HEAD. > > If anyone wants more detail, let me know. > > > > panic: sbflush_locked: cc 4 || mb 0xffffff0052afa400 || mbcnt 0 > > cpuid = 1 > > KDB: enter: panic > > [thread pid 12163 tid 100188 ] > > Stopped at kdb_enter+0x2f: nop > > db> trace > > Tracing pid 12163 tid 100188 td 0xffffff008d169500 > > kdb_enter() at kdb_enter+0x2f > > panic() at panic+0x291 > > sbflush_locked() at sbflush_locked+0x64 > > sbrelease_locked() at sbrelease_locked+0x1c > > sbrelease() at sbrelease+0x48 > > sorflush() at sorflush+0x15c > > sofree() at sofree+0x204 > > soclose() at soclose+0x3af > > fifo_cleanup() at fifo_cleanup+0x38 > > fifo_close() at fifo_close+0x79 > > ufsfifo_close() at ufsfifo_close+0x7d > > vn_close() at vn_close+0x8e > > vn_closefile() at vn_closefile+0x65 > > fdrop_locked() at fdrop_locked+0xc0 > > closef() at closef+0x39 > > close() at close+0x1a5 > > syscall() at syscall+0x51e > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (6, FreeBSD ELF64, close), rip = 0x41e2c0, rsp = 0x7fffffffded8, rbp = 0x57a540 --- > > I haven't seen this in a very long time, but I've definitely tried to > track it down before with zero luck. > With the attached change, I've had no more crashes. I speculate uipc_send() is missing needed synchronization on so_snd. Robert, can you verify the patch? Alan --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-uipc_usrreq.c" Index: kern/uipc_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.143 diff -u -r1.143 uipc_usrreq.c --- kern/uipc_usrreq.c 1 Dec 2004 09:22:26 -0000 1.143 +++ kern/uipc_usrreq.c 19 Dec 2004 03:22:50 -0000 @@ -452,7 +452,9 @@ } } + SOCKBUF_LOCK(&so->so_snd); if (so->so_snd.sb_state & SBS_CANTSENDMORE) { + SOCKBUF_UNLOCK(&so->so_snd); error = EPIPE; break; } @@ -478,6 +480,7 @@ (so2->so_rcv.sb_cc - unp->unp_conn->unp_cc); (void)chgsbsize(so->so_cred->cr_uidinfo, &so->so_snd.sb_hiwat, newhiwat, RLIM_INFINITY); + SOCKBUF_UNLOCK(&so->so_snd); unp->unp_conn->unp_cc = so2->so_rcv.sb_cc; sorwakeup_locked(so2); m = NULL; --Yylu36WmvOXNoKYn-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 20:56:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4232D16A4CF for ; Mon, 20 Dec 2004 20:56:45 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 676E443D5C for ; Mon, 20 Dec 2004 20:56:44 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81948 invoked from network); 20 Dec 2004 20:44:28 -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 ; 20 Dec 2004 20:44:28 -0000 Message-ID: <41C73CBC.9000106@freebsd.org> Date: Mon, 20 Dec 2004 21:57:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Holm References: <20041220194742.GA89598@peter.osted.lan> In-Reply-To: <20041220194742.GA89598@peter.osted.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: rwatson@freebsd.org cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 20:56:45 -0000 Peter Holm wrote: > During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > at netisr_processqueue+0xf > swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > ithread_loop+0x19e > fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > fork_trampoline() at fork_trampoline+0x8 > > http://www.holm.cc/stress/log/cons96.html Duh. This is really strange. t_state is 0x1 which is TCPS_LISTEN. Listen is only checked on the socket not on the tcpcb. However there is a panic after "after_listen:" that checks for exactly TCPS_LISTEN. It should never have made it past this one. That it did suggests some kind of race condition wrt. sockets and the tcpcb creation for the listening socket. Though even more strange is how this KASSERT can be reached; Only if the segment has FIN set. /me puzzled. Ok, we know the segment had FIN set. We know the tcpcb is in LISTEN state. We know in_pcblookup_hash() found this inpcb. We don't know how the segment processing made it past all the checks prior to this KASSERT. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 21:07:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21B1816A4CE for ; Mon, 20 Dec 2004 21:07:43 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 83D2143D41 for ; Mon, 20 Dec 2004 21:07:42 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 60877 invoked from network); 20 Dec 2004 21:07:41 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 20 Dec 2004 21:07:41 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBKL7eME089977; Mon, 20 Dec 2004 22:07:40 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBKL7ehJ089976; Mon, 20 Dec 2004 22:07:40 +0100 (CET) (envelope-from pho) Date: Mon, 20 Dec 2004 22:07:40 +0100 From: Peter Holm To: Andre Oppermann Message-ID: <20041220210740.GA89881@peter.osted.lan> References: <20041220194742.GA89598@peter.osted.lan> <41C73202.1050704@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C73202.1050704@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 21:07:43 -0000 On Mon, Dec 20, 2004 at 09:11:46PM +0100, Andre Oppermann wrote: > Peter Holm wrote: > >During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > > >panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > >tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > >ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > >netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > > at netisr_processqueue+0xf > >swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > >ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > >ithread_loop+0x19e > >fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > >fork_trampoline() at fork_trampoline+0x8 > > > >http://www.holm.cc/stress/log/cons96.html > > Interesting. Can you specify what kind of test was running at the > time of panic? > The tests from http://www.holm.cc/stress/src/stress.tgz Let me know if you need any more info or gdb output. - Peter From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 21:15:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F223F16A4CE for ; Mon, 20 Dec 2004 21:15:11 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E38243D46 for ; Mon, 20 Dec 2004 21:15:11 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 82069 invoked from network); 20 Dec 2004 21:02:55 -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 ; 20 Dec 2004 21:02:55 -0000 Message-ID: <41C74110.5040905@freebsd.org> Date: Mon, 20 Dec 2004 22:16:00 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Holm References: <20041220194742.GA89598@peter.osted.lan> <41C73202.1050704@freebsd.org> <20041220210740.GA89881@peter.osted.lan> In-Reply-To: <20041220210740.GA89881@peter.osted.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 21:15:12 -0000 Peter Holm wrote: > On Mon, Dec 20, 2004 at 09:11:46PM +0100, Andre Oppermann wrote: > >>Peter Holm wrote: >> >>>During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: >>> >>>panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 >>>tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 >>>ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 >>>netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) >>> at netisr_processqueue+0xf >>>swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b >>>ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at >>>ithread_loop+0x19e >>>fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e >>>fork_trampoline() at fork_trampoline+0x8 >>> >>>http://www.holm.cc/stress/log/cons96.html >> >>Interesting. Can you specify what kind of test was running at the >>time of panic? >> > > The tests from http://www.holm.cc/stress/src/stress.tgz Can you find out which of those test was doing the connect and listen? > Let me know if you need any more info or gdb output. Yes, please give *th, *inp and *so as well. -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 21:52:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E32CB16A4CE for ; Mon, 20 Dec 2004 21:52:33 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 5E5DA43D54 for ; Mon, 20 Dec 2004 21:52:33 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 11924 invoked from network); 20 Dec 2004 21:52:31 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 20 Dec 2004 21:52:31 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBKLqVTt090753; Mon, 20 Dec 2004 22:52:31 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBKLqV0x090752; Mon, 20 Dec 2004 22:52:31 +0100 (CET) (envelope-from pho) Date: Mon, 20 Dec 2004 22:52:31 +0100 From: Peter Holm To: Andre Oppermann Message-ID: <20041220215231.GA90721@peter.osted.lan> References: <20041220194742.GA89598@peter.osted.lan> <41C73202.1050704@freebsd.org> <20041220210740.GA89881@peter.osted.lan> <41C74110.5040905@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C74110.5040905@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 21:52:34 -0000 On Mon, Dec 20, 2004 at 10:16:00PM +0100, Andre Oppermann wrote: > Peter Holm wrote: > >On Mon, Dec 20, 2004 at 09:11:46PM +0100, Andre Oppermann wrote: > > > >>Peter Holm wrote: > >> > >>>During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > >>> > >>>panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > >>>tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > >>>ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > >>>netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > >>> at netisr_processqueue+0xf > >>>swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > >>>ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > >>>ithread_loop+0x19e > >>>fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > >>>fork_trampoline() at fork_trampoline+0x8 > >>> > >>>http://www.holm.cc/stress/log/cons96.html > >> > >>Interesting. Can you specify what kind of test was running at the > >>time of panic? > >> > > > >The tests from http://www.holm.cc/stress/src/stress.tgz > > Can you find out which of those test was doing the connect and listen? > That would be the "net" test. > >Let me know if you need any more info or gdb output. > > Yes, please give *th, *inp and *so as well. > I've updated http://www.holm.cc/stress/log/cons96.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 23:41:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9080216A4CE for ; Mon, 20 Dec 2004 23:41:07 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B99E43D31 for ; Mon, 20 Dec 2004 23:41:07 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBKNf4qn063103; Mon, 20 Dec 2004 18:41:04 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBKNf4Vn063101; Mon, 20 Dec 2004 18:41:04 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Mon, 20 Dec 2004 18:41:04 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041220234103.GA59225@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209144233.GA46928@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 20 Dec 2004 23:41:07 -0000 I realize it's been a while. Anyway, what I *think* is going on here is that slab_zalloc() is actually returning NULL even when called with M_WAITOK. Further inspection in slab_zalloc() reveals that this could come from several places. One of them is kmem_malloc() itself, which I doubt will ever return NULL if called with M_WAITOK. If this assumption is indeed correct, then the NULL must be being returned by slab_zalloc() itself, or due to a failed uma_zalloc_internal() call. It is also possible that slab_zalloc() returns NULL if the init that gets called for the zone fails. However, judging from the stack trace you provided, the init in question is mb_init_pack() (kern_mbuf.c). This particular init DOES perform an allocation and CAN in theory fail, but I believe it should be called with M_WAITOK as well, and so it should also never fail in theory. Have you gotten any further with the analysis of this particular trace? If not, I would suggest adding some more printf()s and analysis into slab_zalloc() itself, to see if that is indeed what is causing the infinite looping in uma_zone_slab() and, if so, attempt to figure out what part of slab_zalloc() is returning the NULL. Happy Holidays, -Bosko On Thu, Dec 09, 2004 at 03:42:33PM +0100, Peter Holm wrote: > I modified: > > $ cvs diff -u uma_core.c > Index: uma_core.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > retrieving revision 1.110 > diff -u -r1.110 uma_core.c > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > +++ uma_core.c 9 Dec 2004 14:38:32 -0000 > @@ -1926,6 +1926,7 @@ > { > uma_slab_t slab; > uma_keg_t keg; > + int i; > > keg = zone->uz_keg; > > @@ -1943,7 +1944,8 @@ > > slab = NULL; > > - for (;;) { > + for (i = 0;;i++) { > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > /* > * Find a slab with some space. Prefer slabs that are partially > * used over those that are totally full. This helps to reduce > > > and caught this one: > http://www.holm.cc/stress/log/cons94.html > -- > Peter Holm > _______________________________________________ > 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" -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 02:53:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF8AD16A4CE for ; Tue, 21 Dec 2004 02:53:56 +0000 (GMT) Received: from web4.thecenturiongroup.com (fw14.delivery.com [67.102.42.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35E9843D39 for ; Tue, 21 Dec 2004 02:53:54 +0000 (GMT) (envelope-from mjm@michaelmeltzer.com) Received: from [127.0.0.1] (ix1x1000.thecenturiongroup.com [192.32.248.52]) by web4.thecenturiongroup.com (Postfix) with ESMTP id A24917C00B for ; Mon, 20 Dec 2004 21:53:53 -0500 (EST) Message-ID: <41C78F9B.4010804@michaelmeltzer.com> Date: Mon, 20 Dec 2004 21:51:07 -0500 From: Michael Meltzer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) 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 Subject: twa driver, 3ware 9500s-4lp, speed issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 02:53:57 -0000 I have a 3ware 9500s-4lp controller with 4 10,000rpm raptors hooked up to it. 0+1 configuration. AMD dual 64 bit processor. This Hardware setup had Sese 9.1 running on it for a few days, One on the issues I had was that the controller seemed "slow". After reading 3ware white paper for turning for 2.6, the issue seemed to be buffer read ahead, i.e. blockdev -setra 16384 /dev/sda was needed for any type of read speed. Some quick benchmark under Bonnie++ Sequential read speeds from the mid 40's to 105meg/sec and had the write remained around 98 meg/sec. Now the Problem. loaded 5.3 , cvsup'ed and built for freebsd 5.3 stable, same hardware, the controller is feeling "slow" again. I tried to play with the vfs prams (vfs.read_max after some googling around). I could not find much information(other than the handbook) about the vfs prams and was unable to increase the speed. Can Any one sheed some light, subjections? insight, Gratefull for any help. Her is a iozone report pretty close to the linux bonnie++(sorry the bonnie failed) to give you all an idea whats up. exect same hardware. only change was OS and filesystem. Thank You MJM iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Iozone: Performance Test of File I/O Version $Revision: 3.196 $ Compiled for 64 bit mode. Build: freebsd Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg. Run began: Mon Dec 20 21:03:36 2004 File size set to 20971520 KB Record Size 60 KB Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 Output is in Kbytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 Kbytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Throughput test with 1 process Each process writes a 20971520 Kbyte file in 60 Kbyte records Children see throughput for 1 initial writers = 78738.67 KB/sec Parent sees throughput for 1 initial writers = 78716.55 KB/sec Min throughput per process = 78738.67 KB/sec Max throughput per process = 78738.67 KB/sec Avg throughput per process = 78738.67 KB/sec Min xfer = 20971500.00 KB Children see throughput for 1 rewriters = 32126.46 KB/sec Parent sees throughput for 1 rewriters = 32125.77 KB/sec Min throughput per process = 32126.46 KB/sec Max throughput per process = 32126.46 KB/sec Avg throughput per process = 32126.46 KB/sec Min xfer = 20971500.00 KB Children see throughput for 1 readers = 58563.70 KB/sec Parent sees throughput for 1 readers = 58557.14 KB/sec Min throughput per process = 58563.70 KB/sec Max throughput per process = 58563.70 KB/sec Avg throughput per process = 58563.70 KB/sec Min xfer = 20971500.00 KB Children see throughput for 1 re-readers = 58583.77 KB/sec Parent sees throughput for 1 re-readers = 58581.98 KB/sec Min throughput per process = 58583.77 KB/sec Max throughput per process = 58583.77 KB/sec Avg throughput per process = 58583.77 KB/sec Min xfer = 20971500.00 KB iozone test complete. From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 04:31:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E79416A4CE; Tue, 21 Dec 2004 04:31:18 +0000 (GMT) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 269CA43D2F; Tue, 21 Dec 2004 04:31:18 +0000 (GMT) (envelope-from matt@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id 5279F1449E1; Mon, 20 Dec 2004 23:31:17 -0500 (EST) Received: from [192.168.0.4] (wolf.spinthread.com [66.93.83.176]) by smtp2.arin.net (Postfix) with ESMTP id 124721449DB; Mon, 20 Dec 2004 23:31:14 -0500 (EST) Date: Mon, 20 Dec 2004 23:30:44 -0500 From: Matt Rowley To: obrien@freebsd.org Message-ID: <7528EBE92E58DD12C40EF72E@localhost.localdomain> In-Reply-To: <20041219204352.GA42665@dragon.nuxi.com> References: <20041211004038.GC50516@dragon.nuxi.com> <11A4B937C9C745F2DD5B75EC@elric.arin.net> <20041217081458.GB10368@dan.emsphone.com> <41C30321.5060209@freebsd.org> <22C3670E71A83C719BAC25E9@elric.arin.net> <20041219204352.GA42665@dragon.nuxi.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.3 and Adaptec raidutils (again) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 04:31:18 -0000 >> :) It does compile, when you remove packed. After commenting out the >> unneeded semaphore union struct in basic.hh, the whole thing compiles. >> The resulting raidutil binary spews out the same error as the one >> from the current binary port about "Engine connect failed: >> COMPATIBILITY number"... but that's to be expected. > > Can you post a patch to the sources? We should make the port build from > source, but it never rose high enough on my priority list. Is anyone > interested in working with me in updating the port? I definitely am. I'm having trouble finding a good source to use though... is it kosher to pull from ftp.netbsd.org? Their ftp site is the only place I've found that has raidmgt-3.31.tar.gz ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/raidmgt-3.31.tar.gz From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 07:53:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7661F16A4CE for ; Tue, 21 Dec 2004 07:53:33 +0000 (GMT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBD3443D31 for ; Tue, 21 Dec 2004 07:53:32 +0000 (GMT) (envelope-from michiel@boland.org) Received: from xs6.xs4all.nl (xs6.xs4all.nl [194.109.21.6]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id iBL7rW1d089455 for ; Tue, 21 Dec 2004 08:53:32 +0100 (CET) (envelope-from michiel@boland.org) Received: from xs6.xs4all.nl (boland37@localhost.xs4all.nl [127.0.0.1]) by xs6.xs4all.nl (8.12.10/8.12.10) with ESMTP id iBL7rVpo081003 for ; Tue, 21 Dec 2004 08:53:31 +0100 (CET) (envelope-from michiel@boland.org) Received: (from boland37@localhost) by xs6.xs4all.nl (8.12.10/8.12.9/Submit) id iBL7rVM2081002 for current@freebsd.org; Tue, 21 Dec 2004 08:53:31 +0100 (CET) (envelope-from michiel@boland.org) X-Authentication-Warning: xs6.xs4all.nl: boland37 set sender to michiel@boland.org using -f Date: Tue, 21 Dec 2004 08:53:31 +0100 From: Michiel Boland To: current@freebsd.org Message-ID: <20041221075331.GA74343@xs4all.nl> References: <20041130081804.GA22353@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041130081804.GA22353@xs4all.nl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: bash/readline coredumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 07:53:33 -0000 On Tue, Nov 30, 2004 at 09:18:04AM +0100, Michiel Boland wrote: > Hi. > Lately I am getting core dumps from bash (bash-2.05b.007_2 from ports). > To reproduce: type a command that spans multiple lines, like > > echo ' > ' > > Then bring up the last line with cursor-up or ^P and press enter. Turns out the brokennes was caused by the Readline 5.0 import on 2004/10/18, in particular by the following change in : typedef struct _hist_entry { char *line; + char *timestamp; /* char * rather than time_t for read/write */ histdata_t data; } HIST_ENTRY; Upgrading to the new bash (bash-3.0.16_1) fixed this for me. See also PR 75315. From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 08:29:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5854E16A4CE for ; Tue, 21 Dec 2004 08:29:12 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8B1243D48 for ; Tue, 21 Dec 2004 08:29:11 +0000 (GMT) (envelope-from avleeuwen@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so142063rnz for ; Tue, 21 Dec 2004 00:29:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iQhxDgMKpW0K0342HO6/wUEn4nDiym+H8E9A4mcdkZfhxlIMcHGIbnYAzv949rN+mODtACv3yOxsjdwbUfmVwxOUZ5gK5IQSnJdGZHEwZDenDxYBNDfFnfls7Y7JsuB6YeGS/dSk/0T/fqb7PyeHeA4bl2c5K3tPrcNHFkQAPyg= Received: by 10.38.8.67 with SMTP id 67mr270630rnh; Tue, 21 Dec 2004 00:29:10 -0800 (PST) Received: by 10.38.206.16 with HTTP; Tue, 21 Dec 2004 00:29:10 -0800 (PST) Message-ID: Date: Tue, 21 Dec 2004 09:29:10 +0100 From: Arjan Van Leeuwen To: Peter Holm In-Reply-To: <20041220215231.GA90721@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041220194742.GA89598@peter.osted.lan> <41C73202.1050704@freebsd.org> <20041220210740.GA89881@peter.osted.lan> <41C74110.5040905@freebsd.org> <20041220215231.GA90721@peter.osted.lan> cc: Andre Oppermann cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Arjan Van Leeuwen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 08:29:12 -0000 On Mon, 20 Dec 2004 22:52:31 +0100, Peter Holm wrote: > On Mon, Dec 20, 2004 at 10:16:00PM +0100, Andre Oppermann wrote: > > Peter Holm wrote: > > >On Mon, Dec 20, 2004 at 09:11:46PM +0100, Andre Oppermann wrote: > > > > > >>Peter Holm wrote: > > >> > > >>>During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > >>> > > >>>panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > > >>>tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > > >>>ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > > >>>netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > > >>> at netisr_processqueue+0xf > > >>>swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > > >>>ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > > >>>ithread_loop+0x19e > > >>>fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > > >>>fork_trampoline() at fork_trampoline+0x8 > > >>> > > >>>http://www.holm.cc/stress/log/cons96.html > > >> > > >>Interesting. Can you specify what kind of test was running at the > > >>time of panic? > > >> > > > > > >The tests from http://www.holm.cc/stress/src/stress.tgz > > > > Can you find out which of those test was doing the connect and listen? > > > > That would be the "net" test. > > > >Let me know if you need any more info or gdb output. > > > > Yes, please give *th, *inp and *so as well. > > > > I've updated http://www.holm.cc/stress/log/cons96.html This panic was also mentioned several times on stable@ (with 5.3-RELEASE). I was unable to get a kernel dump when I posted to stable, but I hope it can be fixed now that Peter has all the info! Best regards, Arjan > > -- > Peter Holm > _______________________________________________ > 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 Dec 21 10:41:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51DF616A4CE for ; Tue, 21 Dec 2004 10:41:38 +0000 (GMT) Received: from smtp8.wanadoo.fr (smtp8.wanadoo.fr [193.252.22.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0692643D53 for ; Tue, 21 Dec 2004 10:41:38 +0000 (GMT) (envelope-from cbaud@laposte.net) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0801.wanadoo.fr (SMTP Server) with SMTP id D03AB18000AA for ; Tue, 21 Dec 2004 11:41:36 +0100 (CET) Received: from libra.baudcl-liber.fr (AAmiens-151-1-38-39.w83-192.abo.wanadoo.fr [83.192.52.39]) by mwinf0801.wanadoo.fr (SMTP Server) with ESMTP id 60CF31800071 for ; Tue, 21 Dec 2004 11:41:36 +0100 (CET) From: "Claude B." To: freebsd-current@freebsd.org Content-Type: text/plain; charset=iso-8859-15 Message-Id: <1103629347.2718.8.camel@libra.baudcl-liber.fr> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Date: Tue, 21 Dec 2004 11:42:28 +0000 Content-Transfer-Encoding: 8bit Subject: RAID1 and ASUS PSCH-L motherboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 10:41:38 -0000 Hello, I intalled FreeBSD 5.3 without problem on my ASUS PSCH-L server motherboard. I setup a RAID 1 array in the BIOS of the Promise PDC20319 controller and I boot on the RAID array: "Hard Disk Drives:[FT TX Ary 1]". FreeBSD 5.3 supports perfectly this controller in view of the atacontrol commands and all seem ok: # atacontrol list ATA channel 0: Master: acd0 ATA/ATAPI revision 4 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: no device present Slave: no device present ATA channel 3: Master: ad6 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: ad10 Slave: no device present # atacontrol status ar0 ar0: ATA RAID1 subdisks: ad6 ad10 status: READY # I have two questions: 1)Can someone explain to me why the disks numbering ad6 et ad10? 2)How to do to check the RAID 1 is operational without all to break? Here the ships of my board: Chipset IntelŽ E7210 (CanterWood-ES) Memory Controller Hub -IntelŽ 6300ESB IO Controller Hub (Hance Rapid) -Support mémoire PC3200 DDR (Unbuffered DIMM, non-ECC et ECC) -Support des bus 64bit/66MHz PCI-X et 32bit/33MHz Contrôleur Serial ATA Contrôleur Promise PDC20319 4 Port 32bit/66MHz PCI Serial ATA, supportant les modes RAID 0, 1, 0+1 Contrôleur Intel 6300ESB IO Hub, provide 2 x Serial ATA supportant les modes RAID 0, 1 IDE Primaire & Secondaire channel bus master IDE ports support ATA100, Multi-Word DMA Mode 2, PIO Mode 3/4. Thank in anticipation, claude -- Clé publique: http://pgp.mit.edu From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 11:52:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 870A416A4CE for ; Tue, 21 Dec 2004 11:52:04 +0000 (GMT) Received: from lakermmtao11.cox.net (lakermmtao11.cox.net [68.230.240.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E70B943D55 for ; Tue, 21 Dec 2004 11:52:03 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.30.50]) by lakermmtao11.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041221115159.NTRV1657.lakermmtao11.cox.net@dolphin.local.net> for ; Tue, 21 Dec 2004 06:51:59 -0500 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id iBLBq2Gj082223 for ; Tue, 21 Dec 2004 05:52:02 -0600 (CST) (envelope-from conrads@cox.net) Date: Tue, 21 Dec 2004 05:51:57 -0600 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-ID: <20041221055157.5bf808ff@dolphin.local.net> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: NFS flakiness since @ last Friday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 11:52:04 -0000 I'm seeing some real instability in NFS since approximately last Friday. Intermittently, I'm seeing messages such as the following: On the client machine: Dec 20 23:18:22 dolphin kernel: impossible packet length (1820291) from nfs server gateway:/mm Dec 21 00:51:47 dolphin kernel: impossible packet length (1746474142) from nfs server gateway:/mm and Dec 21 01:14:41 dolphin kernel: nfs send error 35 for server gateway:/mm Dec 21 01:16:33 dolphin kernel: nfs send error 35 for server gateway:/mm Dec 21 01:16:38 dolphin kernel: nfs send error 35 for server gateway:/mm Dec 21 01:16:40 dolphin kernel: nfs server gateway:/mm: not responding Dec 21 01:16:43 dolphin kernel: nfs server gateway:/mm: is alive again On the server machine: Dec 20 21:52:48 gateway kernel: nfsd send error 32 Dec 20 21:57:50 gateway kernel: nfsd send error 32 Dec 20 22:00:45 gateway kernel: nfsd send error 32 Dec 20 22:23:29 gateway kernel: nfsd send error 32 Dec 20 23:18:23 gateway kernel: nfsd send error 32 Then, ultimately, all NFS communication just breaks down altogether until a reboot. I'm also seeing "sillyrenames" left behind occasionally in nfs-mounted directories. There were a couple of nfs-related commits last Thursday, which I believe are most likely the culprit, although I don't know which ones exactly. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 05:22:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 473C816A4CE for ; Tue, 21 Dec 2004 05:22:14 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id DFD8643D2F for ; Tue, 21 Dec 2004 05:22:13 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 4107 invoked from network); 21 Dec 2004 05:22:12 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 21 Dec 2004 05:22:12 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 20 Dec 2004 23:22:11 -0600 (CST) From: Mike Silbersack To: current@freebsd.org Message-ID: <20041220230429.E959@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 21 Dec 2004 13:01:21 +0000 Subject: dmesg with split lines? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 05:22:14 -0000 I just rebooted a SMP box with a new 6.0 kernel and noticed this: --- SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a Expensive timeout(9) function: 0xc06156a8(0) 0. 741 s Expensive timeout(9) function: 0xc06af454(0) 0.014054016 s xl0: promiscuous mode enabled --- No, that wrapping isn't a copy and paste error, it somehow got wrapped by the kernel. I don't know if that's significant or not, just asking. :) Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 14:32:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA21316A4CE for ; Tue, 21 Dec 2004 14:32:12 +0000 (GMT) Received: from hourri.hittite.isp.9tel.net (hourri.hittite.isp.9tel.net [62.62.156.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A3F243D3F for ; Tue, 21 Dec 2004 14:32:12 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from pcgyver.dyndns.org (unknown [84.97.163.154]) by hourri.hittite.isp.9tel.net (Postfix) with ESMTP id A0485157641 for ; Tue, 21 Dec 2004 16:09:30 +0100 (CET) Received: from [192.168.0.1] ([192.168.0.1]) by pcgyver.dyndns.org (8.13.1/8.13.1) with ESMTP id iBLESkVU082257 for ; Tue, 21 Dec 2004 15:28:46 +0100 (CET) (envelope-from martin.mato@wanadoo.fr) Message-ID: <41C8331C.30804@wanadoo.fr> Date: Tue, 21 Dec 2004 15:28:44 +0100 From: Martin MATO 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: gq doesn't compile in 6-CURRENT ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 14:32:13 -0000 cc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/local/openssl/include -O -pipe -march=pentium3 -Wall -W -Wno-unused -Wmissing-declarations -Wcast-align -Wpointer-arith -DLOCALEDIR=\"/usr/X11R6/share/locale\" -c `test -f 'i18n.c' || echo './'`i18n.c source='gq-xml.c' object='gq-xml.o' libtool=no \ depfile='.deps/gq-xml.Po' tmpdepfile='.deps/gq-xml.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/local/openssl/include -O -pipe -march=pentium3 -Wall -W -Wno-unused -Wmissing-declarations -Wcast-align -Wpointer-arith -DLOCALEDIR=\"/usr/X11R6/share/locale\" -c `test -f 'gq-xml.c' || echo './'`gq-xml.c In file included from gq-xml.c:42: xmlparse.h:54: error: syntax error before "xmlChar" xmlparse.h:95: error: syntax error before "xmlSAXHandler" xmlparse.h:119: error: syntax error before "xmlSAXHandler" gq-xml.c: In function `longCDATA': gq-xml.c:87: error: structure has no member named `cdata' gq-xml.c:89: error: structure has no member named `XMLhandler' gq-xml.c:89: error: structure has no member named `XMLhandler' gq-xml.c:89: error: structure has no member named `tag' gq-xml.c:89: error: structure has no member named `tag' gq-xml.c: In function `booleanCDATA': gq-xml.c:102: error: structure has no member named `cdata' gq-xml.c:104: error: structure has no member named `cdata' gq-xml.c:107: error: structure has no member named `XMLhandler' gq-xml.c:107: error: structure has no member named `XMLhandler' gq-xml.c:107: error: structure has no member named `tag' gq-xml.c:107: error: structure has no member named `tag' gq-xml.c: In function `ldif_formatE': gq-xml.c:265: error: structure has no member named `cdata' gq-xml.c: In function `search_argumentE': gq-xml.c:277: error: structure has no member named `cdata' gq-xml.c:283: error: structure has no member named `XMLhandler' gq-xml.c:283: error: structure has no member named `XMLhandler' gq-xml.c:283: error: structure has no member named `tag' gq-xml.c:283: error: structure has no member named `tag' gq-xml.c:286: error: structure has no member named `cdata' gq-xml.c: In function `schema_serverE': gq-xml.c:296: error: structure has no member named `cdata' gq-xml.c:296: error: structure has no member named `cdata' gq-xml.c: In function `ldapserverE': gq-xml.c:321: error: structure has no member named `XMLhandler' gq-xml.c:321: error: structure has no member named `XMLhandler' gq-xml.c: In function `ldapserver_nameE': gq-xml.c:335: error: structure has no member named `cdata' gq-xml.c:335: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_ldaphostE': gq-xml.c:342: error: structure has no member named `cdata' gq-xml.c:342: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_basednE': gq-xml.c:359: error: structure has no member named `cdata' gq-xml.c:359: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_binddnE': gq-xml.c:367: error: structure has no member named `cdata' gq-xml.c:367: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_bindpwE': gq-xml.c:374: error: structure has no member named `cdata' gq-xml.c:374: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_pw_encodingE': gq-xml.c:382: error: structure has no member named `cdata' gq-xml.c:382: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_bindtypeE': gq-xml.c:391: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_search_attributeE': gq-xml.c:399: error: structure has no member named `cdata' gq-xml.c:399: error: structure has no member named `cdata' gq-xml.c: In function `filter_nameE': gq-xml.c:493: error: structure has no member named `cdata' gq-xml.c:493: error: structure has no member named `cdata' gq-xml.c: In function `filter_ldapfilterE': gq-xml.c:500: error: structure has no member named `cdata' gq-xml.c:500: error: structure has no member named `cdata' gq-xml.c: In function `filter_servernameE': gq-xml.c:507: error: structure has no member named `cdata' gq-xml.c:507: error: structure has no member named `cdata' gq-xml.c: In function `filter_basednE': gq-xml.c:514: error: structure has no member named `cdata' gq-xml.c:514: error: structure has no member named `cdata' gq-xml.c: In function `template_nameE': gq-xml.c:538: error: structure has no member named `cdata' gq-xml.c:538: error: structure has no member named `cdata' gq-xml.c: In function `template_objectclassE': gq-xml.c:547: error: structure has no member named `cdata' gq-xml.c: In function `ldapserver_dt_attributeE': gq-xml.c:602: error: structure has no member named `cdata' gq-xml.c: In function `ldap_attributeS': gq-xml.c:620: error: structure has no member named `attrs' gq-xml.c:621: error: structure has no member named `attrs' gq-xml.c:625: error: structure has no member named `attrs' gq-xml.c:627: error: structure has no member named `attrs' gq-xml.c:649: error: structure has no member named `XMLhandler' gq-xml.c:649: error: structure has no member named `XMLhandler' gq-xml.c: In function `user_friendlyE': gq-xml.c:700: error: structure has no member named `cdata' gq-xml.c:700: error: structure has no member named `cdata' gq-xml.c:701: error: structure has no member named `cdata' gq-xml.c: In function `process_rcfile_XML': gq-xml.c:1173: error: `xmlSAXHandler' undeclared (first use in this function) gq-xml.c:1173: error: (Each undeclared identifier is reported only once gq-xml.c:1173: error: for each function it appears in.) gq-xml.c:1173: error: `handler' undeclared (first use in this function) gq-xml.c:1180: error: `errorSAXFunc' undeclared (first use in this function) gq-xml.c:1180: error: syntax error before "XMLerrorHandler" gq-xml.c:1181: error: `fatalErrorSAXFunc' undeclared (first use in this function) gq-xml.c:1181: error: syntax error before "XMLfatalErrorHandler" gq-xml.c:1182: error: `warningSAXFunc' undeclared (first use in this function) gq-xml.c:1182: error: syntax error before "XMLwarningHandler" gmake[2]: *** [gq-xml.o] Error 1 gmake[2]: Leaving directory `/usr/ports/net/gq/work/gq-1.0beta1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/net/gq/work/gq-1.0beta1' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/net/gq. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall59505.0 make ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! net/gq (compiler error) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed my system is a fresh build of both kernel and system: pcgyver# uname -a FreeBSD pcgyver.dyndns.org 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Dec 21 01:51:01 CET 2004 root@pcgyver.dyndns.org:/usr/obj/usr/src/sys/PCGYVER i386 the system was cvsuped and compiled one hour ago. From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 15:43:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A4316A4CF for ; Tue, 21 Dec 2004 15:43:20 +0000 (GMT) Received: from imap.univie.ac.at (mailbox-lmtp.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6773D43D46 for ; Tue, 21 Dec 2004 15:43:19 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id iBLFh3Dm309118; Tue, 21 Dec 2004 16:43:08 +0100 Date: Tue, 21 Dec 2004 16:43:03 +0100 (CET) From: Lukas Ertl To: current@FreeBSD.org Message-ID: <20041221163907.J46219@pcle2.cc.univie.ac.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx9.univie.ac.at 4247; Body=2 Fuz1=2 Fuz2=2 cc: sam@FreeBSD.org Subject: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 15:43:20 -0000 Hi, on a recent -current I can't use the ndis0 interface on my laptop anymore when having WEP enabled. I have both wlan and wlan_wep in my kernel, and the box panics either with a cryptic double fault or with a null pointer dereference (fault virtual address: 0xd00) in the if_ndis driver; the only backtrace I could get from that is: _mtx_lock_flags+0x12 ndis_intrtask+0x45 ndis_runq+0xf1 Any hints? 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 Tue Dec 21 15:43:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B26716A4CE for ; Tue, 21 Dec 2004 15:43:53 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FD743D55 for ; Tue, 21 Dec 2004 15:43:52 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBLFhpUT076223 for ; Tue, 21 Dec 2004 17:43:51 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 71729-09 for ; Tue, 21 Dec 2004 17:43:50 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBLFhorw076219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Dec 2004 17:43:50 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBLFhuuo016523 for current@FreeBSD.org; Tue, 21 Dec 2004 17:43:56 +0200 (EET) (envelope-from ru) Date: Tue, 21 Dec 2004 17:43:56 +0200 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20041221154356.GB16116@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua Subject: HEADS UP: NOFOO -> NO_FOO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 15:43:53 -0000 --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, As threatened several times in the past, the NOFOO -> NO_FOO conversion of various build knobs has just been done in HEAD. The new /usr/share/mk/bsd.compat.mk takes care of reminding you about the need to update your /etc/make.conf and various build scripts accordingly, while still providing the support for old knobs. The plan is to stop supporting the old knobs soon after we stop officially supporting FreeBSD 5.x, i.e., after several years. At this time, the warning in bsd.compat.mk becomes an error for a short period of time, mostly to help catch broken (by that time) ports, and then the support for old knobs will be completely removed. Old and new knobs may co-exist, in which case no warnings =66rom bsd.compat.mk will be issued. This is believed to be helpful for third-party software (including ports) that need to support more than just FreeBSD 6.0-CURRENT. The NOFOO -> NO_FOO conversion will NOT be done in RELENG_5. FAQ section. Q: Where can I get the list of old/new spellings? A: See bsd.compat.mk. Q: I want to use my /etc/make.conf to build different versions of FreeBSD, what should I do now? A: Use both forms of knobs. Q: Who will pay for all this transition pain? A: Tom Rhodes. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OwLcNYc0lM97+oe1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByES8qRfpzJluFF4RAiXvAJ9whVeYmzloBBWo/mkg7kl0/4RJOwCfWKH3 Ga1g5kZ9mLYG45GyH+h/zOM= =rvuz -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 16:19:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9064616A4CE for ; Tue, 21 Dec 2004 16:19:04 +0000 (GMT) Received: from av7-2-sn4.m-sp.skanova.net (av7-2-sn4.m-sp.skanova.net [81.228.10.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E71143D31 for ; Tue, 21 Dec 2004 16:19:04 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id A07603800B; Tue, 21 Dec 2004 17:19:03 +0100 (CET) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8EF2737EE0; Tue, 21 Dec 2004 17:19:03 +0100 (CET) Received: from sentinel (h211n1fls11o822.telia.com [213.64.66.211]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6F58437E53; Tue, 21 Dec 2004 17:19:01 +0100 (CET) From: "Daniel Eriksson" To: "'Conrad J. Sabatier'" , Date: Tue, 21 Dec 2004 17:21:00 +0100 Organization: Home Message-ID: 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: <20041221055157.5bf808ff@dolphin.local.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTnU9Qa6mO337B5RQCoBDR+sScufAAJI0rQ Subject: RE: NFS flakiness since @ last Friday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 16:19:04 -0000 Conrad J. Sabatier wrote: > I'm seeing some real instability in NFS since approximately > last Friday. I'm seeing the same problems. On my SMP client with debug.mpsafenet enabled it only takes a minute or two to lock up NFS enough that it cannot be brought back to life without a reboot. With debug.mpsafenet disabled I get the same error messages as Conrad describes, followed later by either a hard lockup (not possible to break to debugger) or non-functioning NFS. This is on a very recent (<24h) 6-CURRENT machine. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 17:21:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF79616A4CE for ; Tue, 21 Dec 2004 17:21:39 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C5D943D1D for ; Tue, 21 Dec 2004 17:21:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBLHKNsT005636; Tue, 21 Dec 2004 10:20:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Dec 2004 10:20:35 -0700 (MST) Message-Id: <20041221.102035.11997056.imp@bsdimp.com> To: sean@mcneil.com From: "M. Warner Losh" In-Reply-To: <1103489622.5226.6.camel@server.mcneil.com> References: <1103434515.1158.10.camel@server.mcneil.com> <20041219150157.O19917@alpha.siliconlandmark.com> <1103489622.5226.6.camel@server.mcneil.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: reboot without any info X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 17:21:39 -0000 In message: <1103489622.5226.6.camel@server.mcneil.com> Sean McNeil writes: : I think everyone has hardware fault on the brain right now. Please note : that the system works perfectly - even under extreme load - until the : moment I run totem in the debugger. Then it is instant. I would never : consider this behavior as hardware related. In that case, you may be stuck with debugging the debugging process. adding printfs to the perimeter (with a serial console), and gradually worming your way in. Not all printfs happen in some cases, so there may be some abiguity that may drive you nuts... Chances are the kernel/debugger is restoring state bogusly, and that we're jumping to that bogus state, causing the reset (most likely in kernel mode). Warner From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 17:53:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A97A616A4CE for ; Tue, 21 Dec 2004 17:53:16 +0000 (GMT) Received: from web80603.mail.yahoo.com (web80603.mail.yahoo.com [66.218.79.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 88D2E43D2F for ; Tue, 21 Dec 2004 17:53:16 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20041221175316.57814.qmail@web80603.mail.yahoo.com> Received: from [64.172.46.67] by web80603.mail.yahoo.com via HTTP; Tue, 21 Dec 2004 09:53:16 PST Date: Tue, 21 Dec 2004 09:53:16 -0800 (PST) From: Mohan Srinivasan To: "Conrad J. Sabatier" , freebsd-current@freebsd.org In-Reply-To: <20041221055157.5bf808ff@dolphin.local.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: NFS flakiness since @ last Friday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 17:53:16 -0000 Error 32 is an EPIPE, which NFS will get if the TCP connection has been torn down and it tries to send any new data on the socket. The checkin on Thursday was to change the format of the NFS sillyrename. It would be surprising if that could cause these errors. The checkin on Wednesday was to add a new feature - NFS DirectIO. Which should not be used unless the application is opening files O_DIRECT. This can be completely disabled by sysctl'ing nfs_directio_enable to 0. Since you're seeing EPIPE errors, just to isolate the issue to NFS/TCP or NFS/UDP, can you force all mounts to NFS/UDP and see if the lockups persist ? Also, disable nfs directio completely. mohan --- "Conrad J. Sabatier" wrote: > I'm seeing some real instability in NFS since approximately last Friday. > Intermittently, I'm seeing messages such as the following: > > On the client machine: > > Dec 20 23:18:22 dolphin kernel: impossible packet length (1820291) from > nfs server gateway:/mm > Dec 21 00:51:47 dolphin kernel: impossible packet length (1746474142) > from nfs server gateway:/mm > > and > > Dec 21 01:14:41 dolphin kernel: nfs send error 35 for server gateway:/mm > Dec 21 01:16:33 dolphin kernel: nfs send error 35 for server gateway:/mm > Dec 21 01:16:38 dolphin kernel: nfs send error 35 for server gateway:/mm > Dec 21 01:16:40 dolphin kernel: nfs server gateway:/mm: not responding > Dec 21 01:16:43 dolphin kernel: nfs server gateway:/mm: is alive again > > On the server machine: > > Dec 20 21:52:48 gateway kernel: nfsd send error 32 > Dec 20 21:57:50 gateway kernel: nfsd send error 32 > Dec 20 22:00:45 gateway kernel: nfsd send error 32 > Dec 20 22:23:29 gateway kernel: nfsd send error 32 > Dec 20 23:18:23 gateway kernel: nfsd send error 32 > > Then, ultimately, all NFS communication just breaks down > altogether until a reboot. > > I'm also seeing "sillyrenames" left behind occasionally in nfs-mounted > directories. > > There were a couple of nfs-related commits last Thursday, which I > believe are most likely the culprit, although I don't know which ones > exactly. > > -- > Conrad J. Sabatier -- "In Unix veritas" > _______________________________________________ > 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 Dec 21 17:57:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D4916A4CE; Tue, 21 Dec 2004 17:57:03 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCCB43D46; Tue, 21 Dec 2004 17:57:03 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id iBLHv3Wi001149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2004 09:57:03 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41C863E1.2070406@errno.com> Date: Tue, 21 Dec 2004 09:56:49 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lukas Ertl References: <20041221163907.J46219@pcle2.cc.univie.ac.at> In-Reply-To: <20041221163907.J46219@pcle2.cc.univie.ac.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 17:57:04 -0000 Lukas Ertl wrote: > Hi, > > on a recent -current I can't use the ndis0 interface on my laptop > anymore when having WEP enabled. I have both wlan and wlan_wep in my > kernel, and the box panics either with a cryptic double fault or with a > null pointer dereference (fault virtual address: 0xd00) in the if_ndis > driver; the only backtrace I could get from that is: > > _mtx_lock_flags+0x12 > ndis_intrtask+0x45 > ndis_runq+0xf1 > > Any hints? These are symptomatic of your missing fixes; please update or be more specific about what "a recent -current" means. Sam PS. There is no reason to cc me directly; I read the mailing lists. From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 17:57:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A56016A4E4 for ; Tue, 21 Dec 2004 17:57:17 +0000 (GMT) Received: from web80605.mail.yahoo.com (web80605.mail.yahoo.com [66.218.79.94]) by mx1.FreeBSD.org (Postfix) with SMTP id CAE0743D3F for ; Tue, 21 Dec 2004 17:57:16 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20041221175716.79931.qmail@web80605.mail.yahoo.com> Received: from [64.172.46.67] by web80605.mail.yahoo.com via HTTP; Tue, 21 Dec 2004 09:57:16 PST Date: Tue, 21 Dec 2004 09:57:16 -0800 (PST) From: Mohan Srinivasan To: Arjan Van Leeuwen , Peter Holm In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Andre Oppermann cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 17:57:17 -0000 Arjan, This panic is different from the one you experienced on stable. This panic is from the tcp_input() path. The panic you saw was from the tcp_output()->m_copym() path, which is likely the result of attempting to pull more data out of the snd buffer than is present there. I am pretty sure the panic you saw is TCP SACK related, but without a core dump (a dump of the SACK state), it would be impossible to fix the problem you saw. mohan --- Arjan Van Leeuwen wrote: > On Mon, 20 Dec 2004 22:52:31 +0100, Peter Holm wrote: > > On Mon, Dec 20, 2004 at 10:16:00PM +0100, Andre Oppermann wrote: > > > Peter Holm wrote: > > > >On Mon, Dec 20, 2004 at 09:11:46PM +0100, Andre Oppermann wrote: > > > > > > > >>Peter Holm wrote: > > > >> > > > >>>During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > > >>> > > > >>>panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > > > >>>tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > > > >>>ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > > > >>>netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > > > >>> at netisr_processqueue+0xf > > > >>>swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > > > >>>ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > > > >>>ithread_loop+0x19e > > > >>>fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > > > >>>fork_trampoline() at fork_trampoline+0x8 > > > >>> > > > >>>http://www.holm.cc/stress/log/cons96.html > > > >> > > > >>Interesting. Can you specify what kind of test was running at the > > > >>time of panic? > > > >> > > > > > > > >The tests from http://www.holm.cc/stress/src/stress.tgz > > > > > > Can you find out which of those test was doing the connect and listen? > > > > > > > That would be the "net" test. > > > > > >Let me know if you need any more info or gdb output. > > > > > > Yes, please give *th, *inp and *so as well. > > > > > > > I've updated http://www.holm.cc/stress/log/cons96.html > > This panic was also mentioned several times on stable@ (with > 5.3-RELEASE). I was unable to get a kernel dump when I posted to > stable, but I hope it can be fixed now that Peter has all the info! > > Best regards, > > Arjan > > > > > -- > > Peter Holm > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 18:18:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7637216A4CE for ; Tue, 21 Dec 2004 18:18:12 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5446B43D53 for ; Tue, 21 Dec 2004 18:18:12 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 39E5872DD4; Tue, 21 Dec 2004 10:18:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3464A72DCB; Tue, 21 Dec 2004 10:18:12 -0800 (PST) Date: Tue, 21 Dec 2004 10:18:12 -0800 (PST) From: Doug White To: Derek Tattersall In-Reply-To: <200412191831.iBJIVjlx099016@lorne.arm.org> Message-ID: <20041221101603.E75632@carver.gumbysoft.com> References: <200412191831.iBJIVjlx099016@lorne.arm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: Buildworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 18:18:12 -0000 On Sun, 19 Dec 2004, Derek Tattersall wrote: > I have rebuilt current last Sunday and today. Last Sunday, buildworld > failed with default make.conf. I found it would build with CFLAGS=-O > -pipe . It failed building insn-attrtab with an internal compiler > error. This is most likely bad hardware or cooling. You noted that you aren't running overclocked, but is your CPU cooler and case air circulation sufficient? buildworld generates a LOT of CPU load and therefore heat. You might try installing the mbmon port (or whatever is appropriate for your system) or watching hw.acpi.thermal if your system registers thermal zones. > Today, after cvsup'ing this morning, it would not build with default > make.conf. Switching to the above CFLAGS, it fails building > c_common.c with the same internal compiler error. > /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c: In function ` > c_common_nodes_and_builtins': > /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:3465: internal > compiler error: in control_flow_insn_p, at cfgbuild.c:130 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > I have not submitted a report to gcc because I am not confident that > this is really a compiler problem. > > Before last week, buildworld worked (or didn't) quite > straightforwardly. This problem has me completely baffled. > > Hardware is ASUS A7V with AMD Athlon XP 2800+. It seems like vanilla > hardware. Memtest86 run for 1-2 hours shows no problems with the > memory. The CPU is not overclocked, (1650 Mhz). 1 gig of Crucial > pc2700 memory. > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 18:21:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCCC116A4CE for ; Tue, 21 Dec 2004 18:21:22 +0000 (GMT) Received: from imap.univie.ac.at (mailbox-lmtp.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0F0743D3F for ; Tue, 21 Dec 2004 18:21:21 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from korben.prv.univie.ac.at (korben.prv.univie.ac.at [131.130.7.98]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id iBLILBDm381648; Tue, 21 Dec 2004 19:21:15 +0100 Date: Tue, 21 Dec 2004 19:21:11 +0100 (CET) From: Lukas Ertl To: Sam Leffler In-Reply-To: <41C863E1.2070406@errno.com> Message-ID: <20041221191910.J653@korben.prv.univie.ac.at> References: <20041221163907.J46219@pcle2.cc.univie.ac.at> <41C863E1.2070406@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx9.univie.ac.at 4248; Body=2 Fuz1=2 Fuz2=2 cc: current@FreeBSD.org Subject: Re: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 18:21:22 -0000 On Tue, 21 Dec 2004, Sam Leffler wrote: >> _mtx_lock_flags+0x12 >> ndis_intrtask+0x45 >> ndis_runq+0xf1 >> >> Any hints? > > These are symptomatic of your missing fixes; please update or be more > specific about what "a recent -current" means. Recent as in 'Tue Dec 21 15:40:23 CET 2004'. I load if_ndis.ko from /boot/loader.conf and configure it with: ifconfig ndis0 inet netmask ssid wepmode on wepkey 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 Tue Dec 21 18:28:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 914FF16A4CE; Tue, 21 Dec 2004 18:28:35 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 729A543D46; Tue, 21 Dec 2004 18:28:35 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6315672DD4; Tue, 21 Dec 2004 10:28:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6056E72DCB; Tue, 21 Dec 2004 10:28:35 -0800 (PST) Date: Tue, 21 Dec 2004 10:28:35 -0800 (PST) From: Doug White To: "Mr. Darren" In-Reply-To: <20041220065922.35072.qmail@web40702.mail.yahoo.com> Message-ID: <20041221102340.O75632@carver.gumbysoft.com> References: <20041220065922.35072.qmail@web40702.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: pci dma error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 18:28:35 -0000 On Sun, 19 Dec 2004, Mr. Darren wrote: > I have a diamond mx400 and I get the following error > Maestro: DMA buffer beyond 256MB (busaddr 0x1ed50000 > size 81920) > Couldn't allocate Maestro memory This string doesn't appear in the FreeBSD maestro driver, at least in HEAD. What is the output of 'ident /boot/kernel/snd_maestro.ko', 'ident /boot/kernel/snd_maestro.ko', and 'uname -a'? > I am informed on some linux sites that this problem is > related to having more than 250megs of ram. they > claimed the problem was fixed by manually setting a > dma.. I'm not sure how to do this in freebsd. According the commit logs the necessary adjustments to busdma were made to the maestro3 driver months ago. What sound driver does the Diamond use? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 18:35:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4DDA16A4CE for ; Tue, 21 Dec 2004 18:35:03 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D08443D2F for ; Tue, 21 Dec 2004 18:35:03 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 7168872DD4; Tue, 21 Dec 2004 10:35:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6C42872DCB; Tue, 21 Dec 2004 10:35:03 -0800 (PST) Date: Tue, 21 Dec 2004 10:35:03 -0800 (PST) From: Doug White To: Michael Meltzer In-Reply-To: <41C78F9B.4010804@michaelmeltzer.com> Message-ID: <20041221103449.Q75632@carver.gumbysoft.com> References: <41C78F9B.4010804@michaelmeltzer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: twa driver, 3ware 9500s-4lp, speed issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 18:35:03 -0000 Sorry for the top post, but there's one imporant thing you forgot: Volume config? On Mon, 20 Dec 2004, Michael Meltzer wrote: > I have a 3ware 9500s-4lp controller with 4 10,000rpm raptors hooked up > to it. 0+1 configuration. AMD dual 64 bit processor. > > This Hardware setup had Sese 9.1 running on it for a few days, One on > the issues I had was that the controller seemed "slow". After reading > 3ware white paper for turning for 2.6, the issue seemed to be buffer > read ahead, i.e. blockdev -setra 16384 /dev/sda was needed for any type > of read speed. Some quick benchmark under Bonnie++ Sequential read > speeds from the mid 40's to 105meg/sec and had the write remained around > 98 meg/sec. > > Now the Problem. loaded 5.3 , cvsup'ed and built for freebsd 5.3 stable, > same hardware, the controller is feeling "slow" again. I tried to play > with the vfs prams (vfs.read_max after some googling around). I could > not find much information(other than the handbook) about the vfs prams > and was unable to increase the speed. Can Any one sheed some light, > subjections? insight, Gratefull for any help. > > Her is a iozone report pretty close to the linux bonnie++(sorry the > bonnie failed) to give you all an idea whats up. exect same hardware. > only change was OS and filesystem. Thank You > > MJM > > iozone -s 20480m -r 60 -i 0 -i 1 -t 1 > Iozone: Performance Test of File I/O > Version $Revision: 3.196 $ > Compiled for 64 bit mode. > Build: freebsd > > Contributors:William Norcott, Don Capps, Isom Crawford, Kirby > Collins > Al Slater, Scott Rhine, Mike Wisner, Ken Goss > Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, > Randy Dunlap, Mark Montague, Dan Million, > Jean-Marc Zucconi, Jeff Blomberg. > > Run began: Mon Dec 20 21:03:36 2004 > > File size set to 20971520 KB > Record Size 60 KB > Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 > Output is in Kbytes/sec > Time Resolution = 0.000001 seconds. > Processor cache size set to 1024 Kbytes. > Processor cache line size set to 32 bytes. > File stride size set to 17 * record size. > Throughput test with 1 process > Each process writes a 20971520 Kbyte file in 60 Kbyte records > > Children see throughput for 1 initial writers = 78738.67 KB/sec > Parent sees throughput for 1 initial writers = 78716.55 KB/sec > Min throughput per process = 78738.67 KB/sec > Max throughput per process = 78738.67 KB/sec > Avg throughput per process = 78738.67 KB/sec > Min xfer = 20971500.00 KB > > Children see throughput for 1 rewriters = 32126.46 KB/sec > Parent sees throughput for 1 rewriters = 32125.77 KB/sec > Min throughput per process = 32126.46 KB/sec > Max throughput per process = 32126.46 KB/sec > Avg throughput per process = 32126.46 KB/sec > Min xfer = 20971500.00 KB > > Children see throughput for 1 readers = 58563.70 KB/sec > Parent sees throughput for 1 readers = 58557.14 KB/sec > Min throughput per process = 58563.70 KB/sec > Max throughput per process = 58563.70 KB/sec > Avg throughput per process = 58563.70 KB/sec > Min xfer = 20971500.00 KB > > Children see throughput for 1 re-readers = 58583.77 KB/sec > Parent sees throughput for 1 re-readers = 58581.98 KB/sec > Min throughput per process = 58583.77 KB/sec > Max throughput per process = 58583.77 KB/sec > Avg throughput per process = 58583.77 KB/sec > Min xfer = 20971500.00 KB > > > > iozone test complete. > _______________________________________________ > 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" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 19:42:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AA8B16A4CF for ; Tue, 21 Dec 2004 19:42:20 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B28043D39 for ; Tue, 21 Dec 2004 19:42:19 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 17362 invoked from network); 21 Dec 2004 19:42:13 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.118) by gandalf.online.bg with SMTP; 21 Dec 2004 19:42:13 -0000 Received: (qmail 51246 invoked by uid 1000); 21 Dec 2004 19:42:17 -0000 Date: Tue, 21 Dec 2004 21:42:17 +0200 From: Peter Pentchev To: Craig Rodrigues Message-ID: <20041221194217.GE801@straylight.m.ringlet.net> Mail-Followup-To: Peter Pentchev , Craig Rodrigues , freebsd-current@freebsd.org, freebsd-docs@freebsd.org References: <20041210000933.GA5325@crodrigues.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xJK8B5Wah2CMJs8h" Content-Disposition: inline In-Reply-To: <20041210000933.GA5325@crodrigues.org> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: freebsd-docs@freebsd.org Subject: Re: hw.ata.atapi_dma patch for ata(4) man page? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 19:42:20 -0000 --xJK8B5Wah2CMJs8h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 09, 2004 at 07:09:33PM -0500, Craig Rodrigues wrote: > Hi, >=20 > In ata(4), it states: >=20 > hw.ata.atapi_dma > set to 1 for DMA access, 0 for PIO (default is PIO). >=20 > In src/sys/dev/ata/ata-all.c, this sysctl is by default > set to 1 (on -CURRENT, and also on 5.3-RELEASE). >=20 > Perhaps this patch is in order? Patch applied, thanks! G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Do you think anybody has ever had *precisely this thought* before? --xJK8B5Wah2CMJs8h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByHyZ7Ri2jRYZRVMRAj20AJ0fjU6obbqO8UXgaE+3vamSOtim3QCgvDxU TqwMl1iebiG86CopOaEpfuE= =McjZ -----END PGP SIGNATURE----- --xJK8B5Wah2CMJs8h-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 20:36:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9345116A4D1 for ; Tue, 21 Dec 2004 20:36:00 +0000 (GMT) Received: from hq.sectorb.msk.ru (petaflop.b.gz.ru [217.67.124.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 077DC43D1F for ; Tue, 21 Dec 2004 20:35:59 +0000 (GMT) (envelope-from chinhngt@sectorb.msk.ru) Received: from unix.local (unix.local [172.16.12.120]) by hq.sectorb.msk.ru (Postfix) with ESMTP id C4BC8213C; Tue, 21 Dec 2004 23:35:55 +0300 (MSK) Date: Tue, 21 Dec 2004 23:36:10 +0300 (MSK) From: Nguyen Tam Chinh X-X-Sender: chinhngt@unix.local To: Poul-Henning Kamp In-Reply-To: <11525.1102849563@critter.freebsd.dk> Message-ID: <20041221233459.W3105@unix.local> References: <11525.1102849563@critter.freebsd.dk> Keywords: 216091683 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@freebsd.org Subject: Re: [fsck -B problem] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 20:36:00 -0000 On Sun, 12 Dec 2004, Poul-Henning Kamp wrote: > In message <20041210034850.C2440@unix.local>, Nguyen Tam Chinh writes: > >> Hmm, I think the problem is still there, or maybe I misunderstanding >> something ... >> See the result: >> ------------------------------------------- >> unix# dmesg | grep WARN >> WARNING: /root was not properly dismounted >> WARNING: attempt to net_add_domain(netgraph) after domainfinalize() >> unix# fsck -B ad0s1h >> Can't stat /root/.snap/fsck_snapshot: No such file or directory >> unix# uname -a >> FreeBSD unix.hackers 6.0-CURRENT FreeBSD 6.0-CURRENT #10: Fri Dec 10 >> 02:42:45 MSK 2004 >> root@unix.hackers:/mnt/unix/Temp/obj/usr/src/sys/kernel i386 >> unix# >> ------------------------------------------- >> I must reboot in single user mode to manually run fsck other slides, but >> I left /root to verify the background fsck. > > Ok, found it: fsck_ffs passed random stack bits to the kernel as > mountoptions. > > Try with -current now, and make sure to recompile fsck_ffs/main.c 1.43 > OK, it was fixed. :) (I tested this morning) ----- With best regards, | The Power to Serve Nguyen Tam Chinh | http://www.FreeBSD.org Loc: sp.cs.msu.ru | http://chinhngt.svmgu.com | http://www.gnu.org/copyleft/copyleft.html From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 20:45:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5CDC16A4CE for ; Tue, 21 Dec 2004 20:45:41 +0000 (GMT) Received: from 168.18.broadband2.iol.cz (27.240.broadband2.iol.cz [83.208.240.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E2343D58 for ; Tue, 21 Dec 2004 20:45:40 +0000 (GMT) (envelope-from bln@deprese.net) Received: from [172.16.3.2] (helo=[172.16.3.2]) by 168.18.broadband2.iol.cz with asmtp (Exim 4.41) id 1Cgqt1-0004Fp-7v for current@freebsd.org; Tue, 21 Dec 2004 21:45:39 +0100 Message-ID: <41C88B6F.2010803@deprese.net> Date: Tue, 21 Dec 2004 21:45:35 +0100 From: Ondra Holecek User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) 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 Subject: acpiconf -s3 and time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 20:45:41 -0000 hello, i use 5.3-STABLE, and have noticed, that if i run acpiconf -s3 (hard sleep ?) on my laptop, all is fine, but the current time "freezes", so if i power my laptop later on, i have the same time as before sleep it is very ..er..unpleasant to set up time after each sleep again i am not sure, but think that some version before this worked, so question is how to make it work again :) -- # If it happens once, it's a bug. # If it happens twice, it's a feature. # If it happens more then twice, it's a design philosophy. From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 21:07:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA57416A4CF for ; Tue, 21 Dec 2004 21:07:07 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8773343D4C for ; Tue, 21 Dec 2004 21:07:06 +0000 (GMT) (envelope-from avleeuwen@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so168575rnz for ; Tue, 21 Dec 2004 13:07:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rPoXMCkyIynBhsCC6RhGA9LcG2N+J0OP0z36vhwZqku1jSZjEx05r05opuY1jKUILacI3nSUl/3e5Va1TEqs8Ufz9nFb3MhaPuwm/GbkBX33vjITb6vSRk59c/wP5HtnP4fpEYnC9PKfztrG78m/syj/RovPEE++UJSRNznDFwY= Received: by 10.38.8.67 with SMTP id 67mr480061rnh; Tue, 21 Dec 2004 13:07:05 -0800 (PST) Received: by 10.38.206.16 with HTTP; Tue, 21 Dec 2004 13:07:05 -0800 (PST) Message-ID: Date: Tue, 21 Dec 2004 22:07:05 +0100 From: Arjan Van Leeuwen To: Mohan Srinivasan In-Reply-To: <20041221175716.79931.qmail@web80605.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041221175716.79931.qmail@web80605.mail.yahoo.com> cc: Andre Oppermann cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Arjan Van Leeuwen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 21:07:08 -0000 Hey Mohan, On Tue, 21 Dec 2004 09:57:16 -0800 (PST), Mohan Srinivasan wrote: > Arjan, > > This panic is different from the one you experienced on stable. > This panic is from the tcp_input() path. > > The panic you saw was from the tcp_output()->m_copym() path, > which is likely the result of attempting to pull more data out > of the snd buffer than is present there. I am pretty sure the > panic you saw is TCP SACK related, but without a core dump > (a dump of the SACK state), it would be impossible to fix the > problem you saw. Hmm... I'm not sure. See http://www.piwebs.com/freebsd/pagefault-network.jpg - there's ip_input, but no tcp_output. It's probably still a different panic though :). I'll resume my hunt for a coredump on this machine when I'm able to replace it with another one, I hope next week. Arjan > > mohan > > --- Arjan Van Leeuwen wrote: > > > On Mon, 20 Dec 2004 22:52:31 +0100, Peter Holm wrote: > > > On Mon, Dec 20, 2004 at 10:16:00PM +0100, Andre Oppermann wrote: > > > > Peter Holm wrote: > > > > >On Mon, Dec 20, 2004 at 09:11:46PM +0100, Andre Oppermann wrote: > > > > > > > > > >>Peter Holm wrote: > > > > >> > > > > >>>During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > > > >>> > > > > >>>panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > > > > >>>tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > > > > >>>ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > > > > >>>netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > > > > >>> at netisr_processqueue+0xf > > > > >>>swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > > > > >>>ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > > > > >>>ithread_loop+0x19e > > > > >>>fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > > > > >>>fork_trampoline() at fork_trampoline+0x8 > > > > >>> > > > > >>>http://www.holm.cc/stress/log/cons96.html > > > > >> > > > > >>Interesting. Can you specify what kind of test was running at the > > > > >>time of panic? > > > > >> > > > > > > > > > >The tests from http://www.holm.cc/stress/src/stress.tgz > > > > > > > > Can you find out which of those test was doing the connect and listen? > > > > > > > > > > That would be the "net" test. > > > > > > > >Let me know if you need any more info or gdb output. > > > > > > > > Yes, please give *th, *inp and *so as well. > > > > > > > > > > I've updated http://www.holm.cc/stress/log/cons96.html > > > > This panic was also mentioned several times on stable@ (with > > 5.3-RELEASE). I was unable to get a kernel dump when I posted to > > stable, but I hope it can be fixed now that Peter has all the info! > > > > Best regards, > > > > Arjan > > > > > > > > -- > > > Peter Holm > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 21:10:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEB3116A4CE for ; Tue, 21 Dec 2004 21:10:09 +0000 (GMT) Received: from mail.seekingfire.com (caliban.rospa.ca [24.72.10.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5101B43D1D for ; Tue, 21 Dec 2004 21:10:09 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id BDE2521C; Tue, 21 Dec 2004 15:10:08 -0600 (CST) Date: Tue, 21 Dec 2004 15:10:08 -0600 From: Tillman Hodgson To: FreeBSD -CURRENT Message-ID: <20041221211008.GB2641@seekingfire.com> References: <20041214165144.GJ17907@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041214165144.GJ17907@seekingfire.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.6i Subject: Re: krb5 port: -current behaves differently than 4.X w.r.t rsh (possibly EPERM from bind) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 21:10:10 -0000 On Tue, Dec 14, 2004 at 10:51:44AM -0600, Tillman Hodgson wrote: > Howdy folks, > > I'm this on trying on -current@ to see if I can work with someone here to > get this problem trouble-shot and fixed. I'm still trying to resolve this proble. I have a ktrace.dump available (using `ktrace -di rsh -x -d athena uptime`), but it doesn't seem to show anything out of the ordinary. I'm not very proficient with ktrace and kdump, however. For instance, I didn't see the socket operations ... I imagien that takes place in a library and simply wasn't captured. I also have a tcpdump capture. It looks like the connect to port kshell passes the 3-way handshake. This is where things get weird. The kshd host sends a new SYN back to the client on the client's source port + 1. The client sends a reset packet back to the host (it seems it's not listening there). The host then sends a FIN to the original source port, closing off the original connection attempt. I'm not sure what the connect-back is all about ... Any ideas out there? I'd really like to get the Kerberos rsh client working on a 5.X system. -T > Date: Tue, 23 Nov 2004 16:00:09 -0600 > From: Tillman Hodgson > Subject: krb5 port: -current behaves differently than 4.X w.r.t rsh > To: FreeBSD-Ports > > Howdy folks, > > [I'm not sure that ports@ is the right place for this, but thought I'd > start here and see what happens.] > > I run a couple of Kerberos realms. I recently installed some new 5.3R > machines and then immediately upgraded them to -current. Cursory testing > (I know, I know) seemed to show that the MIT Kerberos port > (security/krb5) was working correctly. Over time, I've found a > difference between it and my older 4.X systems. > > While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic > tools work correctly, the kerberos rsh client (not the server, it's > fine) doesn't seem to work. > > Here's a a 4-stable box connecting via rsh to anotehr 4-stable box as > well as to a -current box: > > [root@athena ~]# rsh -x coyote uname -a > This rsh session is encrypting input/output data transmissions. > FreeBSD coyote.seekingfire.com 4.10-STABLE FreeBSD 4.10-STABLE #0: Thu Nov 18 13:10:32 CST 2004 > toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE i386 > > [root@athena ~]# rsh -x backforty uname -a > This rsh session is encrypting input/output data transmissions. > FreeBSD backforty.seekingfire.prv 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Nov 19 08:03:52 CST 2004 > tillman@backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY i386 > > When I try to connect from the -current box ('backforty' from the > example above) outwards to either type of box I get a failure: > > $ rsh -x coyote uptime > socket: protocol error or closed connection in circuit setup > > $ rsh -x caliban uptime > socket: protocol error or closed connection in circuit setup > > (caliban is another -current box). > > The auth.log on the server-side system shows: > > Nov 23 15:55:10 athena kshd[4565]: connect second port: Connection refused > > Note that all otehr client Kerberos apps work: I can telnet -x, ftp -x, > rlogin, etc to my hearts connect. Only rsh displays this behaviour. > > I've confirmed that I'm running the right rsh binary: > > $ which rsh > /usr/local/krb5/bin/rsh > > And I've confirmed that they're both running up-to-date ports trees and > the most current version fo security/krb5. > > I've googled for the auth.log message. It seems that the connection > "back" for stderr is being denied. By what, I don't know ... the host > backforty isn't runnign any sort of firewall: > > root@backforty# ipfw list > ipfw: getsockopt(IP_FW_GET): Protocol not available > root@backforty# ipfstat -hin > open: No such file or directory > root@backforty# pfctl -s rules > pfctl: /dev/pf: No such file or directory > > Any ideas? From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 23:50:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4F0F16A4CE for ; Tue, 21 Dec 2004 23:50:54 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5A9A43D31 for ; Tue, 21 Dec 2004 23:50:52 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (PPP264.air128.dti.ne.jp [210.170.213.35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E79E215218 for ; Wed, 22 Dec 2004 08:50:47 +0900 (JST) Date: Wed, 22 Dec 2004 08:51:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: current@freebsd.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: BIND9 performance issues with SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 21 Dec 2004 23:50:55 -0000 Hello, I was recently playing with FreeBSD 5.3's SMP kernel and BIND9 to measure the response performance using multiple threads. Perhaps this is already well-known, but the result showed using threads with FreeBSD 5.3 didn't improve the performance (rather, it actually degraded the performance as we increased threads/CPUs). In very short, it doesn't make sense to enable threading on FreeBSD in any case (even with multiple CPUs). I'm going to describe what I found in this experience in detail. I hope some of the followings contain new information in order to improve FreeBSD's SMP support in general. - tested environments OS: FreeBSD 5.3 beta 7 and RC1 (I believe the result should be the same with 5.3-RELEASE) Machine: Xeon 700MHz x 4 / Xeon 3000MHz x 4 BIND version: 9.3.0, built with --enable-threads - measurement description named loaded the root zone file (as of around May 2003). I measured the response performance as query-per-second (qps) with the queryperf program (which comes with the BIND9 distributions). queryperf asked various host names which are randomly generated (some of the host names result in NXDOMAIN). All the numbers below show the resulting qps for a 30-second test. - some general observations from the results 1. BIND 9.3.0 does not create worker threads with the PTHREAD_SCOPE_SYSTEM attribute. For FreeBSD, this means different worker threads cannot run on different CPUs, so multi-threading doesn't help anything in terms of performance. 2. generally, BIND9 requires lots of mutex locks to process a single DNS query, causing many lock contentions. The contentions degrade response performance very much. This is true to some extent for any OSes, but lock contentions seem particularly heavy on FreeBSD (see also item 4 below). 3. the SMP support in the kernel generally performs well in terms of UDP input/output on a single socket. However, the kernel uses a giant lock for socket send buffer in the sosend() function, which can be a significant performance bottleneck with high-performance CPUs (the bottleneck was not revealed with 700MHz processors, but did appear with 3000MHz CPUs). It seems to me we can safely avoid the bottleneck for DNS servers, since UDP output does not use socket send buffer. I've made a quick-hack patch in the FreeBSD kernel and confirmed that this is the case. (For those who are particularly interested in this patch, it's available at: http://www.jinmei.org/freebsd5.3-sosend-patch . A new socket option SO_FAST1 on a UDP socket enables the optimization) 4. mutex contentions are VERY expensive (looks like much much more expensive than other OSes), while trying to get a lock without a contention is reasonably cheap. (Almost) whenever a user thread blocks due to a lock contention, it is suspended with a system call (kse_release), probably causing context switch. (I'm not really sure if the system call overhead is the main reason of the performance penalty though.) 5. some standard libraries internally call pthread_mutex_lock(), which can also make the server slow due to the expensive contention tax. Regarding BIND9, malloc() and arc4random() can be a heavy bottleneck (the latter is called for every query if we use the "random" order for RRsets). 6. at least so far, the ULE scheduler doesn't help improve the performance (it even performs worse than the normal 4BSD scheduler). - experiments with possible optimizations Based on the above results, I've explored some optimizations to improve the performance. The first-level optimization is to create worker threads with PTHREAD_SCOPE_SYSTEM and to avoid using malloc(3) in the main part of query processing. Let's call this version "BIND+". I also tried eliminating any possible mutex contentions in the main part of query processing (it depends on some unrealistic assumptions, so we cannot use this code in actual operation). This optimization is called "BIND++". BIND++ also contains the optimizations of BIND+. Additionally, I've made a quick patch to the kernel source code so that sosend() does not lock the socket send buffer for some particular UDP packets. The followings are the test results with these optimizations: A. tests with FreeBSD 5.3 beta 7 on Xeon 700MHz x 4 threads BIND BIND+ BIND++ 0 4818 1 3021 3390 4474 2 1859 2496 7781 3 986 1450 10615 4 774 1167 12668 Note: "BIND" is pure BIND 9.3.0. "0 threads" mean the result without threading. Numbers in the table body show the resulting qps's. While 9.3.0+ ran much better than pure 9.3.0, it still performed quite poorly. However, we can achieve the real benefit of multi-threading/CPUs with BIND++. This result shows if we can control mutex contentions in BIND9 by some realistic way, BIND can run faster on multiple CPUs with FreeBSD. B. tests with FreeBSD 5.3 RC1 on Xeon 3000MHz x 4 threads BIND BIND++ BIND++ 0 16253 kernel_patch 1 7953 14600 14438 2 3591 19840 23854 3 1012 24268 30268 4 533 25447 30434 Note: "BIND++kernel_patch" means BIND++ with the kernel optimization I mentioned in item 3 above. The results show even the full optimization in the application side is not enough with high-speed CPUs. Further kernel optimization can help in this area. The performance was still saturated with around 4 CPUs. I could not figure out the reason at that time. C. (for comparison) SuSE Linux (kernel 2.6.4, glibc 2.3.3) on the same box I used with experiment B threads BIND BIND++ 0 16117 1 13707 17835 2 16493 26946 3 16478 32688 4 14517 36090 While "pure BIND9" does not provide better performance with multiple CPUs either (and the optimizations in BIND++ are equally effective), the penalty with multiple threads is much smaller. I guess this is because Linux handles lock contentions much better than FreeBSD. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 00:05:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F98516A4CE; Wed, 22 Dec 2004 00:05:05 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF66843D1D; Wed, 22 Dec 2004 00:05:04 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iBM022Hg063387; Tue, 21 Dec 2004 19:02:02 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iBM01p6F063382; Wed, 22 Dec 2004 00:02:02 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 22 Dec 2004 00:01:51 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Joe Kelsey In-Reply-To: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: stable@freebsd.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 00:05:05 -0000 On Mon, 13 Dec 2004, Joe Kelsey wrote: > I have a desire to fix posix semaphores in at least 5.3. The current > implementation doesn't actually follow the "spirit" of the standard, > even though it technically qualifies in a somewhat degraded sense. I > refer to the fact that the current implementation treats posix > semaphores as completely contained inside the kernel and essentially > divorced from the filesystem. The true "spirit" of the standard places > the semaphores directly in the file system, similar to named pipes. > However the current implementation treats the supplied "name" as a > 14-character identifier, required to begin with a slash and contain no > other slashes. Pretty weak. > > Well, in order to fix this, we need to add file system code and come up > with a new type. I currently have some time to spend on something like > this and am willing to put in whatever effort it takes. Does anyone > want to add their own ideas or requirements? >From my perspective, the biggest win here is that it would permit different name spaces to trivially exist using multiple mountpoints of a "semfs". This would make it easy to allow applications in different jails to use identical names without colliding. FWIW, my only experience with POSIX semaphores on a system other than FreeBSD is on Darwin, where a similar model is used to that on FreeBSD: a flat kernel-maintained name space is present. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 01:15:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A19A16A4D0 for ; Wed, 22 Dec 2004 01:15:12 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id E976043D1D for ; Wed, 22 Dec 2004 01:15:09 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 2658 invoked from network); 22 Dec 2004 01:15:07 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.118) by gandalf.online.bg with SMTP; 22 Dec 2004 01:15:07 -0000 Received: (qmail 70899 invoked by uid 1000); 22 Dec 2004 01:15:07 -0000 Date: Wed, 22 Dec 2004 03:15:06 +0200 From: Peter Pentchev To: Robert Watson Message-ID: <20041222011506.GG801@straylight.m.ringlet.net> Mail-Followup-To: Robert Watson , Joe Kelsey , arch@freebsd.org, stable@freebsd.org, hackers@freebsd.org, current@freebsd.org References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0qt3EE9wi45a2ZFX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: stable@freebsd.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 01:15:12 -0000 --0qt3EE9wi45a2ZFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 22, 2004 at 12:01:51AM +0000, Robert Watson wrote: >=20 > On Mon, 13 Dec 2004, Joe Kelsey wrote: >=20 > > I have a desire to fix posix semaphores in at least 5.3. The current > > implementation doesn't actually follow the "spirit" of the standard, > > even though it technically qualifies in a somewhat degraded sense. I > > refer to the fact that the current implementation treats posix > > semaphores as completely contained inside the kernel and essentially > > divorced from the filesystem. The true "spirit" of the standard places > > the semaphores directly in the file system, similar to named pipes.=20 > > However the current implementation treats the supplied "name" as a > > 14-character identifier, required to begin with a slash and contain no > > other slashes. Pretty weak.=20 > >=20 > > Well, in order to fix this, we need to add file system code and come up > > with a new type. I currently have some time to spend on something like > > this and am willing to put in whatever effort it takes. Does anyone > > want to add their own ideas or requirements?=20 >=20 > >From my perspective, the biggest win here is that it would permit > different name spaces to trivially exist using multiple mountpoints of a > "semfs". This would make it easy to allow applications in different jails > to use identical names without colliding.=20 >=20 > FWIW, my only experience with POSIX semaphores on a system other than > FreeBSD is on Darwin, where a similar model is used to that on FreeBSD: a > flat kernel-maintained name space is present. I seem to remember either W. Richard Stevens's APUE, or Marc Rochkind's AUP stating that: 1. the standards say that semaphore names ought to have filesystem semantics, but... 2. the standards leave it to the implementation to define whether slashes should be allowed at all except in the first position, so... 3. portable programs should only depend on a flat namespace, especially as... 4. there are widely-used OS's (ISTR Solaris, but ICBW) that only provide a flat namespace. Thus, it would seem that even if somebody would do the work to really tie the semaphore naming fully to the filesystem, still programs that want to be Really Really Portable would not dare use this feature, wonderful as it would be for those that do :( G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? --0qt3EE9wi45a2ZFX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByMqa7Ri2jRYZRVMRAlEPAKDDChgctYLb3u/wxshef1C9gj03kQCfeKv6 fvXZ6UOrvkG0sLS343Rmau0= =Hn9M -----END PGP SIGNATURE----- --0qt3EE9wi45a2ZFX-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 01:27:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7F8716A4CE for ; Wed, 22 Dec 2004 01:27:20 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C8043D54 for ; Wed, 22 Dec 2004 01:27:16 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iBM1QBJH029593 for ; Wed, 22 Dec 2004 11:56:11 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Wed, 22 Dec 2004 11:57:08 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iBM1KkQ32018 for ; Wed, 22 Dec 2004 11:50:46 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK37B55A; Wed, 22 Dec 2004 11:50:44 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iBM1KkEY000961 ; Wed, 22 Dec 2004 11:50:46 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iBM1Kk0u000960; Wed, 22 Dec 2004 11:50:46 +1030 (CST) (envelope-from wilkinsa) Date: Wed, 22 Dec 2004 11:50:46 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20041222012046.GA921@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, matthew.thyer@dsto.defence.gov.au Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: matthew.thyer@dsto.defence.gov.au Subject: [RELENG_5 panic] Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 01:27:21 -0000 upon exec'ing xmms. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0521eed stack pointer = 0x10:0xe5186c38 frame pointer = 0x10:0xe5186c6c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 35 (swi5: clock sio) [thread 100031] Stopped at turnstile_wait+0x269: movl 0x24(%eax),%eax db> show pcpu cpuid = 0 curthread = 0xc26b8190: pid 35 "swi5: clock sio" curpcb = 0xe5186da0 fpcurthread = none idlethread = 0xc26644b0: pid 11 "idle" APIC ID = 0 currentldt = 0x28 db> tr turnstile_wait(0,c06f5ec0,c2b334b0,0,e5186cd4) at turnstile_wait+0x269 _mtx_lock_sleep(c06f5ec0,c26b8190,0,0,0) at _mtx_lock_sleep+0x81 softclock(0,0,0,0,c0685f86) at softclock+0x3b0 ithread_loop(c26d0300,e5186d48,e5186d48,c0685c67,31e) at ithread_loop+0xb7 fork_exit(c04e3db0,c26d0300,e5186d48) at fork_exit+0x64 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe5186d7c, ebp = 0 --- db> - aW From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 02:11:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC74116A4CF for ; Wed, 22 Dec 2004 02:11:56 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17B5B43D55 for ; Wed, 22 Dec 2004 02:11:56 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBM0L1xh080609; Tue, 21 Dec 2004 17:21:02 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41C8BD1C.9090507@freebsd.org> Date: Tue, 21 Dec 2004 17:17:32 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: BIND9 performance issues with SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 02:11:57 -0000 JINMEI Tatuya / 神明達哉 wrote: > Hello, > > I was recently playing with FreeBSD 5.3's SMP kernel and BIND9 to > measure the response performance using multiple threads. Perhaps this > is already well-known, but the result showed using threads with > FreeBSD 5.3 didn't improve the performance (rather, it actually > degraded the performance as we increased threads/CPUs). > > In very short, it doesn't make sense to enable threading on FreeBSD in > any case (even with multiple CPUs). > > I'm going to describe what I found in this experience in detail. I > hope some of the followings contain new information in order to > improve FreeBSD's SMP support in general. > > - tested environments > OS: FreeBSD 5.3 beta 7 and RC1 (I believe the result should be the > same with 5.3-RELEASE) > Machine: Xeon 700MHz x 4 / Xeon 3000MHz x 4 > BIND version: 9.3.0, built with --enable-threads > > - measurement description > named loaded the root zone file (as of around May 2003). I measured > the response performance as query-per-second (qps) with the queryperf > program (which comes with the BIND9 distributions). queryperf asked > various host names which are randomly generated (some of the host > names result in NXDOMAIN). All the numbers below show the resulting > qps for a 30-second test. > > - some general observations from the results > > 1. BIND 9.3.0 does not create worker threads with the > PTHREAD_SCOPE_SYSTEM attribute. For FreeBSD, this means > different worker threads cannot run on different CPUs, so > multi-threading doesn't help anything in terms of performance. This isn't really true. All it means is that each thread will use whatever scheduler activation is available to the UTS at the time instead of having its own dedicated scheduler activation. The whole theory behind SA/KSE is that scheduling threads from the userland should be cheaper than from the kernel, and SA provides the benefit of making more than 1 scheduling resource available to the userland scheduler, unlike libc_r. In practice, it looks like something broke in between 5.2 and 5.3 where process scope threads behave very strangely, almost like the UTS is acting like it only has one scheduling resource to work with. The result is that performance degrades to that of libc_r, except that threads that block in the kernel don't block the whole process. I keep on hoping that Dan or Julian or David will have time to look at this, but that hasn't come to be yet, unfortunately. I'd consider it a very high-priority bug, though. > > 2. generally, BIND9 requires lots of mutex locks to process a single > DNS query, causing many lock contentions. The contentions > degrade response performance very much. This is true to some > extent for any OSes, but lock contentions seem particularly heavy > on FreeBSD (see also item 4 below). > > 3. the SMP support in the kernel generally performs well in terms of > UDP input/output on a single socket. However, the kernel uses a > giant lock for socket send buffer in the sosend() function, which > can be a significant performance bottleneck with high-performance > CPUs (the bottleneck was not revealed with 700MHz processors, but > did appear with 3000MHz CPUs). It seems to me we can safely > avoid the bottleneck for DNS servers, since UDP output does not > use socket send buffer. I've made a quick-hack patch in the > FreeBSD kernel and confirmed that this is the case. (For those > who are particularly interested in this patch, it's available at: > http://www.jinmei.org/freebsd5.3-sosend-patch . > A new socket option SO_FAST1 on a UDP socket enables the > optimization) Very interesting! > > 4. mutex contentions are VERY expensive (looks like much much more > expensive than other OSes), while trying to get a lock without a > contention is reasonably cheap. (Almost) whenever a user thread > blocks due to a lock contention, it is suspended with a system > call (kse_release), probably causing context switch. (I'm not > really sure if the system call overhead is the main reason of the > performance penalty though.) This might be related to what I said above. Where you observing this with process scope or system scope threads? Again, if scheduling decisions are not cheap in the UTS then there really is no point to SA/KSE. > > 5. some standard libraries internally call pthread_mutex_lock(), > which can also make the server slow due to the expensive > contention tax. Regarding BIND9, malloc() and arc4random() can > be a heavy bottleneck (the latter is called for every query if we > use the "random" order for RRsets). > > 6. at least so far, the ULE scheduler doesn't help improve the > performance (it even performs worse than the normal 4BSD > scheduler). With both types of threads? Have you tried Jeff's recent fixes to ULE? Unfortunately we saw similar performance problems over the summer, and that contributed to switching off of the ULE scheduler. Hopefully this situation improves. > > - experiments with possible optimizations > > Based on the above results, I've explored some optimizations to > improve the performance. The first-level optimization is to create > worker threads with PTHREAD_SCOPE_SYSTEM and to avoid using malloc(3) > in the main part of query processing. Let's call this version > "BIND+". I also tried eliminating any possible mutex contentions in > the main part of query processing (it depends on some unrealistic > assumptions, so we cannot use this code in actual operation). This > optimization is called "BIND++". BIND++ also contains the > optimizations of BIND+. Additionally, I've made a quick patch to the > kernel source code so that sosend() does not lock the socket send > buffer for some particular UDP packets. > > The followings are the test results with these optimizations: > > A. tests with FreeBSD 5.3 beta 7 on Xeon 700MHz x 4 > > threads BIND BIND+ BIND++ > 0 4818 > 1 3021 3390 4474 > 2 1859 2496 7781 > 3 986 1450 10615 > 4 774 1167 12668 > > Note: "BIND" is pure BIND 9.3.0. "0 threads" mean the result > without threading. Numbers in the table body show the resulting > qps's. > > While 9.3.0+ ran much better than pure 9.3.0, it still performed > quite poorly. However, we can achieve the real benefit of > multi-threading/CPUs with BIND++. This result shows if we can > control mutex contentions in BIND9 by some realistic way, BIND can > run faster on multiple CPUs with FreeBSD. > > B. tests with FreeBSD 5.3 RC1 on Xeon 3000MHz x 4 > > threads BIND BIND++ BIND++ > 0 16253 kernel_patch > 1 7953 14600 14438 > 2 3591 19840 23854 > 3 1012 24268 30268 > 4 533 25447 30434 > > Note: "BIND++kernel_patch" means BIND++ with the kernel optimization > I mentioned in item 3 above. > > The results show even the full optimization in the application side > is not enough with high-speed CPUs. Further kernel optimization can > help in this area. The performance was still saturated with around > 4 CPUs. I could not figure out the reason at that time. > > C. (for comparison) SuSE Linux (kernel 2.6.4, glibc 2.3.3) on the > same box I used with experiment B > > threads BIND BIND++ > 0 16117 > 1 13707 17835 > 2 16493 26946 > 3 16478 32688 > 4 14517 36090 > > While "pure BIND9" does not provide better performance with multiple > CPUs either (and the optimizations in BIND++ are equally effective), > the penalty with multiple threads is much smaller. I guess this is > because Linux handles lock contentions much better than FreeBSD. > Do you have any comparisons to NetBSD or Solaris? Comparing to Linux often results in comparing apples to oranges since there is long-standing suspicion that Linux cuts corners where BSD does not. Also, would you be able to re-run your tests using the THR thread package? Scott From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 02:11:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5BA416A4CE for ; Wed, 22 Dec 2004 02:11:57 +0000 (GMT) Received: from web4.thecenturiongroup.com (fw14.delivery.com [67.102.42.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA5E943D1D for ; Wed, 22 Dec 2004 02:11:54 +0000 (GMT) (envelope-from mjm@michaelmeltzer.com) Received: from [127.0.0.1] (ix1x1000.thecenturiongroup.com [192.32.248.52]) by web4.thecenturiongroup.com (Postfix) with ESMTP id 1C86A7C00A; Tue, 21 Dec 2004 21:11:52 -0500 (EST) Message-ID: <41C8D740.8060001@michaelmeltzer.com> Date: Tue, 21 Dec 2004 21:09:04 -0500 From: Michael Meltzer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Meltzer References: <41C78F9B.4010804@michaelmeltzer.com> In-Reply-To: <41C78F9B.4010804@michaelmeltzer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: twa driver, 3ware 9500s-4lp, speed issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 02:11:57 -0000 The array is treated as one logical disk, managed by the hardware controller / driver, i.e. /dev/da0. BIOS setup with 4 disks, raid 1 mirrored pairs with raid 0 between the pair(stock 3ware 0+1), 64k strip, write back turned on and 128meg ram. File system ext2 with soft updates was used. The "stock" default setting for newfs as per 5.3, the disk is laid out in the "classical" unix pattern a->root, b->swap, f->var g->usr h->home. the test was run on home so it might be a little slower for inner track issues. Their is no volume manger(i.e vimum, disk suite, etc...), Now the numbers are pretty good(my 3ware 6000s and 7000s max out around 20meg/s on freebsd with older hardware), But this a "hot" controller that I know could do better with some tuning. Ruled out the hardware by using Suse 9.1(disks/pci slots/cabling), but hated yast and 5.3 came out with suport for ADM and the other boxes are freebsd so..... The read-ahead issue has come up for both windows and linux on 3ware support pages, so this seems like a "know" issue. But Alas I failed here. It my fault, I simply do not know what knob to turn. It not helping my ego that my write speed is faster than my read speed, that should not be. -mjm BTW it a database machine with 6gig of ram and the disk speed would be handy, just wanted to mention that before people think "micro benchmark crazy" guy. Michael Meltzer wrote: > I have a 3ware 9500s-4lp controller with 4 10,000rpm raptors hooked up > to it. 0+1 configuration. AMD dual 64 bit processor. > > This Hardware setup had Sese 9.1 running on it for a few days, One on > the issues I had was that the controller seemed "slow". After reading > 3ware white paper for turning for 2.6, the issue seemed to be buffer > read ahead, i.e. blockdev -setra 16384 /dev/sda was needed for any > type of read speed. Some quick benchmark under Bonnie++ Sequential > read speeds from the mid 40's to 105meg/sec and had the write remained > around 98 meg/sec. > > Now the Problem. loaded 5.3 , cvsup'ed and built for freebsd 5.3 > stable, same hardware, the controller is feeling "slow" again. I tried > to play with the vfs prams (vfs.read_max after some googling around). > I could not find much information(other than the handbook) about the > vfs prams and was unable to increase the speed. Can Any one sheed some > light, subjections? insight, Gratefull for any help. > > Her is a iozone report pretty close to the linux bonnie++(sorry the > bonnie failed) to give you all an idea whats up. exect same hardware. > only change was OS and filesystem. Thank You > > MJM > > iozone -s 20480m -r 60 -i 0 -i 1 -t 1 > Iozone: Performance Test of File I/O > Version $Revision: 3.196 $ > Compiled for 64 bit mode. > Build: freebsd > > Contributors:William Norcott, Don Capps, Isom Crawford, Kirby > Collins > Al Slater, Scott Rhine, Mike Wisner, Ken Goss > Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain > CYR, > Randy Dunlap, Mark Montague, Dan Million, > Jean-Marc Zucconi, Jeff Blomberg. > > Run began: Mon Dec 20 21:03:36 2004 > > File size set to 20971520 KB > Record Size 60 KB > Command line used: iozone -s 20480m -r 60 -i 0 -i 1 -t 1 > Output is in Kbytes/sec > Time Resolution = 0.000001 seconds. > Processor cache size set to 1024 Kbytes. > Processor cache line size set to 32 bytes. > File stride size set to 17 * record size. > Throughput test with 1 process > Each process writes a 20971520 Kbyte file in 60 Kbyte records > > Children see throughput for 1 initial writers = 78738.67 > KB/sec > Parent sees throughput for 1 initial writers = 78716.55 > KB/sec > Min throughput per process = 78738.67 > KB/sec > Max throughput per process = 78738.67 > KB/sec > Avg throughput per process = 78738.67 > KB/sec > Min xfer = 20971500.00 KB > > Children see throughput for 1 rewriters = 32126.46 > KB/sec > Parent sees throughput for 1 rewriters = 32125.77 > KB/sec > Min throughput per process = 32126.46 > KB/sec > Max throughput per process = 32126.46 > KB/sec > Avg throughput per process = 32126.46 > KB/sec > Min xfer = 20971500.00 KB > > Children see throughput for 1 readers = 58563.70 > KB/sec > Parent sees throughput for 1 readers = 58557.14 > KB/sec > Min throughput per process = 58563.70 > KB/sec > Max throughput per process = 58563.70 > KB/sec > Avg throughput per process = 58563.70 > KB/sec > Min xfer = 20971500.00 KB > > Children see throughput for 1 re-readers = 58583.77 > KB/sec > Parent sees throughput for 1 re-readers = 58581.98 > KB/sec > Min throughput per process = 58583.77 > KB/sec > Max throughput per process = 58583.77 > KB/sec > Avg throughput per process = 58583.77 > KB/sec > Min xfer = 20971500.00 KB > > > > iozone test complete. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 02:25:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9152916A4CF; Wed, 22 Dec 2004 02:25:38 +0000 (GMT) Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D1A843D1F; Wed, 22 Dec 2004 02:25:38 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 3EDDB37F2A; Wed, 22 Dec 2004 03:25:37 +0100 (CET) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 31A4737E64; Wed, 22 Dec 2004 03:25:37 +0100 (CET) Received: from sentinel (h211n1fls11o822.telia.com [213.64.66.211]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 1407C37E44; Wed, 22 Dec 2004 03:25:37 +0100 (CET) From: "Daniel Eriksson" To: Date: Wed, 22 Dec 2004 03:27:35 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTnzcw4PZQNIXUrQ4GP9VhYWfI2RA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: 'Pawel Jakub Dawidek' Subject: geom_gate panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 02:25:38 -0000 Using geom_gate to mount a geom_stripe array from another machine (hooked up through a crossover cable), the following happens when moving large amounts of data: g_vfs_done():ggate0[WRITE(offset=59507982336, length=131072)]error = 5 ... g_vfs_done():ggate0[WRITE(offset=1119618220032, length=131072)]error = 5 g_vfs_done():ggate0[WRITE(offset=1062713851904, length=16384)]error = 5 g_vfs_done():ggate0[WRITE(offset=1101811367936, length=49152)]error = 5 initiate_write_filepage: already started panic: handle_written_filepage: attached cpuid = 1 KDB: enter: panic [thread pid 3 tid 100044 ] Stopped at kdb_enter+0x32: leave db> tr Tracing pid 3 tid 100044 td 0xc1eb65c0 kdb_enter(c075cb66,1,c07692b8,e06c5c00,0) at kdb_enter+0x32 panic(c07692b8,c07a9d80,46,c1eb65c0,2) at panic+0x1e9 softdep_disk_write_complete(d1872668,246,c1eb65c0,0,e06c5ca0) at softdep_disk_write_complete+0x839 bufdone(d1872668,c1eb65c0,0,0,0) at bufdone+0x2c2 g_vfs_done(c245c000,c07b2f48,24c,c0758cf2,c8) at g_vfs_done+0x69 g_io_schedule_up(c1eb65c0,c1eb91f8,e06c5d34,c0553252,0) at g_io_schedule_up+0x70 g_up_procbody(0,e06c5d48,75003c80,74f73bfa,48a4e10) at g_up_procbody+0x1e fork_exit(c052a2e0,0,e06c5d48) at fork_exit+0x62 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe06c5d7c, ebp = 0 --- Server: FBSD 6-CURRENT, UP, 2004.12.20.16.00.00 Client: FBSD 6-CURRENT, SMP, 2004.12.20.16.00.00 This happens with or without debug.mpsafenet=0. I've seen the same error-messages when mounting a filesystem backed by a normal disc (instead of the geom_stripe used above), but I aborted the file-move before the machine had a chance to panic. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 02:48:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB6D16A4CE for ; Wed, 22 Dec 2004 02:48:36 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E74F43D39 for ; Wed, 22 Dec 2004 02:48:36 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] (pool-68-160-208-232.ny325.east.verizon.net [68.160.208.232]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iBM2mRX7077199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2004 21:48:29 -0500 (EST) Message-ID: <41C8E083.9010909@mac.com> Date: Tue, 21 Dec 2004 21:48:35 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sam@errno.com References: <20041221163907.J46219@pcle2.cc.univie.ac.at> <41C863E1.2070406@errno.com> In-Reply-To: <41C863E1.2070406@errno.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.8 required=5.5 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on pi.codefab.com cc: current@freebsd.org Subject: Re: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 02:48:36 -0000 Sam Leffler wrote: [ ... ] > PS. There is no reason to cc me directly; I read the mailing lists. A solution is available. Go to the bottom of: http://lists.freebsd.org/mailman/options/freebsd-current/sam@errno.com ...and turn the "Avoid duplicate copies of messages?" option on. Mailman has a good color with which to paint the "people who don't want to be CC:ed on list traffic" versus "people who insist on being CC:'ed with messages sent to the list or else they might just ignore that mail!" bikeshed. :-) -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 05:48:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D9A9B16A4CE; Wed, 22 Dec 2004 05:48:04 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id iBM5m348096527; Wed, 22 Dec 2004 00:48:04 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id iBM5m26u096522; Wed, 22 Dec 2004 00:48:02 -0500 (EST) (envelope-from green) Date: Wed, 22 Dec 2004 00:48:02 -0500 From: Brian Fundakowski Feldman To: Scott Long Message-ID: <20041222054802.GE41996@green.homeunix.org> References: <41C8BD1C.9090507@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C8BD1C.9090507@freebsd.org> User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: JINMEI Tatuya Subject: Re: BIND9 performance issues with SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 05:48:05 -0000 On Tue, Dec 21, 2004 at 05:17:32PM -0700, Scott Long wrote: > Do you have any comparisons to NetBSD or Solaris? Comparing to Linux > often results in comparing apples to oranges since there is > long-standing suspicion that Linux cuts corners where BSD does not. > Also, would you be able to re-run your tests using the THR thread > package? Also, shouldn't PTHREAD_MUTEX_NORMAL (_not_ the default in FreeBSD) have possible speed ramifications? I concur with the observation that libpthread generally offers no performance increase over libc_r (whereas linuxthreads very much increases performance). I don't presume to have nearly enough knowledge to contribute meaningfully to the thread libraries or the scheduler, though. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 06:24:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E0E116A4CE; Wed, 22 Dec 2004 06:24:08 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD45843D3F; Wed, 22 Dec 2004 06:24:05 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:b956:5497:3d80:eed6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3E07115210; Wed, 22 Dec 2004 15:24:04 +0900 (JST) Date: Wed, 22 Dec 2004 15:24:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Scott Long In-Reply-To: <41C8BD1C.9090507@freebsd.org> References: <41C8BD1C.9090507@freebsd.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: Re: BIND9 performance issues with SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 06:24:08 -0000 >>>>> On Tue, 21 Dec 2004 17:17:32 -0700, >>>>> Scott Long said: >> 4. mutex contentions are VERY expensive (looks like much much more >> expensive than other OSes), while trying to get a lock without a >> contention is reasonably cheap. (Almost) whenever a user thread >> blocks due to a lock contention, it is suspended with a system >> call (kse_release), probably causing context switch. (I'm not >> really sure if the system call overhead is the main reason of the >> performance penalty though.) > This might be related to what I said above. Where you observing this > with process scope or system scope threads? Again, if scheduling > decisions are not cheap in the UTS then there really is no point to > SA/KSE. I observed this with system scope threads. Note that "BIND+" I showed in my previous message was modified so that it would specify PTHREAD_SCOPE_SYSTEM. Yet this version ran slower as we increased worker threads. >> 6. at least so far, the ULE scheduler doesn't help improve the >> performance (it even performs worse than the normal 4BSD >> scheduler). > With both types of threads? Yes. Here are some results that were not contained in my previous message: #of process system threads scope scope 1 3014 3090 2 3121 3179 3 2254 1922 4 1869 1405 (the tests were on FreeBSD 5.3 beta 7 w/ ULE + Xeon 700MHz x 4) One remarkable difference is that ULE *relatively* improved the results for process scope threads. However, the BIND server still slowed down with multiple threads. That's why I said "ULE doesn't help improve the performance". > Have you tried Jeff's recent fixes to ULE? I'm not sure. My experience with ULE was limited to the beta7 version of FreeBSD 5.3, and I just gave up using it at that stage, having seen everyone in this list said "ULE is broken, don't use it." If beta7 did not contain the fixes you mentioned, I didn't try them. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 08:58:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FE0116A4CE; Wed, 22 Dec 2004 08:58:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A13443D3F; Wed, 22 Dec 2004 08:58:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iBM8tWZe072467; Wed, 22 Dec 2004 03:55:32 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iBM8tWGq072464; Wed, 22 Dec 2004 08:55:32 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 22 Dec 2004 08:55:31 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alan Cox In-Reply-To: <20041220201953.GI1362@cs.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: panic: sbflush_locked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 08:58:41 -0000 On Mon, 20 Dec 2004, Alan Cox wrote: > > I haven't seen this in a very long time, but I've definitely tried to > > track it down before with zero luck. > > With the attached change, I've had no more crashes. > > I speculate uipc_send() is missing needed synchronization on so_snd. > Robert, can you verify the patch? Sorry for the delay in responding to your original post; I'm still catching up with e-mail from my trip to Bangladesh. I actually had similar changes to this in the netperf branch at one point, but think I removed them due to concerns about lock order. However, this change is careful to acquire the send lock before the receive lock, so I think shouldn't present a problem from that perspective. Please go ahead and commit, perhaps with a 2 week MFC time? Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > Index: kern/uipc_usrreq.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_usrreq.c,v > retrieving revision 1.143 > diff -u -r1.143 uipc_usrreq.c > --- kern/uipc_usrreq.c 1 Dec 2004 09:22:26 -0000 1.143 > +++ kern/uipc_usrreq.c 19 Dec 2004 03:22:50 -0000 > @@ -452,7 +452,9 @@ > } > } > > + SOCKBUF_LOCK(&so->so_snd); > if (so->so_snd.sb_state & SBS_CANTSENDMORE) { > + SOCKBUF_UNLOCK(&so->so_snd); > error = EPIPE; > break; > } > @@ -478,6 +480,7 @@ > (so2->so_rcv.sb_cc - unp->unp_conn->unp_cc); > (void)chgsbsize(so->so_cred->cr_uidinfo, &so->so_snd.sb_hiwat, > newhiwat, RLIM_INFINITY); > + SOCKBUF_UNLOCK(&so->so_snd); > unp->unp_conn->unp_cc = so2->so_rcv.sb_cc; > sorwakeup_locked(so2); > m = NULL; From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 09:51:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E93E816A4CE for ; Wed, 22 Dec 2004 09:51:29 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD3B43D3F for ; Wed, 22 Dec 2004 09:51:29 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 9563FACAE0; Wed, 22 Dec 2004 10:51:27 +0100 (CET) Date: Wed, 22 Dec 2004 10:51:27 +0100 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20041222095127.GE787@darkness.comp.waw.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zjcmjzIkjQU2rmur" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-current@freebsd.org Subject: Re: geom_gate panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 09:51:30 -0000 --zjcmjzIkjQU2rmur Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 22, 2004 at 03:27:35AM +0100, Daniel Eriksson wrote: +>=20 +> Using geom_gate to mount a geom_stripe array from another machine (hooke= d up +> through a crossover cable), the following happens when moving large amou= nts +> of data: +>=20 +> g_vfs_done():ggate0[WRITE(offset=3D59507982336, length=3D131072)]error = =3D 5 +> ... +> g_vfs_done():ggate0[WRITE(offset=3D1119618220032, length=3D131072)]error= =3D 5 +> g_vfs_done():ggate0[WRITE(offset=3D1062713851904, length=3D16384)]error = =3D 5 +> g_vfs_done():ggate0[WRITE(offset=3D1101811367936, length=3D49152)]error = =3D 5 Error number 5 is EIO. GGATE can generate such an error in some situations (e.g. queue is full). Please, increase debug level to 1 (kern.geom.gate.debug=3D1) and send me debug printfs from before panic. We can see other serious problem here - UFS cannot handle EIOs properly... --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --zjcmjzIkjQU2rmur Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFByUOfForvXbEpPzQRAh4pAJ40F2YpxU/7EVCbIZZEYVReiqJ6MACeJQZl gOb0L7qxIynxcUfYbTGq3+Q= =69Yb -----END PGP SIGNATURE----- --zjcmjzIkjQU2rmur-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 11:43:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2777216A4CE for ; Wed, 22 Dec 2004 11:43:12 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B88D43D45 for ; Wed, 22 Dec 2004 11:43:11 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.43 (FreeBSD)) id 1Ch4tZ-000GUq-Tt for current@freebsd.org; Wed, 22 Dec 2004 12:43:10 +0100 Date: Wed, 22 Dec 2004 12:43:09 +0100 From: Oliver Brandmueller To: current@freebsd.org Message-ID: <20041222114309.GB39637@e-Gitt.NET> References: <41C78F9B.4010804@michaelmeltzer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C78F9B.4010804@michaelmeltzer.com> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller Subject: Re: twa driver, 3ware 9500s-4lp, speed issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 11:43:12 -0000 Hi. On Mon, Dec 20, 2004 at 09:51:07PM -0500, Michael Meltzer wrote: > I have a 3ware 9500s-4lp controller with 4 10,000rpm raptors hooked up > to it. 0+1 configuration. AMD dual 64 bit processor. We had reproducably very bad experiences with 8500 and 9500 3ware disk controllers in combination with Raptors. After a while (this can be hours or weeks) one of the disks was detached from the RAID ("drive timeout"). You could remove it with tw_cli, when trying to rescan it was not found, until the disk was physically removed or the machine was switched off (only rebooting was not enough): This means the "failed" disk needed to be powercycled. This behaviour has been seen on 6 different machines with either 8500 oder 9500 3ware controllers. The acoustic management of the disks was disabled (this seemed to have caused problems also for other people). The disks were OK, the SMART data showed no damage and it was alsways a random disk failing in the RAIDs. This behaviour seems to only show up in an environment, where you have continuous disk I/O with high stepping rates, such as very loaded mailservers. We switched to the slightly more expensive ICP Vortex controllers in our new machines and will be replacing the old 3wares in the older machines. - The behaviour is _NOT_ seen on servers with less disk I/O. - The behaviour is _NOT_ seen on serevrs with other disks and 3wares. If you ever see a drive timeout in this setup think of this posting. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 12:36:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8F3F16A4CE for ; Wed, 22 Dec 2004 12:36:22 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E14943D2D for ; Wed, 22 Dec 2004 12:36:22 +0000 (GMT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from localhost (localhost [127.0.0.1])70BE849E9F; Wed, 22 Dec 2004 13:36:21 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25122-06-2; Wed, 22 Dec 2004 13:36:20 +0100 (CET) Received: from m2a2.dyndns.org (p54854701.dip.t-dialin.net [84.133.71.1]) 399FB49E7D; Wed, 22 Dec 2004 13:36:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 5EAD2875D9; Wed, 22 Dec 2004 13:36:19 +0100 (CET) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12937-06-2; Wed, 22 Dec 2004 13:36:18 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id A0E00875CE; Wed, 22 Dec 2004 13:36:18 +0100 (CET) From: Matthias Andree To: Oliver Brandmueller In-Reply-To: <20041222114309.GB39637@e-Gitt.NET> (Oliver Brandmueller's message of "Wed, 22 Dec 2004 12:43:09 +0100") References: <41C78F9B.4010804@michaelmeltzer.com> <20041222114309.GB39637@e-Gitt.NET> Date: Wed, 22 Dec 2004 13:36:18 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de cc: current@freebsd.org Subject: Re: twa driver, 3ware 9500s-4lp, speed issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 12:36:23 -0000 Oliver Brandmueller writes: > We had reproducably very bad experiences with 8500 and 9500 3ware disk > controllers in combination with Raptors. After a while (this can be > hours or weeks) one of the disks was detached from the RAID ("drive > timeout"). You could remove it with tw_cli, when trying to rescan it was > not found, until the disk was physically removed or the machine was > switched off (only rebooting was not enough): This means the "failed" > disk needed to be powercycled. I'd probably replace the drives by a different make or at least model; the earlier 36 GB Raptors at any rate - check storagereview.com why. Checking/improving drive cooling may be worthwhile though. > We switched to the slightly more expensive ICP Vortex controllers in our > new machines and will be replacing the old 3wares in the older > machines. Does replacing the adaptor help when the drives lock up? I doubt that. My ancient Micropolis 4345WS drive in a test computer w/ FreeBSD 4.X locks up randomly regardless of the SCSI adaptor (no RAID), I've tried three different chips, Tekram DC-390 (AMD 53C974), DC-390U (SYM53C875), Adaptec 2940UW Pro (AIC 7880) - the problem remains. Must be the drive then in my case. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 15:52:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB5B216A4CE for ; Wed, 22 Dec 2004 15:52:52 +0000 (GMT) Received: from imap.univie.ac.at (mailbox-lmtp.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A409943D41 for ; Wed, 22 Dec 2004 15:52:51 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from korben.prv.univie.ac.at (korben.prv.univie.ac.at [131.130.7.98]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id iBMFqeDm424888; Wed, 22 Dec 2004 16:52:42 +0100 Date: Wed, 22 Dec 2004 16:52:40 +0100 (CET) From: Lukas Ertl To: Sam Leffler In-Reply-To: <20041221191910.J653@korben.prv.univie.ac.at> Message-ID: <20041222165135.L632@korben.prv.univie.ac.at> References: <20041221163907.J46219@pcle2.cc.univie.ac.at> <41C863E1.2070406@errno.com> <20041221191910.J653@korben.prv.univie.ac.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx9.univie.ac.at 4249; Body=2 Fuz1=2 Fuz2=2 cc: current@FreeBSD.org Subject: Re: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 15:52:52 -0000 On Tue, 21 Dec 2004, Lukas Ertl wrote: > I load if_ndis.ko from /boot/loader.conf and configure it with: > > ifconfig ndis0 inet netmask ssid wepmode on wepkey One addition: It works fine if I first set wireless params on the interface, and then in a second step set the IP params. But if I issue just the one command shown above - boom. 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 Wed Dec 22 16:06:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CE1616A4CE for ; Wed, 22 Dec 2004 16:06:58 +0000 (GMT) Received: from web52709.mail.yahoo.com (web52709.mail.yahoo.com [206.190.39.160]) by mx1.FreeBSD.org (Postfix) with SMTP id D352D43D48 for ; Wed, 22 Dec 2004 16:06:56 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 67112 invoked by uid 60001); 22 Dec 2004 16:06:56 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=srtaJajv+uicKRfs4n8XT+PJxg62am5CfAgbFEONFOPbwkP8RZckd4hW3TaIaPuUt4EQ0WvyEdbgXgJ4Elq3uNcRYQ8l+GTpgYQs9bHbCaZVCICiSOK2j/1yB56dCiS0lzTEgDO2dBMjJUg/G8xAV66fZ7iOxOn2R7qTfJNoJM8= ; Message-ID: <20041222160656.67110.qmail@web52709.mail.yahoo.com> Received: from [203.195.199.244] by web52709.mail.yahoo.com via HTTP; Wed, 22 Dec 2004 08:06:56 PST Date: Wed, 22 Dec 2004 08:06:56 -0800 (PST) From: "Kamal R. Prasad" To: Peter Pentchev , Robert Watson In-Reply-To: <20041222011506.GG801@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 22 Dec 2004 16:08:53 +0000 cc: arch@freebsd.org cc: stable@freebsd.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2004 16:06:58 -0000 --- Peter Pentchev wrote: > On Wed, Dec 22, 2004 at 12:01:51AM +0000, Robert > Watson wrote: > > > > On Mon, 13 Dec 2004, Joe Kelsey wrote: > > > > > I have a desire to fix posix semaphores in at > least 5.3. The current > > > implementation doesn't actually follow the > "spirit" of the standard, > > > even though it technically qualifies in a > somewhat degraded sense. I > > > refer to the fact that the current > implementation treats posix > > > semaphores as completely contained inside the > kernel and essentially > > > divorced from the filesystem. The true "spirit" > of the standard places > > > the semaphores directly in the file system, > similar to named pipes. > > > However the current implementation treats the > supplied "name" as a > > > 14-character identifier, required to begin with > a slash and contain no > > > other slashes. Pretty weak. > > > > > > Well, in order to fix this, we need to add file > system code and come up > > > with a new type. I currently have some time to > spend on something like > > > this and am willing to put in whatever effort it > takes. Does anyone > > > want to add their own ideas or requirements? > > > > >From my perspective, the biggest win here is that > it would permit > > different name spaces to trivially exist using > multiple mountpoints of a > > "semfs". This would make it easy to allow > applications in different jails > > to use identical names without colliding. > > > > FWIW, my only experience with POSIX semaphores on > a system other than > > FreeBSD is on Darwin, where a similar model is > used to that on FreeBSD: a > > flat kernel-maintained name space is present. > > I seem to remember either W. Richard Stevens's APUE, > or Marc Rochkind's > AUP stating that: > > 1. the standards say that semaphore names ought to > have filesystem > semantics, but... > 2. the standards leave it to the implementation to > define whether > slashes should be allowed at all except in the > first position, so... But the Posix 1003.1 does require that afully qualified pathname be supported by the interface. > 3. portable programs should only depend on a flat > namespace, > especially as... > 4. there are widely-used OS's (ISTR Solaris, but > ICBW) that only provide > a flat namespace. > > Thus, it would seem that even if somebody would do > the work to really > tie the semaphore naming fully to the filesystem, > still programs that > want to be Really Really Portable would not dare use > this feature, > wonderful as it would be for those that do :( > Well -the issue was about providing support to the interface so that it can handle a fully qualified pathname. If a programmer wants to use a flat namespace to ensure that his program is portable onto other OS'es that don't adhere to the std -that is a different issue [which does not put it in conflict with the std]. BTW -I see no reason why pathnames should be tied to the filesystem, instead of being used simply as identifiers across processes. regards -kamal > G'luck, > Peter > > -- > Peter Pentchev roam@ringlet.net roam@cnsys.bg > roam@FreeBSD.org > PGP key: > http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 > B68D 1619 4553 > What would this sentence be like if pi were 3? > > ATTACHMENT part 2 application/pgp-signature __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 16:09:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59C5516A4CE for ; Wed, 22 Dec 2004 16:09:40 +0000 (GMT) Received: from 9.hellooperator.net (cpc3-cdif2-3-0-cust202.cdif.cable.ntl.com [81.103.32.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id EACEB43D2D for ; Wed, 22 Dec 2004 16:09:39 +0000 (GMT) (envelope-from rasputin@hellooperator.net) Received: from rasputin by 9.hellooperator.net with local (Exim 4.43) id 1Ch93S-0004yp-Ek for freebsd-current@freebsd.org; Wed, 22 Dec 2004 16:09:38 +0000 Date: Wed, 22 Dec 2004 16:09:38 +0000 From: Dick Davies To: FreeBSD Current Users Message-ID: <20041222160938.GH11869@lb.tenfour> References: <20041221163907.J46219@pcle2.cc.univie.ac.at> <41C863E1.2070406@errno.com> <20041221191910.J653@korben.prv.univie.ac.at> <20041222165135.L632@korben.prv.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041222165135.L632@korben.prv.univie.ac.at> User-Agent: Mutt/1.4.2.1i Sender: Dick Davies Subject: Re: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dick Davies List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2004 16:09:40 -0000 * Lukas Ertl [1253 15:53]: > On Tue, 21 Dec 2004, Lukas Ertl wrote: > > >I load if_ndis.ko from /boot/loader.conf and configure it with: > > > >ifconfig ndis0 inet netmask ssid wepmode on wepkey > > One addition: > > It works fine if I first set wireless params on the interface, and then in > a second step set the IP params. But if I issue just the one command > shown above - boom. Thanks for mentioning that, I thought it was just me.... -- 'The old 'give em a Linux box and they think they're Jean-Luc Picard' syndrome.' -- Pete Bentley Rasputin :: Jack of All Trades - Master of Nuns From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 18:05:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62BD016A4CE; Wed, 22 Dec 2004 18:05:34 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FE1743D2F; Wed, 22 Dec 2004 18:05:33 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iBMI5V3H008932; Wed, 22 Dec 2004 19:05:31 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Don Lewis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 18 Dec 2004 23:32:28 PST." <200412190732.iBJ7WSHC066183@gw.catspoiler.org> Date: Wed, 22 Dec 2004 19:05:31 +0100 Message-ID: <8931.1103738731@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: vnode lock assertion violation in devfs_fixup() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 18:05:34 -0000 In message <200412190732.iBJ7WSHC066183@gw.catspoiler.org>, Don Lewis writes: >The vput() call is actually in devfs_fixup(): > > mp->mnt_vnodecovered = vp; > vp->v_mountedhere = mp; > mtx_lock(&mountlist_mtx); > TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); > mtx_unlock(&mountlist_mtx); > VOP_UNLOCK(vp, 0, td); > vfs_unbusy(mp, td); > VREF(vp); >---> vput(vp); > vput(dvp); > >vput() is supposed to be called with the vnode lock held and it releases >the lock, which won't work too well because the vnode was just unlocked >3 lines earlier. vput() also decrements the vnode reference count, but >why are we incrementing the reference count on the line above? I >suspect that the VREF()/vput() sequence should just go away. That sounds like the most likely fix :-) I just tried to faithfully emulate the previous code in all respects and never got around to fix this up. If you can confirm that just removing VREF+vput works, then by all means commit it. -- 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 Wed Dec 22 19:49:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3544D16A4CE for ; Wed, 22 Dec 2004 19:49:47 +0000 (GMT) Received: from mail.snowfall.se (guldivar.globalwire.se [212.112.184.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 597CF43D2F for ; Wed, 22 Dec 2004 19:49:46 +0000 (GMT) (envelope-from stefan@snowfall.se) Received: from [213.136.48.101] (unknown [213.136.48.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.snowfall.se (Postfix) with ESMTP id 706FB2396 for ; Wed, 22 Dec 2004 20:49:44 +0100 (CET) Message-ID: <41C9CFD7.4020303@snowfall.se> Date: Wed, 22 Dec 2004 20:49:43 +0100 From: Stefan Cars 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: Keyboard not working Dell PE 1850 and DRAC cards.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 19:49:47 -0000 Hi! I have some trouble using keyboards (both PS/2 and/or USB) on our 15 new PE 1850's. The installation goes fine (the PS/2 works, USB does not) and single user works OK (with PS/2), but normal boot does not work, it seems it attaches the keyboard to the DRAC cards (it identifies itself as ukbd0). I found a post regarding this (http://lists.freebsd.org/pipermail/freebsd-current/2004-September/038879.html). My question is then, is there anyway I can make this work so I can use a regular keyboard (PS/2 or USB) and the DRAC, maybe by fixing so when i attach a USB it disconnectes the DRAC and attaches the USB ?. Disable the keyboard for the DRAC is something I don't want to do since the reason we bought DRACS to them is the possibility to control them remote, I have some pressure of people wanting us to run RedHat on them and I don't want to be forced to do that becuase of this stupid little thing. Kind Regards, Stefan Cars From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:02:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E2F716A4CE for ; Wed, 22 Dec 2004 20:02:34 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5139743D45 for ; Wed, 22 Dec 2004 20:02:34 +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 iBMK2tlZ024083; Wed, 22 Dec 2004 12:02:55 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBMK2t9r024082; Wed, 22 Dec 2004 12:02:55 -0800 Date: Wed, 22 Dec 2004 12:02:55 -0800 From: Brooks Davis To: Stefan Cars Message-ID: <20041222200255.GB15881@odin.ac.hmc.edu> References: <41C9CFD7.4020303@snowfall.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline In-Reply-To: <41C9CFD7.4020303@snowfall.se> 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: Keyboard not working Dell PE 1850 and DRAC cards.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:02:34 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 22, 2004 at 08:49:43PM +0100, Stefan Cars wrote: > Hi! >=20 > I have some trouble using keyboards (both PS/2 and/or USB) on our 15 new= =20 > PE 1850's. The installation goes fine (the PS/2 works, USB does not) and= =20 > single user works OK (with PS/2), but normal boot does not work, it=20 > seems it attaches the keyboard to the DRAC cards (it identifies itself=20 > as ukbd0). I found a post regarding this=20 > (http://lists.freebsd.org/pipermail/freebsd-current/2004-September/038879= .html).=20 > > My question is then, is there anyway I can make this work so I can use a= =20 > regular keyboard (PS/2 or USB) and the DRAC, maybe by fixing so when i=20 > attach a USB it disconnectes the DRAC and attaches the USB ?. Disable=20 > the keyboard for the DRAC is something I don't want to do since the=20 > reason we bought DRACS to them is the possibility to control them=20 > remote, I have some pressure of people wanting us to run RedHat on them= =20 > and I don't want to be forced to do that becuase of this stupid little=20 > thing. The correct behavior is currently unobtainable, but you may be able to get a sufficent approximation working. At the moment, you'll only be able to use the PS/2 keyboard in single user mode because syscons is going to always pick it and you can't switch unless you have a keyboard or are in multi-user mode. However, in multiuser you can change devd.conf to have a different behavior. It would be fairly simple to make /dev/kbd1 the primary keyboard and have the appearence of ukbd1 cause /dev/kdb2 to become and primary. Hopefully we'll have a real solution soon, but I haven't found the time to work on it as much as I'd 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 --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBydLuXY6L6fI4GtQRAorRAKDQ7h8BxUnZG1KgV6+DaEqzufgZGwCg4txs A2nCaozvEClEcCmxoWir07Y= =P9UU -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:04:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC15A16A4CE for ; Wed, 22 Dec 2004 20:04:46 +0000 (GMT) Received: from mail.snowfall.se (guldivar.globalwire.se [212.112.184.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DEE443D31 for ; Wed, 22 Dec 2004 20:04:46 +0000 (GMT) (envelope-from stefan@snowfall.se) Received: from [213.136.48.101] (unknown [213.136.48.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.snowfall.se (Postfix) with ESMTP id 8A0D723A1; Wed, 22 Dec 2004 21:04:45 +0100 (CET) Message-ID: <41C9D35C.1090408@snowfall.se> Date: Wed, 22 Dec 2004 21:04:44 +0100 From: Stefan Cars User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <41C9CFD7.4020303@snowfall.se> <20041222200255.GB15881@odin.ac.hmc.edu> In-Reply-To: <20041222200255.GB15881@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Keyboard not working Dell PE 1850 and DRAC cards.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:04:46 -0000 Hi! Thanks for the info, where can I find more information on how to do that ? Could you provide an example of how the devd.conf (or what files needed to be changed) would look ? Kind Regards, Stefan Cars Brooks Davis wrote: > On Wed, Dec 22, 2004 at 08:49:43PM +0100, Stefan Cars wrote: > >>Hi! >> >>I have some trouble using keyboards (both PS/2 and/or USB) on our 15 new >>PE 1850's. The installation goes fine (the PS/2 works, USB does not) and >>single user works OK (with PS/2), but normal boot does not work, it >>seems it attaches the keyboard to the DRAC cards (it identifies itself >>as ukbd0). I found a post regarding this >>(http://lists.freebsd.org/pipermail/freebsd-current/2004-September/038879.html). >> >>My question is then, is there anyway I can make this work so I can use a >>regular keyboard (PS/2 or USB) and the DRAC, maybe by fixing so when i >>attach a USB it disconnectes the DRAC and attaches the USB ?. Disable >>the keyboard for the DRAC is something I don't want to do since the >>reason we bought DRACS to them is the possibility to control them >>remote, I have some pressure of people wanting us to run RedHat on them >>and I don't want to be forced to do that becuase of this stupid little >>thing. > > > The correct behavior is currently unobtainable, but you may be able to > get a sufficent approximation working. At the moment, you'll only be > able to use the PS/2 keyboard in single user mode because syscons is > going to always pick it and you can't switch unless you have a keyboard > or are in multi-user mode. However, in multiuser you can change > devd.conf to have a different behavior. It would be fairly simple to > make /dev/kbd1 the primary keyboard and have the appearence of ukbd1 > cause /dev/kdb2 to become and primary. > > Hopefully we'll have a real solution soon, but I haven't found the time > to work on it as much as I'd like. > > -- Brooks > From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:08:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2449116A4CE for ; Wed, 22 Dec 2004 20:08:45 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E853643D1F for ; Wed, 22 Dec 2004 20:08:44 +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 iBMK96CV024503; Wed, 22 Dec 2004 12:09:06 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBMK96Ea024501; Wed, 22 Dec 2004 12:09:06 -0800 Date: Wed, 22 Dec 2004 12:09:06 -0800 From: Brooks Davis To: Stefan Cars Message-ID: <20041222200906.GA24094@odin.ac.hmc.edu> References: <41C9CFD7.4020303@snowfall.se> <20041222200255.GB15881@odin.ac.hmc.edu> <41C9D35C.1090408@snowfall.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <41C9D35C.1090408@snowfall.se> 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: Keyboard not working Dell PE 1850 and DRAC cards.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:08:45 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 22, 2004 at 09:04:44PM +0100, Stefan Cars wrote: > Hi! >=20 > Thanks for the info, where can I find more information on how to do that= =20 > ? Could you provide an example of how the devd.conf (or what files=20 > needed to be changed) would look ? The devd.conf changes should be a fairly simple modification of the existing rules (see "When a USB keyboard arrives") in the file. Mostly changing 1 to 2 and 0 to 1. You'll want to set the rc.conf variable "keyboard" to /dev/kdb1 so it uses the DRAC keyboard by default. -- Brooks >=20 > Kind Regards, > Stefan Cars >=20 >=20 > Brooks Davis wrote: > >On Wed, Dec 22, 2004 at 08:49:43PM +0100, Stefan Cars wrote: > > > >>Hi! > >> > >>I have some trouble using keyboards (both PS/2 and/or USB) on our 15 ne= w=20 > >>PE 1850's. The installation goes fine (the PS/2 works, USB does not) an= d=20 > >>single user works OK (with PS/2), but normal boot does not work, it=20 > >>seems it attaches the keyboard to the DRAC cards (it identifies itself= =20 > >>as ukbd0). I found a post regarding this=20 > >>(http://lists.freebsd.org/pipermail/freebsd-current/2004-September/0388= 79.html).=20 > >> > >>My question is then, is there anyway I can make this work so I can use = a=20 > >>regular keyboard (PS/2 or USB) and the DRAC, maybe by fixing so when i= =20 > >>attach a USB it disconnectes the DRAC and attaches the USB ?. Disable= =20 > >>the keyboard for the DRAC is something I don't want to do since the=20 > >>reason we bought DRACS to them is the possibility to control them=20 > >>remote, I have some pressure of people wanting us to run RedHat on them= =20 > >>and I don't want to be forced to do that becuase of this stupid little= =20 > >>thing. > > > > > >The correct behavior is currently unobtainable, but you may be able to > >get a sufficent approximation working. At the moment, you'll only be > >able to use the PS/2 keyboard in single user mode because syscons is > >going to always pick it and you can't switch unless you have a keyboard > >or are in multi-user mode. However, in multiuser you can change > >devd.conf to have a different behavior. It would be fairly simple to > >make /dev/kbd1 the primary keyboard and have the appearence of ukbd1 > >cause /dev/kdb2 to become and primary. > > > >Hopefully we'll have a real solution soon, but I haven't found the time > >to work on it as much as I'd 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 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBydRhXY6L6fI4GtQRAiObAKDE542WFw0H3qN2yKIPzp2gfImn1ACgu5nZ oft6fTBqBNJuSXjsVU85AfQ= =8CEz -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:11:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54CA116A4CE; Wed, 22 Dec 2004 20:11:07 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7311543D55; Wed, 22 Dec 2004 20:11:06 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) iBMKB66m015729 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2004 21:11:07 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.1/8.12.10/Submit) id iBMKB6pU003464; Wed, 22 Dec 2004 21:11:06 +0100 (MET) Date: Wed, 22 Dec 2004 21:11:06 +0100 From: Daniel Hartmeier To: Peter Holm Message-ID: <20041222201106.GA2090@insomnia.benzedrine.cx> References: <20041220194742.GA89598@peter.osted.lan> <41C73202.1050704@freebsd.org> <20041220210740.GA89881@peter.osted.lan> <41C74110.5040905@freebsd.org> <20041220215231.GA90721@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041220215231.GA90721@peter.osted.lan> User-Agent: Mutt/1.4.1i cc: Andre Oppermann cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:11:07 -0000 On Mon, Dec 20, 2004 at 10:52:31PM +0100, Peter Holm wrote: > > >The tests from http://www.holm.cc/stress/src/stress.tgz > > > > Can you find out which of those test was doing the connect and listen? > > That would be the "net" test. I can't reproduce the problem on today's HEAD. I'm running net.sh in an endless loop on an i386. Did you run the test in a specific way? How reliably can you produce the problem? Daniel From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:16:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9041116A4CE for ; Wed, 22 Dec 2004 20:16:52 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DC4343D2F for ; Wed, 22 Dec 2004 20:16:52 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from [192.168.0.10] (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id iBMKGdXI053135 for ; Wed, 22 Dec 2004 12:16:39 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: current@freebsd.org Date: Wed, 22 Dec 2004 13:15:46 -0700 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412221315.47189.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean Subject: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:16:52 -0000 Hi folks- I'm trying to find out if there is support for integrated nForce2 RAID MCP SATA controller already or planned in the forseeable future. I'm setting up a system with an MSI K7N2 Delta2 Series motherboard. Booting from 5.3-R, the controller is detected as a generic ata controller and runs the disks at UDMA33. I'm actually quite impressed by the hardware even without a specialized driver, but I'd like to know what to expect in terms of support. Thanks! JN From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:22:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E6D716A4CE for ; Wed, 22 Dec 2004 20:22:27 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0463C43D45 for ; Wed, 22 Dec 2004 20:22: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 iBMKMmIQ025527; Wed, 22 Dec 2004 12:22:48 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBMKMmoD025526; Wed, 22 Dec 2004 12:22:48 -0800 Date: Wed, 22 Dec 2004 12:22:48 -0800 From: Brooks Davis To: John Nielsen Message-ID: <20041222202248.GB24094@odin.ac.hmc.edu> References: <200412221315.47189.lists@jnielsen.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <200412221315.47189.lists@jnielsen.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: current@freebsd.org Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:22:27 -0000 --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 22, 2004 at 01:15:46PM -0700, John Nielsen wrote: > Hi folks- >=20 > I'm trying to find out if there is support for integrated nForce2 RAID MC= P=20 > SATA controller already or planned in the forseeable future. >=20 > I'm setting up a system with an MSI K7N2 Delta2 Series motherboard. Boot= ing=20 > from 5.3-R, the controller is detected as a generic ata controller and ru= ns=20 > the disks at UDMA33. I'm actually quite impressed by the hardware even= =20 > without a specialized driver, but I'd like to know what to expect in term= s=20 > of support. This RAID controler requires a software RAID implementation. We do support the necessicary RAID functionality, but apparently we don't support the meta data used by your BIOS. All your average onboard RAID system does is allow you to boot from a mirror or strip. Once you're booted, it's up to the OS to read the geometry data from the disks and proceed with software RAID support. Since there's no standard for the on-disk metadata, we only support those systems were we've managed to pry the data out of the manufacture or reverse engineer the format. -- 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 --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBydeXXY6L6fI4GtQRAnRnAKDnrX/M4SguUDOg0wwP0WAAWBZIzQCdEWtg QaFUzxAIN9WKKdTxtZUSJpE= =zJfb -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:34:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7B5F16A4CE; Wed, 22 Dec 2004 20:34:38 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9036D43D1D; Wed, 22 Dec 2004 20:34:36 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 0A2A34A9AE; Wed, 22 Dec 2004 14:34:36 -0600 (CST) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 31683-01-73; Wed, 22 Dec 2004 14:34:35 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id A54434A9A7; Wed, 22 Dec 2004 14:34:35 -0600 (CST) Date: Wed, 22 Dec 2004 14:34:35 -0600 From: Alan Cox To: Robert Watson Message-ID: <20041222203435.GN1362@cs.rice.edu> References: <20041220201953.GI1362@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: current@freebsd.org Subject: Re: panic: sbflush_locked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:34:38 -0000 On Wed, Dec 22, 2004 at 08:55:31AM +0000, Robert Watson wrote: > > On Mon, 20 Dec 2004, Alan Cox wrote: > > > > I haven't seen this in a very long time, but I've definitely tried to > > > track it down before with zero luck. > > > > With the attached change, I've had no more crashes. > > > > I speculate uipc_send() is missing needed synchronization on so_snd. > > Robert, can you verify the patch? > > Sorry for the delay in responding to your original post; I'm still > catching up with e-mail from my trip to Bangladesh. I actually had > similar changes to this in the netperf branch at one point, but think I > removed them due to concerns about lock order. However, this change is > careful to acquire the send lock before the receive lock, so I think > shouldn't present a problem from that perspective. Please go ahead and > commit, perhaps with a 2 week MFC time? I just committed the patch. Thanks for the review. Alan From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 20:45:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F8B616A4CE for ; Wed, 22 Dec 2004 20:45:37 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 1136243D55 for ; Wed, 22 Dec 2004 20:45:37 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 17818 invoked from network); 22 Dec 2004 20:45:35 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 22 Dec 2004 20:45:35 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBMKjY9H027933; Wed, 22 Dec 2004 21:45:34 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBMKjYhL027932; Wed, 22 Dec 2004 21:45:34 +0100 (CET) (envelope-from pho) Date: Wed, 22 Dec 2004 21:45:34 +0100 From: Peter Holm To: Daniel Hartmeier Message-ID: <20041222204534.GA27894@peter.osted.lan> References: <20041220194742.GA89598@peter.osted.lan> <41C73202.1050704@freebsd.org> <20041220210740.GA89881@peter.osted.lan> <41C74110.5040905@freebsd.org> <20041220215231.GA90721@peter.osted.lan> <20041222201106.GA2090@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041222201106.GA2090@insomnia.benzedrine.cx> User-Agent: Mutt/1.4.2.1i cc: Andre Oppermann cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 20:45:37 -0000 On Wed, Dec 22, 2004 at 09:11:06PM +0100, Daniel Hartmeier wrote: > On Mon, Dec 20, 2004 at 10:52:31PM +0100, Peter Holm wrote: > > > > >The tests from http://www.holm.cc/stress/src/stress.tgz > > > > > > Can you find out which of those test was doing the connect and listen? > > > > That would be the "net" test. > > I can't reproduce the problem on today's HEAD. I'm running net.sh in an > endless loop on an i386. Did you run the test in a specific way? How > reliably can you produce the problem? > > Daniel I have only seen this problem once. I run all of the tests via the run.sh script. -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 21:02:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3070416A4CE; Wed, 22 Dec 2004 21:02:56 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F148943D54; Wed, 22 Dec 2004 21:02:55 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id iBML2t7t013354; Wed, 22 Dec 2004 13:02:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Dec 2004 13:02:54 -0800 Message-ID: <00CDF9AA240E204FA6E923BD35BC643607C4803C@bcs-mail.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP URG point Thread-Index: AcToaZs4rj1zYtFcRASeS3QwS8Onyg== From: "Li, Qing" To: , X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 Subject: TCP URG point X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 21:02:56 -0000 It appears the TCP urgent pointer is off by 1. In RFC-1122, section 4.2.2.4 on Page 83 describes the urgent pointer error in RFC-793. The 6.0-CURRENT code has the urgent pointer set to (LAST+1). Any comments before I sent a PR ? -- Qing From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 21:05:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC2FA16A4CE for ; Wed, 22 Dec 2004 21:05:56 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E62343D49 for ; Wed, 22 Dec 2004 21:05:56 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 22702 invoked from network); 22 Dec 2004 21:05:54 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 22 Dec 2004 21:05:54 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBML5sno028129; Wed, 22 Dec 2004 22:05:54 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBML5rvp028128; Wed, 22 Dec 2004 22:05:53 +0100 (CET) (envelope-from pho) Date: Wed, 22 Dec 2004 22:05:53 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20041222210553.GA28108@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041220234103.GA59225@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 21:05:57 -0000 On Mon, Dec 20, 2004 at 06:41:04PM -0500, Bosko Milekic wrote: > > I realize it's been a while. > > Anyway, what I *think* is going on here is that slab_zalloc() is > actually returning NULL even when called with M_WAITOK. Further > inspection in slab_zalloc() reveals that this could come from several > places. One of them is kmem_malloc() itself, which I doubt will ever > return NULL if called with M_WAITOK. If this assumption is indeed > correct, then the NULL must be being returned by slab_zalloc() itself, > or due to a failed uma_zalloc_internal() call. It is also possible > that slab_zalloc() returns NULL if the init that gets called for the > zone fails. However, judging from the stack trace you provided, the > init in question is mb_init_pack() (kern_mbuf.c). This particular > init DOES perform an allocation and CAN in theory fail, but I believe > it should be called with M_WAITOK as well, and so it should also never > fail in theory. > > Have you gotten any further with the analysis of this particular > trace? If not, I would suggest adding some more printf()s and > analysis into slab_zalloc() itself, to see if that is indeed what is > causing the infinite looping in uma_zone_slab() and, if so, attempt to > figure out what part of slab_zalloc() is returning the NULL. OK, did that: http://www.holm.cc/stress/log/freeze03.html > > Happy Holidays, > -Bosko > > On Thu, Dec 09, 2004 at 03:42:33PM +0100, Peter Holm wrote: > > I modified: > > > > $ cvs diff -u uma_core.c > > Index: uma_core.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > > retrieving revision 1.110 > > diff -u -r1.110 uma_core.c > > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > > +++ uma_core.c 9 Dec 2004 14:38:32 -0000 > > @@ -1926,6 +1926,7 @@ > > { > > uma_slab_t slab; > > uma_keg_t keg; > > + int i; > > > > keg = zone->uz_keg; > > > > @@ -1943,7 +1944,8 @@ > > > > slab = NULL; > > > > - for (;;) { > > + for (i = 0;;i++) { > > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > > /* > > * Find a slab with some space. Prefer slabs that are partially > > * used over those that are totally full. This helps to reduce > > > > > > and caught this one: > > http://www.holm.cc/stress/log/cons94.html > > -- > > Peter Holm > > _______________________________________________ > > 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" > > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 21:11:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A7116A4CE for ; Wed, 22 Dec 2004 21:11:01 +0000 (GMT) Received: from mail.snowfall.se (guldivar.globalwire.se [212.112.184.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB14943D39 for ; Wed, 22 Dec 2004 21:11:00 +0000 (GMT) (envelope-from stefan@snowfall.se) Received: from [213.136.48.101] (unknown [213.136.48.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.snowfall.se (Postfix) with ESMTP id CC1C6231B for ; Wed, 22 Dec 2004 22:10:58 +0100 (CET) Message-ID: <41C9E2DF.8010405@snowfall.se> Date: Wed, 22 Dec 2004 22:10:55 +0100 From: Stefan Cars User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41C9CFD7.4020303@snowfall.se> <20041222200255.GB15881@odin.ac.hmc.edu> <41C9D35C.1090408@snowfall.se> <20041222200906.GA24094@odin.ac.hmc.edu> In-Reply-To: <20041222200906.GA24094@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: MegaRAID management X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 21:11:01 -0000 Hi! Thanks, that worked well. Going to another issue then. Does anyone know if there is any support for some management of the MegaRAID (perc 4e/Si)in FreeBSD ? Kind Regards, Stefan Cars Brooks Davis wrote: > On Wed, Dec 22, 2004 at 09:04:44PM +0100, Stefan Cars wrote: > >>Hi! >> >>Thanks for the info, where can I find more information on how to do that >>? Could you provide an example of how the devd.conf (or what files >>needed to be changed) would look ? > > > The devd.conf changes should be a fairly simple modification of the > existing rules (see "When a USB keyboard arrives") in the file. Mostly > changing 1 to 2 and 0 to 1. You'll want to set the rc.conf variable > "keyboard" to /dev/kdb1 so it uses the DRAC keyboard by default. > > -- Brooks > > >>Kind Regards, >>Stefan Cars >> >> >>Brooks Davis wrote: >> >>>On Wed, Dec 22, 2004 at 08:49:43PM +0100, Stefan Cars wrote: >>> >>> >>>>Hi! >>>> >>>>I have some trouble using keyboards (both PS/2 and/or USB) on our 15 new >>>>PE 1850's. The installation goes fine (the PS/2 works, USB does not) and >>>>single user works OK (with PS/2), but normal boot does not work, it >>>>seems it attaches the keyboard to the DRAC cards (it identifies itself >>>>as ukbd0). I found a post regarding this >>>>(http://lists.freebsd.org/pipermail/freebsd-current/2004-September/038879.html). >>>> >>>>My question is then, is there anyway I can make this work so I can use a >>>>regular keyboard (PS/2 or USB) and the DRAC, maybe by fixing so when i >>>>attach a USB it disconnectes the DRAC and attaches the USB ?. Disable >>>>the keyboard for the DRAC is something I don't want to do since the >>>>reason we bought DRACS to them is the possibility to control them >>>>remote, I have some pressure of people wanting us to run RedHat on them >>>>and I don't want to be forced to do that becuase of this stupid little >>>>thing. >>> >>> >>>The correct behavior is currently unobtainable, but you may be able to >>>get a sufficent approximation working. At the moment, you'll only be >>>able to use the PS/2 keyboard in single user mode because syscons is >>>going to always pick it and you can't switch unless you have a keyboard >>>or are in multi-user mode. However, in multiuser you can change >>>devd.conf to have a different behavior. It would be fairly simple to >>>make /dev/kbd1 the primary keyboard and have the appearence of ukbd1 >>>cause /dev/kdb2 to become and primary. >>> >>>Hopefully we'll have a real solution soon, but I haven't found the time >>>to work on it as much as I'd like. >>> >>>-- Brooks >>> From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 21:14:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AEE316A4CE for ; Wed, 22 Dec 2004 21:14:44 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6783F43D5E for ; Wed, 22 Dec 2004 21:14:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 54F497A457; Wed, 22 Dec 2004 13:14:44 -0800 (PST) Message-ID: <41C9E3C4.8090201@elischer.org> Date: Wed, 22 Dec 2004 13:14:44 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Michael Meltzer References: <41C78F9B.4010804@michaelmeltzer.com> <41C8D740.8060001@michaelmeltzer.com> In-Reply-To: <41C8D740.8060001@michaelmeltzer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: twa driver, 3ware 9500s-4lp, speed issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 21:14:44 -0000 Michael Meltzer wrote: > > BTW it a database machine with 6gig of ram and the disk speed would be > handy, just wanted to mention that before people think "micro > benchmark crazy" guy. Does the driver do bounce bufferring for >4GB? Is it faster if you only have 2GB of ram turned on? From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 21:15:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C243916A4CE for ; Wed, 22 Dec 2004 21:15:52 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1537343D48 for ; Wed, 22 Dec 2004 21:15:52 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 255 invoked from network); 22 Dec 2004 21:03:13 -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 ; 22 Dec 2004 21:03:13 -0000 Message-ID: <41C9E437.5040309@freebsd.org> Date: Wed, 22 Dec 2004 22:16:39 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Li, Qing" References: <00CDF9AA240E204FA6E923BD35BC643607C4803C@bcs-mail.internal.cacheflow.com> In-Reply-To: <00CDF9AA240E204FA6E923BD35BC643607C4803C@bcs-mail.internal.cacheflow.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: TCP URG point X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 21:15:52 -0000 Li, Qing wrote: > It appears the TCP urgent pointer is off by 1. > > In RFC-1122, section 4.2.2.4 on Page 83 describes the > urgent pointer error in RFC-793. > > The 6.0-CURRENT code has the urgent pointer set > to (LAST+1). > > Any comments before I sent a PR ? No, please do and send me the PR number. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 22:15:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1824816A4CE for ; Wed, 22 Dec 2004 22:15:44 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8232D43D1F for ; Wed, 22 Dec 2004 22:15:43 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBMMFemH080075; Wed, 22 Dec 2004 17:15:40 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBMMFeTl080074; Wed, 22 Dec 2004 17:15:40 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Wed, 22 Dec 2004 17:15:40 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041222221540.GA70052@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041222210553.GA28108@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 22:15:44 -0000 On Wed, Dec 22, 2004 at 10:05:53PM +0100, Peter Holm wrote: > On Mon, Dec 20, 2004 at 06:41:04PM -0500, Bosko Milekic wrote: > > > > I realize it's been a while. > > > > Anyway, what I *think* is going on here is that slab_zalloc() is > > actually returning NULL even when called with M_WAITOK. Further > > inspection in slab_zalloc() reveals that this could come from several > > places. One of them is kmem_malloc() itself, which I doubt will ever > > return NULL if called with M_WAITOK. If this assumption is indeed > > correct, then the NULL must be being returned by slab_zalloc() itself, > > or due to a failed uma_zalloc_internal() call. It is also possible > > that slab_zalloc() returns NULL if the init that gets called for the > > zone fails. However, judging from the stack trace you provided, the > > init in question is mb_init_pack() (kern_mbuf.c). This particular > > init DOES perform an allocation and CAN in theory fail, but I believe > > it should be called with M_WAITOK as well, and so it should also never > > fail in theory. > > > > Have you gotten any further with the analysis of this particular > > trace? If not, I would suggest adding some more printf()s and > > analysis into slab_zalloc() itself, to see if that is indeed what is > > causing the infinite looping in uma_zone_slab() and, if so, attempt to > > figure out what part of slab_zalloc() is returning the NULL. > > OK, did that: http://www.holm.cc/stress/log/freeze03.html OK, well, I think I know what's happening. See if you can confirm this with me. I'll start with your trace and describe the analysis, please bear with me because it's long and painful. Your trace indicates that the NULL allocation failure, despite a call with M_WAITOK, is coming from slab_zalloc(). The particular thing that should also be mentionned about this trace, and your previous one, is that they both show a call path that goes through an init which performs an allocation, also with M_WAITOK. Currently, only the "packet zone" does this. It looks something like this: 1. UMA allocation is performed for a "packet." A "packet" is an mbuf with a pre-attached cluster. 2. UMA dips into the packet zone and finds it empty. Additionally, it determines that it is unable to get a bucket to fill up the zone (presumably there is a lot of memory request load). So it calls uma_zalloc_internal on the packet zone (frame 18). 3. Perhaps after some blocking, a slab is obtained from the packet zone's backing keg (which coincidentally is the same keg as the mbuf zone's backing keg -- let's call it the MBUF KEG). So now that an mbuf item is taken from the freshly allocated slab obtained from the MBUF KEG, uma_zalloc_internal() needs to init and ctor it, since it is about to return it to the top (calling) layer. It calls the initializer on it for the packet zone, mbuf_init_pack(). This corresponds to frame 17. 4. The packet zone's initializer needs to call into UMA again to get and attach an mbuf cluster to the mbuf being allocated, because mbufs residing within the packet zone (or obtained from the packet zone) MUST have clusters attached to them. It attempts to perform this allocation with M_WAITOK, because that's what the initial caller was calling with. This is frame 16. 5. Now the cluster zone is also completely empty and we can't get a bucket (surprise, surprise, the system is under high memory-request load). UMA calls uma_zalloc_internal() on the cluster zone as well. This is frame 15. 6. uma_zalloc_internal() calls uma_zone_slab(). Its job is to find a slab from the cluster zone's backing keg (a separate CLUSTER KEG) and return it. Unfortunately, memory-request load is high, so it's going to have a difficult time. The uma_zone_slab() call is frame 14. 7. uma_zone_slab() can't find a locally cached slab (hardly surprising, due to load) and calls slab_zalloc() to actually go to VM and get one. Before calling, it increments a special "recurse" flag so that we do not recurse on calling into the VM. This is because the VM itself might call back into UMA when it attempts to allocate vm_map_entries which could cause it to recurse on allocating buckets. This recurse flag is PER zone, and really only exists to protect the bucket zone. Crazy, crazy shit indeed. Pardon the language. This is frame 13. 8. Now slab_zalloc(), called for the CLUSTER zone, determines that the cluster zone (for space efficiency reasons) is in fact an OFFPAGE zone, so it needs to grab a slab header structure from a separate UMA "slab header" zone. It calls uma_zalloc_internal() from slab_zalloc(), but it calls it on the SLAB HEADER zone. It passes M_WAITOK down to it, but for some reason IT returns NULL and the failure is propagated back up which causes the uma_zone_slab() to keep looping. Go back to step 7. This is the infinite loop 7 -> 8 -> 7 -> 8 -> ... which you seem to have caught. The question now is why does the uma_zalloc_internal() fail on the SLAB HEADER zone, even though it is called with M_WAITOK. Unfortunately, your stack trace does not provide enough depth to be able to continue an accurate deductive analysis from this point on (you would need to sprinkle MORE KASSERTs). However, here are some hypotheses. The uma_zalloc_internal() which ends up getting called also ends up calling uma_zone_slab(), but uma_zone_slab() eventually fails (this is a fact, this is the only reason that the uma_zalloc_internal() could in turn fail for the SLAB HEADER zone, which doesn't have an init or a ctor). So why does the uma_zone_slab() fail with M_WAITOK on the slab header zone? Possibilities: 1. The recurse flag is at some point determined non-zero FOR THE SLAB HEADER backing keg. If the VM ends up getting called from the subsequent slab_zalloc() and ends up calling back into UMA for whatever allocations, and "whatever allocations" are also potentially offpage, and a slab header is ALSO required, then we could also be recursing on the slab header zone from VM, so this could cause the failure. if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { /* ADD PRINTF HERE */ printf("This zone: %s, forced fail due to recurse non-null", zone->uz_name); return NULL; } If you get the print to trigger right before the panic (last one before the panic), see if it is on the SLAB HEADER zone. In theory, it should only happen for the BUCKET ZONE. 2. M_WAITOK really isn't set. Unlikely. If (1) is really happening, we'll need to think about it a little more before deciding how to fix it. As you can see, due to the recursive nature of UMA/VM, things can get really tough when resources are scarce. Regards, -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 01:47:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB26E16A4CE for ; Thu, 23 Dec 2004 01:47:58 +0000 (GMT) Received: from bombadil.mebtel.net (bombadil.mebtel.net [64.40.67.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E21643D2D for ; Thu, 23 Dec 2004 01:47:58 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from localhost (localhost [127.0.0.1]) by bombadil.mebtel.net (Postfix) with ESMTP id 97B3C20854B; Wed, 22 Dec 2004 20:47:57 -0500 (EST) Received: from bombadil.mebtel.net ([127.0.0.1]) by localhost (bombadil [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21377-08; Wed, 22 Dec 2004 20:47:57 -0500 (EST) Received: from lorne.arm.org (66-79-79-176.dsl.mebtel.net [66.79.79.176]) by bombadil.mebtel.net (Postfix) with ESMTP id EB345208516; Wed, 22 Dec 2004 20:47:56 -0500 (EST) Received: from lorne.arm.org (localhost [127.0.0.1]) by lorne.arm.org (8.13.1/8.13.1) with ESMTP id iBN1lwfI025876; Wed, 22 Dec 2004 20:47:58 -0500 (EST) (envelope-from dlt@lorne.arm.org) Received: (from dlt@localhost) by lorne.arm.org (8.13.1/8.13.1/Submit) id iBN1lwbn025873; Wed, 22 Dec 2004 20:47:58 -0500 (EST) (envelope-from dlt) Date: Wed, 22 Dec 2004 20:47:58 -0500 (EST) Message-Id: <200412230147.iBN1lwbn025873@lorne.arm.org> From: Derek Tattersall To: X-Virus-Scanned: by amavisd-new at mebtel.net cc: current@FreeBSD.org Subject: Re: Buildworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dlt@mebtel.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 01:47:59 -0000 On Wed. 22 Dec 2004, Doug White wrote: >On Sun, 19 Dec 2004, Derek Tattersall wrote: > >> I have rebuilt current last Sunday and today. Last Sunday, buildworld >> failed with default make.conf. I found it would build with CFLAGS=-O >> -pipe . It failed building insn-attrtab with an internal compiler >> error. > >This is most likely bad hardware or cooling. You noted that you aren't >running overclocked, but is your CPU cooler and case air circulation >sufficient? buildworld generates a LOT of CPU load and therefore heat. >You might try installing the mbmon port (or whatever is appropriate for >your system) or watching hw.acpi.thermal if your system registers thermal >zones. > >> Today, after cvsup'ing this morning, it would not build with default >> make.conf. Switching to the above CFLAGS, it fails building >> c_common.c with the same internal compiler error. >> /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c: In function ` >> c_common_nodes_and_builtins': >> /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:3465: internal >> compiler error: in control_flow_insn_p, at cfgbuild.c:130 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See > >> I have not submitted a report to gcc because I am not confident that >> this is really a compiler problem. >> >> Before last week, buildworld worked (or didn't) quite >> straightforwardly. This problem has me completely baffled. >> >> Hardware is ASUS A7V with AMD Athlon XP 2800+. It seems like vanilla >> hardware. Memtest86 run for 1-2 hours shows no problems with the >> memory. The CPU is not overclocked, (1650 Mhz). 1 gig of Crucial >> pc2700 memory. >> >> > >-- >Doug White | FreeBSD: The Power to Serve >dwhite@gumbysoft.com | www.FreeBSD.org Thanks, Doug. It appears to be an overheating problem. Now where did I put that extra fan... -- Derek Tattersall | "She is descended from a long line that her mother | listened to." -- Gypsy Rose Lee dlt@mebtel.net | | dlt666@yahoo.com | From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 01:48:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A07C716A4D0; Thu, 23 Dec 2004 01:48:11 +0000 (GMT) Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C45A43D53; Thu, 23 Dec 2004 01:48:11 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out006.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041223014810.LRNK7873.out006.verizon.net@RabbitsDen>; Wed, 22 Dec 2004 19:48:10 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Lukas Ertl In-Reply-To: <20041222165135.L632@korben.prv.univie.ac.at> References: <20041221163907.J46219@pcle2.cc.univie.ac.at> <20041221191910.J653@korben.prv.univie.ac.at> <20041222165135.L632@korben.prv.univie.ac.at> Content-Type: text/plain; charset=iso-8859-5 Date: Wed, 22 Dec 2004 20:47:51 -0500 Message-Id: <1103766471.947.6.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out006.verizon.net from [70.21.161.195] at Wed, 22 Dec 2004 19:48:09 -0600 cc: Sam Leffler cc: current@FreeBSD.org Subject: Re: WLAN, WEP, if_ndis on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 01:48:11 -0000 On Wed, 2004-12-22 at 16:52 +0100, Lukas Ertl wrote: > On Tue, 21 Dec 2004, Lukas Ertl wrote: > > > I load if_ndis.ko from /boot/loader.conf and configure it with: > > > > ifconfig ndis0 inet netmask ssid wepmode on wepkey > > One addition: > > It works fine if I first set wireless params on the interface, and then in > a second step set the IP params. But if I issue just the one command > shown above - boom. > > cheers, > le > I have ndis driven (Broadcom-based Belkin F5D7010) card working with -current as of December 17. Only difference in command line is ifconfig ... weptxkey 1 wlan and wlan_wep are compiled in. if_ndis is the module. HTH, -- Alexandre "Sunny" Kovalenko (žŰŐÚáĐÝÔŕ şŢŇĐŰŐÝÚŢ) From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 02:31:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99FB616A4CE for ; Thu, 23 Dec 2004 02:31:52 +0000 (GMT) Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17BAB43D31 for ; Thu, 23 Dec 2004 02:31:52 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.30.50]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041223022950.ILGV16431.lakermmtao05.cox.net@dolphin.local.net> for ; Wed, 22 Dec 2004 21:29:50 -0500 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id iBN2TkVM089060 for ; Wed, 22 Dec 2004 20:29:46 -0600 (CST) (envelope-from conrads@cox.net) Date: Wed, 22 Dec 2004 20:29:41 -0600 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-ID: <20041222202941.79ea15a6@dolphin.local.net> In-Reply-To: <20041221055157.5bf808ff@dolphin.local.net> References: <20041221055157.5bf808ff@dolphin.local.net> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: NFS flakiness since @ last Friday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 02:31:52 -0000 On Tue, 21 Dec 2004 05:51:57 -0600, "Conrad J. Sabatier" wrote: > I'm seeing some real instability in NFS since approximately last > Friday. Intermittently, I'm seeing messages such as the following: > > On the client machine: > > Dec 20 23:18:22 dolphin kernel: impossible packet length (1820291) > from nfs server gateway:/mm > Dec 21 00:51:47 dolphin kernel: impossible packet length (1746474142) > from nfs server gateway:/mm > > and > > Dec 21 01:14:41 dolphin kernel: nfs send error 35 for server > gateway:/mm Dec 21 01:16:33 dolphin kernel: nfs send error 35 for > server gateway:/mm Dec 21 01:16:38 dolphin kernel: nfs send error 35 > for server gateway:/mm Dec 21 01:16:40 dolphin kernel: nfs server > gateway:/mm: not responding Dec 21 01:16:43 dolphin kernel: nfs server > gateway:/mm: is alive again > > On the server machine: > > Dec 20 21:52:48 gateway kernel: nfsd send error 32 > Dec 20 21:57:50 gateway kernel: nfsd send error 32 > Dec 20 22:00:45 gateway kernel: nfsd send error 32 > Dec 20 22:23:29 gateway kernel: nfsd send error 32 > Dec 20 23:18:23 gateway kernel: nfsd send error 32 > > Then, ultimately, all NFS communication just breaks down > altogether until a reboot. > > I'm also seeing "sillyrenames" left behind occasionally in nfs-mounted > directories. > > There were a couple of nfs-related commits last Thursday, which I > believe are most likely the culprit, although I don't know which ones > exactly. I do believe this problem is related to the new direct i/o mode for nfs. Disabling it seems to have made the problem disappear. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 02:44:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DE5D16A4CE for ; Thu, 23 Dec 2004 02:44:14 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4392F43D39 for ; Thu, 23 Dec 2004 02:44:14 +0000 (GMT) (envelope-from mikore.li@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so41809rne for ; Wed, 22 Dec 2004 18:44:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=exIL3G/HGLgmJ/rqSH1HIP2KiiqvmiR65l1jTSPWv6HecpTz644CE4VLIfVK29rX8MpVCd13KH8BsMbIeuQdY7cjA9xBCcZvTgVcQgLhoI4ar/13TRu38OlBT10doBx2JlC5G83ZU4vqGtbuRi3F6gtmoWW48DDgBAPJ5hMSsgk= Received: by 10.38.207.65 with SMTP id e65mr5748rng; Wed, 22 Dec 2004 18:44:13 -0800 (PST) Received: by 10.38.22.72 with HTTP; Wed, 22 Dec 2004 18:44:13 -0800 (PST) Message-ID: Date: Thu, 23 Dec 2004 10:44:13 +0800 From: Mikore Li To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Try installation of freebsd 5.3.0 on ferrari3400(AMD64 based laptop), failed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mikore Li List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 02:44:14 -0000 Can freebsd work on this model of laptop or desktop? Thanks From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 03:49:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEAE516A4CE for ; Thu, 23 Dec 2004 03:49:27 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id A135143D1F for ; Thu, 23 Dec 2004 03:49:27 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from [192.168.0.10] (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id iBN3nQXI024465 for ; Wed, 22 Dec 2004 19:49:27 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Wed, 22 Dec 2004 20:48:31 -0700 User-Agent: KMail/1.7.2 References: <200412221315.47189.lists@jnielsen.net> <20041222202248.GB24094@odin.ac.hmc.edu> In-Reply-To: <20041222202248.GB24094@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412222048.32037.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 03:49:28 -0000 On Wednesday 22 December 2004 01:22 pm, Brooks Davis wrote: > On Wed, Dec 22, 2004 at 01:15:46PM -0700, John Nielsen wrote: > > Hi folks- > > > > I'm trying to find out if there is support for integrated nForce2 RAID > > MCP SATA controller already or planned in the forseeable future. > > > > I'm setting up a system with an MSI K7N2 Delta2 Series motherboard. > > Booting from 5.3-R, the controller is detected as a generic ata > > controller and runs the disks at UDMA33. I'm actually quite impressed > > by the hardware even without a specialized driver, but I'd like to know > > what to expect in terms of support. > > This RAID controler requires a software RAID implementation. We do > support the necessicary RAID functionality, but apparently we don't > support the meta data used by your BIOS. All your average onboard RAID > system does is allow you to boot from a mirror or strip. Once you're > booted, it's up to the OS to read the geometry data from the disks and > proceed with software RAID support. Since there's no standard for the > on-disk metadata, we only support those systems were we've managed to > pry the data out of the manufacture or reverse engineer the format. That's understandable. I don't have an immediate need for RAID support though. What would be needed to simply have the controller recognized and able to support UDMA 150 (or even 133)? JN From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 03:58:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEAE616A4CE; Thu, 23 Dec 2004 03:58:23 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CAC643D41; Thu, 23 Dec 2004 03:58:23 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBN41ub2086401; Wed, 22 Dec 2004 21:01:57 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41CA4240.3050605@freebsd.org> Date: Wed, 22 Dec 2004 20:57:52 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: "current@freebsd.org" Subject: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 03:58:24 -0000 Got this while trying to build a kernel from today's sources in /sys/i386/compile/. I assume that we are still allowed to build kernels in this way, yes? ===> aic7xxx (all) ===> aic7xxx/aicasm (all) make: don't know how to make aicasm.1. Stop *** Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 04:25:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35EBE16A4CE; Thu, 23 Dec 2004 04:25:43 +0000 (GMT) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01AB443D1D; Thu, 23 Dec 2004 04:25:43 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) (192.168.1.2) by mail.ambrisko.com with ESMTP; 22 Dec 2004 20:25:42 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id iBN4PgL8032458; Wed, 22 Dec 2004 20:25:42 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id iBN4Pg8O032457; Wed, 22 Dec 2004 20:25:42 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200412230425.iBN4Pg8O032457@ambrisko.com> In-Reply-To: <41CA4240.3050605@freebsd.org> To: Scott Long Date: Wed, 22 Dec 2004 20:25:42 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: "current@freebsd.org" Subject: Re: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 04:25:43 -0000 Scott Long writes: | Got this while trying to build a kernel from today's sources in | /sys/i386/compile/. I assume that we are still allowed | to build kernels in this way, yes? | | ===> aic7xxx (all) | ===> aic7xxx/aicasm (all) | make: don't know how to make aicasm.1. Stop I ran into that as well. I added NOMAN= 1 to my sys/modules/aic7xxx/aicasm/Makefile locally here. Now I can build the modules again. Doug A. From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 04:27:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80A0416A4CE for ; Thu, 23 Dec 2004 04:27:29 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F2FD43D49 for ; Thu, 23 Dec 2004 04:27:27 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iBN4QLVn025703 for ; Thu, 23 Dec 2004 14:56:21 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Thu, 23 Dec 2004 14:57:17 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iBN4O0Q07427 for ; Thu, 23 Dec 2004 14:54:00 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK37D6BK; Thu, 23 Dec 2004 14:53:56 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iBN4O4Rj005428 for ; Thu, 23 Dec 2004 14:54:04 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iBN4O4dr005427 for freebsd-current@freebsd.org; Thu, 23 Dec 2004 14:54:04 +1030 (CST) (envelope-from wilkinsa) Date: Thu, 23 Dec 2004 14:54:04 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20041223042404.GB5393@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20041221055157.5bf808ff@dolphin.local.net> <20041222202941.79ea15a6@dolphin.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20041222202941.79ea15a6@dolphin.local.net> User-Agent: Mutt/1.5.6i Subject: Re: NFS flakiness since @ last Friday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 04:27:29 -0000 0n Wed, Dec 22, 2004 at 08:29:41PM -0600, Conrad J. Sabatier wrote: >On Tue, 21 Dec 2004 05:51:57 -0600, "Conrad J. Sabatier" > wrote: > >> I'm seeing some real instability in NFS since approximately last >> Friday. Intermittently, I'm seeing messages such as the following: >> >> On the client machine: >> >> Dec 20 23:18:22 dolphin kernel: impossible packet length (1820291) >> from nfs server gateway:/mm >> Dec 21 00:51:47 dolphin kernel: impossible packet length (1746474142) >> from nfs server gateway:/mm >> >> and >> >> Dec 21 01:14:41 dolphin kernel: nfs send error 35 for server >> gateway:/mm Dec 21 01:16:33 dolphin kernel: nfs send error 35 for >> server gateway:/mm Dec 21 01:16:38 dolphin kernel: nfs send error 35 >> for server gateway:/mm Dec 21 01:16:40 dolphin kernel: nfs server >> gateway:/mm: not responding Dec 21 01:16:43 dolphin kernel: nfs server >> gateway:/mm: is alive again >> >> On the server machine: >> >> Dec 20 21:52:48 gateway kernel: nfsd send error 32 >> Dec 20 21:57:50 gateway kernel: nfsd send error 32 >> Dec 20 22:00:45 gateway kernel: nfsd send error 32 >> Dec 20 22:23:29 gateway kernel: nfsd send error 32 >> Dec 20 23:18:23 gateway kernel: nfsd send error 32 >> >> Then, ultimately, all NFS communication just breaks down >> altogether until a reboot. >> >> I'm also seeing "sillyrenames" left behind occasionally in nfs-mounted >> directories. >> >> There were a couple of nfs-related commits last Thursday, which I >> believe are most likely the culprit, although I don't know which ones >> exactly. > >I do believe this problem is related to the new direct i/o mode for nfs. >Disabling it seems to have made the problem disappear. What is the "new direct i/o mode for nfs" all about ? - aW From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 05:31:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E879A16A4D2 for ; Thu, 23 Dec 2004 05:31:17 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D5243D2D for ; Thu, 23 Dec 2004 05:31:06 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBN5THGx029983; Wed, 22 Dec 2004 22:29:21 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Dec 2004 22:29:40 -0700 (MST) Message-Id: <20041222.222940.21578569.imp@bsdimp.com> To: rushani@bl.mmtr.or.jp From: "M. Warner Losh" In-Reply-To: <20041220.174608.63062245.rushani@bl.mmtr.or.jp> References: <20041218141228.GA65853@spot.0xfce3.net> <20041220.174608.63062245.rushani@bl.mmtr.or.jp> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: gbergling@0xfce3.net cc: freebsd-current@freebsd.org Subject: Re: [PATCH] add missing device id for pccard bridge O2Micro OZ711M1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 05:31:18 -0000 In message: <20041220.174608.63062245.rushani@bl.mmtr.or.jp> Hideyuki KURASHINA writes: : I suggest you sending a PR so that our PCI-CardBus Bridge maintainer : can track your change. Already committed, but generally excellent advise. Warner From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 06:08:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D264316A4CE for ; Thu, 23 Dec 2004 06:08:28 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A10D743D2D for ; Thu, 23 Dec 2004 06:08:28 +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 iBN68sIf029485; Wed, 22 Dec 2004 22:08:54 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iBN68sb1029484; Wed, 22 Dec 2004 22:08:54 -0800 Date: Wed, 22 Dec 2004 22:08:54 -0800 From: Brooks Davis To: John Nielsen Message-ID: <20041223060854.GB28133@odin.ac.hmc.edu> References: <200412221315.47189.lists@jnielsen.net> <20041222202248.GB24094@odin.ac.hmc.edu> <200412222048.32037.lists@jnielsen.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DBIVS5p969aUjpLe" Content-Disposition: inline In-Reply-To: <200412222048.32037.lists@jnielsen.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 Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 06:08:28 -0000 --DBIVS5p969aUjpLe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 22, 2004 at 08:48:31PM -0700, John Nielsen wrote: > On Wednesday 22 December 2004 01:22 pm, Brooks Davis wrote: > > On Wed, Dec 22, 2004 at 01:15:46PM -0700, John Nielsen wrote: > > > Hi folks- > > > > > > I'm trying to find out if there is support for integrated nForce2 RAID > > > MCP SATA controller already or planned in the forseeable future. > > > > > > I'm setting up a system with an MSI K7N2 Delta2 Series motherboard.= =20 > > > Booting from 5.3-R, the controller is detected as a generic ata > > > controller and runs the disks at UDMA33. I'm actually quite impressed > > > by the hardware even without a specialized driver, but I'd like to kn= ow > > > what to expect in terms of support. > > > > This RAID controler requires a software RAID implementation. We do > > support the necessicary RAID functionality, but apparently we don't > > support the meta data used by your BIOS. All your average onboard RAID > > system does is allow you to boot from a mirror or strip. Once you're > > booted, it's up to the OS to read the geometry data from the disks and > > proceed with software RAID support. Since there's no standard for the > > on-disk metadata, we only support those systems were we've managed to > > pry the data out of the manufacture or reverse engineer the format. >=20 > That's understandable. I don't have an immediate need for RAID support= =20 > though. What would be needed to simply have the controller recognized an= d=20 > able to support UDMA 150 (or even 133)? At least in current, there's an nForce2 MCP device id that is supposed to support UDMA6 so I suspect you may just need to wait a bit and it will arrive. It's possiable you have a board with a non-standard PCI-id. You might make sure "pciconf -lv" shows that your controler shows a device ID of 0x008510de. If not, you may be a simple matter of adding it to the necessicary two lines. -- 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 --DBIVS5p969aUjpLe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBymD2XY6L6fI4GtQRAjm9AJ4mRMRwGDrCGJWxLtRsDTGjN9oeWwCeMDe9 aCnL6cJGCALCY08iVrfiNfg= =+gBc -----END PGP SIGNATURE----- --DBIVS5p969aUjpLe-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 06:20:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A01AF16A4CE for ; Thu, 23 Dec 2004 06:20:33 +0000 (GMT) Received: from sbk-gw.sibnet.ru (sbk-gw.sibnet.ru [217.70.96.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id C996F43D55 for ; Thu, 23 Dec 2004 06:20:23 +0000 (GMT) (envelope-from stranger@sberbank.sibnet.ru) Received: from sbk-gw.sibnet.ru (localhost [127.0.0.1]) by sbk-gw.sibnet.ru (8.13.1/8.13.1) with ESMTP id iBN6Jxo7021841; Thu, 23 Dec 2004 12:19:59 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) Received: from localhost (stranger@localhost)iBN6JxOR021838; Thu, 23 Dec 2004 12:19:59 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) X-Authentication-Warning: sbk-gw.sibnet.ru: stranger owned process doing -bs Date: Thu, 23 Dec 2004 12:19:58 +0600 (NOVT) From: "Maxim M. Kazachek" X-X-Sender: stranger@sbk-gw.sibnet.ru To: Brooks Davis In-Reply-To: <20041223060854.GB28133@odin.ac.hmc.edu> Message-ID: <20041223121128.G21793@sbk-gw.sibnet.ru> References: <200412221315.47189.lists@jnielsen.net> <20041222202248.GB24094@odin.ac.hmc.edu> <20041223060854.GB28133@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.8 required=7.5 tests=ALL_TRUSTED,AWL,BAYES_20 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on sbk-gw.sibnet.ru cc: freebsd-current@freebsd.org cc: John Nielsen Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 06:20:33 -0000 MCP 2 doesn't have ANY SATA support. MCP have 6ch codec, 2xATA133, 6xUSB2, 100Mbps ethernet, 6xPCI. MCP-T also have IEEE1394, SoundStorm support (I'm afraid it still unsupported, just 6ch codec too) and the interface for second 100Mbps ethernet (3COM). No SATA at all... Usually motherboard manufacturers add SATA controller (Silicon, etc) that allows to implement SATA support. Some puts GigE chip. But usually you need to pay a fee - one or more available PCI slots. Sincerely, Maxim M. Kazachek mailto:stranger@sberbank.sibnet.ru mailto:stranger@fpm.ami.nstu.ru On Wed, 22 Dec 2004, Brooks Davis wrote: > On Wed, Dec 22, 2004 at 08:48:31PM -0700, John Nielsen wrote: >> On Wednesday 22 December 2004 01:22 pm, Brooks Davis wrote: >>> On Wed, Dec 22, 2004 at 01:15:46PM -0700, John Nielsen wrote: >>>> Hi folks- >>>> >>>> I'm trying to find out if there is support for integrated nForce2 RAID >>>> MCP SATA controller already or planned in the forseeable future. >>>> >>>> I'm setting up a system with an MSI K7N2 Delta2 Series motherboard. >>>> Booting from 5.3-R, the controller is detected as a generic ata >>>> controller and runs the disks at UDMA33. I'm actually quite impressed >>>> by the hardware even without a specialized driver, but I'd like to know >>>> what to expect in terms of support. >>> >>> This RAID controler requires a software RAID implementation. We do >>> support the necessicary RAID functionality, but apparently we don't >>> support the meta data used by your BIOS. All your average onboard RAID >>> system does is allow you to boot from a mirror or strip. Once you're >>> booted, it's up to the OS to read the geometry data from the disks and >>> proceed with software RAID support. Since there's no standard for the >>> on-disk metadata, we only support those systems were we've managed to >>> pry the data out of the manufacture or reverse engineer the format. >> >> That's understandable. I don't have an immediate need for RAID support >> though. What would be needed to simply have the controller recognized and >> able to support UDMA 150 (or even 133)? > > At least in current, there's an nForce2 MCP device id that is supposed > to support UDMA6 so I suspect you may just need to wait a bit and it > will arrive. It's possiable you have a board with a non-standard > PCI-id. You might make sure "pciconf -lv" shows that your controler > shows a device ID of 0x008510de. If not, you may be a simple matter of > adding it to the necessicary two lines. > > -- Brooks > > -- > 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 > From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 06:32:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84DBB16A4CE for ; Thu, 23 Dec 2004 06:32:19 +0000 (GMT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A99943D45 for ; Thu, 23 Dec 2004 06:32:19 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao02.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041223063212.LLPA2202.lakermmtao02.cox.net@mezz.mezzweb.com>; Thu, 23 Dec 2004 01:32:12 -0500 Date: Thu, 23 Dec 2004 00:32:53 -0600 To: "Maxim M. Kazachek" References: <200412221315.47189.lists@jnielsen.net> <20041222202248.GB24094@odin.ac.hmc.edu> <20041223060854.GB28133@odin.ac.hmc.edu> <20041223121128.G21793@sbk-gw.sibnet.ru> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20041223121128.G21793@sbk-gw.sibnet.ru> User-Agent: Opera M2/7.54u1 (Linux, build 892) cc: John Nielsen cc: current@freebsd.org Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 06:32:19 -0000 On Thu, 23 Dec 2004 12:19:58 +0600 (NOVT), Maxim M. Kazachek wrote: > MCP 2 doesn't have ANY SATA support. MCP have 6ch codec, 2xATA133, I have the same (maybe, mine is 7N2 Delta2 Platinum) motherboard as his and it does has SATA support. Mine SATA is disabled in BIOS, which I don't have any SATA HD. http://www.msicomputer.com/product/p_spec.asp?model=K7N2_Delta2_Platinum&class=mb ===================================== ? nVIDIA nForce2 Gigabit MCP Chipset - Integrated Ethernet MAC - Integrated Hardware Sound Blaster/Direct Sound AC97 audio - Ultra DMA 66/100/133 master mode PCI EIDE controller - Supports USB 2.0 - Integrated SATA Interface ===================================== Cheers, Mezz > 6xUSB2, 100Mbps ethernet, 6xPCI. MCP-T also have IEEE1394, SoundStorm > support (I'm afraid it still unsupported, just 6ch codec too) and the > interface for second 100Mbps ethernet (3COM). No SATA at all... Usually > motherboard manufacturers add SATA controller (Silicon, etc) that allows > to implement SATA support. Some puts GigE chip. But usually you need to > pay a fee - one or more available PCI slots. > > Sincerely, Maxim M. Kazachek > mailto:stranger@sberbank.sibnet.ru > mailto:stranger@fpm.ami.nstu.ru > > > On Wed, 22 Dec 2004, Brooks Davis wrote: > >> On Wed, Dec 22, 2004 at 08:48:31PM -0700, John Nielsen wrote: >>> On Wednesday 22 December 2004 01:22 pm, Brooks Davis wrote: >>>> On Wed, Dec 22, 2004 at 01:15:46PM -0700, John Nielsen wrote: >>>>> Hi folks- >>>>> >>>>> I'm trying to find out if there is support for integrated nForce2 >>>>> RAID >>>>> MCP SATA controller already or planned in the forseeable future. >>>>> >>>>> I'm setting up a system with an MSI K7N2 Delta2 Series motherboard. >>>>> Booting from 5.3-R, the controller is detected as a generic ata >>>>> controller and runs the disks at UDMA33. I'm actually quite >>>>> impressed >>>>> by the hardware even without a specialized driver, but I'd like to >>>>> know >>>>> what to expect in terms of support. >>>> >>>> This RAID controler requires a software RAID implementation. We do >>>> support the necessicary RAID functionality, but apparently we don't >>>> support the meta data used by your BIOS. All your average onboard >>>> RAID >>>> system does is allow you to boot from a mirror or strip. Once you're >>>> booted, it's up to the OS to read the geometry data from the disks and >>>> proceed with software RAID support. Since there's no standard for the >>>> on-disk metadata, we only support those systems were we've managed to >>>> pry the data out of the manufacture or reverse engineer the format. >>> >>> That's understandable. I don't have an immediate need for RAID support >>> though. What would be needed to simply have the controller recognized >>> and >>> able to support UDMA 150 (or even 133)? >> >> At least in current, there's an nForce2 MCP device id that is supposed >> to support UDMA6 so I suspect you may just need to wait a bit and it >> will arrive. It's possiable you have a board with a non-standard >> PCI-id. You might make sure "pciconf -lv" shows that your controler >> shows a device ID of 0x008510de. If not, you may be a simple matter of >> adding it to the necessicary two lines. >> >> -- Brooks >> >> -- 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 >> -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 06:40:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE06A16A4E5; Thu, 23 Dec 2004 06:40:25 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6BE643D45; Thu, 23 Dec 2004 06:40:16 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBN6eEbX012378; Thu, 23 Dec 2004 08:40:15 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 40806-02; Thu, 23 Dec 2004 08:40:14 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBN6eDaJ012375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Dec 2004 08:40:14 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBN6eLE0081898; Thu, 23 Dec 2004 08:40:21 +0200 (EET) (envelope-from ru) Date: Thu, 23 Dec 2004 08:40:20 +0200 From: Ruslan Ermilov To: Scott Long Message-ID: <20041223064020.GA81788@ip.net.ua> References: <41CA4240.3050605@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <41CA4240.3050605@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@freebsd.org Subject: Re: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 06:40:26 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Scott, On Wed, Dec 22, 2004 at 08:57:52PM -0700, Scott Long wrote: > Got this while trying to build a kernel from today's sources in > /sys/i386/compile/. I assume that we are still allowed > to build kernels in this way, yes? >=20 > =3D=3D=3D> aic7xxx (all) > =3D=3D=3D> aic7xxx/aicasm (all) > make: don't know how to make aicasm.1. Stop > *** Error code 2 > 1 error >=20 We never guarantee this. What we guarantee though, is that you'll be able to build your kernel through this sequence: make buildworld make buildkernel This takes care of upgrade issues. In this case, the upgrade issue is that sys/dev/aic7xxx/aicasm/Makefile relies on the new spelling of NO_MAN, and you still have your /usr/share/mk filled with the old stuff. Two options: 1. You follow the supported upgrade path above, which is also documented in src/UPDATING (COMMON ITEMS, "To build a kernel"). 2. You follow "To just build a kernel when you know that it won't mess you up" also from src/UPDATING, after manually updating your /usr/share/mk: cd /usr/src/share/mk make install Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBymhUqRfpzJluFF4RAupiAJ0eoa/eKI5GxmULy0FScbKCWtui9wCfTq9F ISSLsNAGsY3jdmJCR5CYbc4= =Waed -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 07:44:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AC2116A4CE for ; Thu, 23 Dec 2004 07:44:49 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58EF743D39 for ; Thu, 23 Dec 2004 07:44:48 +0000 (GMT) (envelope-from ed@stack.nl) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mailhost.stack.nl (Postfix) with ESMTP id 677221F0BD; Thu, 23 Dec 2004 08:44:47 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1830) id 534CA1E230; Thu, 23 Dec 2004 08:44:47 +0100 (CET) Date: Thu, 23 Dec 2004 08:44:47 +0100 From: Ed Schouten To: Mikore Li Message-ID: <20041223074447.GC57052@il.fontys.nl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bAmEntskrkuBymla" Content-Disposition: inline In-Reply-To: X-Message-Flag: Have you mooed today? User-Agent: Mutt/1.5.6i cc: FreeBSD Current Subject: Re: Try installation of freebsd 5.3.0 on ferrari3400(AMD64 based laptop), failed. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 07:44:49 -0000 --bAmEntskrkuBymla Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Mikore, Mikore Li wrote: > Can freebsd work on this model of laptop or desktop? Could you give us more output, like startup logs (dmesg)? Yours sincerely, --=20 _________________=20 / Ed Schouten \ \ ed@il.fontys.nl / -----------------=20 \ ,__, \ (oo)____ (__) )\ ||--|| * --bAmEntskrkuBymla Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByndvyx16ydahrz4RAmWtAJ9LRx9VI9/9n619qLc33RzTv2UZcgCg2Lxs dXDVwerQB7YCeBvqdrKbW5k= =vzO7 -----END PGP SIGNATURE----- --bAmEntskrkuBymla-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 10:30:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F6A416A4CE for ; Thu, 23 Dec 2004 10:30:06 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 4CC5743D46 for ; Thu, 23 Dec 2004 10:30:05 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 27657 invoked from network); 23 Dec 2004 10:17:29 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 23 Dec 2004 10:17:29 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBNAHS1U035023; Thu, 23 Dec 2004 11:17:28 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBNAHSGc035022; Thu, 23 Dec 2004 11:17:28 +0100 (CET) (envelope-from pho) Date: Thu, 23 Dec 2004 11:17:27 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20041223101727.GA34943@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041222221540.GA70052@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 10:30:06 -0000 On Wed, Dec 22, 2004 at 05:15:40PM -0500, Bosko Milekic wrote: > > On Wed, Dec 22, 2004 at 10:05:53PM +0100, Peter Holm wrote: > > On Mon, Dec 20, 2004 at 06:41:04PM -0500, Bosko Milekic wrote: > > > > > > I realize it's been a while. > > > > > > Anyway, what I *think* is going on here is that slab_zalloc() is > > > actually returning NULL even when called with M_WAITOK. Further > > > inspection in slab_zalloc() reveals that this could come from several > > > places. One of them is kmem_malloc() itself, which I doubt will ever > > > return NULL if called with M_WAITOK. If this assumption is indeed > > > correct, then the NULL must be being returned by slab_zalloc() itself, > > > or due to a failed uma_zalloc_internal() call. It is also possible > > > that slab_zalloc() returns NULL if the init that gets called for the > > > zone fails. However, judging from the stack trace you provided, the > > > init in question is mb_init_pack() (kern_mbuf.c). This particular > > > init DOES perform an allocation and CAN in theory fail, but I believe > > > it should be called with M_WAITOK as well, and so it should also never > > > fail in theory. > > > > > > Have you gotten any further with the analysis of this particular > > > trace? If not, I would suggest adding some more printf()s and > > > analysis into slab_zalloc() itself, to see if that is indeed what is > > > causing the infinite looping in uma_zone_slab() and, if so, attempt to > > > figure out what part of slab_zalloc() is returning the NULL. > > > > OK, did that: http://www.holm.cc/stress/log/freeze03.html > > OK, well, I think I know what's happening. See if you can confirm > this with me. > > I'll start with your trace and describe the analysis, please bear with > me because it's long and painful. > > Your trace indicates that the NULL allocation failure, despite a call > with M_WAITOK, is coming from slab_zalloc(). The particular thing > that should also be mentionned about this trace, and your previous > one, is that they both show a call path that goes through an init > which performs an allocation, also with M_WAITOK. Currently, only the > "packet zone" does this. It looks something like this: > > 1. UMA allocation is performed for a "packet." A "packet" is an mbuf > with a pre-attached cluster. > > 2. UMA dips into the packet zone and finds it empty. Additionally, it > determines that it is unable to get a bucket to fill up the zone > (presumably there is a lot of memory request load). So it calls > uma_zalloc_internal on the packet zone (frame 18). > > 3. Perhaps after some blocking, a slab is obtained from the packet > zone's backing keg (which coincidentally is the same keg as the > mbuf zone's backing keg -- let's call it the MBUF KEG). So now > that an mbuf item is taken from the freshly allocated slab obtained > from the MBUF KEG, uma_zalloc_internal() needs to init and ctor it, > since it is about to return it to the top (calling) layer. It > calls the initializer on it for the packet zone, mbuf_init_pack(). > This corresponds to frame 17. > > 4. The packet zone's initializer needs to call into UMA again to get > and attach an mbuf cluster to the mbuf being allocated, because mbufs > residing within the packet zone (or obtained from the packet zone) > MUST have clusters attached to them. It attempts to perform this > allocation with M_WAITOK, because that's what the initial caller > was calling with. This is frame 16. > > 5. Now the cluster zone is also completely empty and we can't get a > bucket (surprise, surprise, the system is under high memory-request > load). UMA calls uma_zalloc_internal() on the cluster zone as well. > This is frame 15. > > 6. uma_zalloc_internal() calls uma_zone_slab(). Its job is to find a > slab from the cluster zone's backing keg (a separate CLUSTER KEG) > and return it. Unfortunately, memory-request load is high, so it's > going to have a difficult time. The uma_zone_slab() call is frame > 14. > > 7. uma_zone_slab() can't find a locally cached slab (hardly > surprising, due to load) and calls slab_zalloc() to actually go to > VM and get one. Before calling, it increments a special "recurse" > flag so that we do not recurse on calling into the VM. This is > because the VM itself might call back into UMA when it attempts to > allocate vm_map_entries which could cause it to recurse on > allocating buckets. This recurse flag is PER zone, and really only > exists to protect the bucket zone. Crazy, crazy shit indeed. > Pardon the language. This is frame 13. > > 8. Now slab_zalloc(), called for the CLUSTER zone, determines that the > cluster zone (for space efficiency reasons) is in fact an OFFPAGE > zone, so it needs to grab a slab header structure from a separate > UMA "slab header" zone. It calls uma_zalloc_internal() from > slab_zalloc(), but it calls it on the SLAB HEADER zone. It passes > M_WAITOK down to it, but for some reason IT returns NULL and the > failure is propagated back up which causes the uma_zone_slab() to > keep looping. Go back to step 7. > > This is the infinite loop 7 -> 8 -> 7 -> 8 -> ... which you seem to > have caught. > > The question now is why does the uma_zalloc_internal() fail on the > SLAB HEADER zone, even though it is called with M_WAITOK. > Unfortunately, your stack trace does not provide enough depth to be > able to continue an accurate deductive analysis from this point on > (you would need to sprinkle MORE KASSERTs). > > However, here are some hypotheses. > > The uma_zalloc_internal() which ends up getting called also ends up > calling uma_zone_slab(), but uma_zone_slab() eventually fails (this is > a fact, this is the only reason that the uma_zalloc_internal() could > in turn fail for the SLAB HEADER zone, which doesn't have an init or a > ctor). > > So why does the uma_zone_slab() fail with M_WAITOK on the slab header > zone? Possibilities: > > 1. The recurse flag is at some point determined non-zero FOR THE SLAB > HEADER backing keg. If the VM ends up getting called from the > subsequent slab_zalloc() and ends up calling back into UMA for > whatever allocations, and "whatever allocations" are also > potentially offpage, and a slab header is ALSO required, then we > could also be recursing on the slab header zone from VM, so this > could cause the failure. > > if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) { > /* ADD PRINTF HERE */ > printf("This zone: %s, forced fail due to recurse non-null", > zone->uz_name); > return NULL; > } > The printf didn't really fly. It seems to be called early in boot: ck_flags(0,0,c07e8890,882) at _mtx_lock_flags+0x24 uma_zalloc_internal(c09284a0,c0c20c84,2) at uma_zalloc_internal+0x2d uma_zcreate(c07e8b1e,40,0,0,0,0,3,2000) at uma_zcreate+0x57 uma_startup(c103d000,c103d000,28000,c0c20d78,ff00000) at uma_startup+0x2ae vm_page_startup(c1065000,c0c20d98,c05ec857,0,c08525d0) at vm_page_startup+0x109 vm_mem_init(0,c08525d0,c1ec00,c1e000,c28000) at vm_mem_init+0x13 mi_startup() at mi_startup+0xb3 begin() at begin+0x2c so I just sprinkled some more asserts. I'm trying to see if I can provoke this problem more consistently, based on your analysis. It usually takes me a day or two of testing to get there. > If you get the print to trigger right before the panic (last one > before the panic), see if it is on the SLAB HEADER zone. In > theory, it should only happen for the BUCKET ZONE. > > 2. M_WAITOK really isn't set. Unlikely. > > If (1) is really happening, we'll need to think about it a little more > before deciding how to fix it. As you can see, due to the recursive > nature of UMA/VM, things can get really tough when resources are > scarce. > > Regards, > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 12:36:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 126E916A4CE for ; Thu, 23 Dec 2004 12:36:25 +0000 (GMT) Received: from eddie.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EDC43D1D for ; Thu, 23 Dec 2004 12:36:23 +0000 (GMT) (envelope-from simon@eddie.nitro.dk) Received: by eddie.nitro.dk (Postfix, from userid 1000) id 65A03119CD9; Thu, 23 Dec 2004 13:36:22 +0100 (CET) Date: Thu, 23 Dec 2004 13:36:22 +0100 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20041223123621.GB17515@eddie.nitro.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XvKFcGCOAo53UbWW" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: aac(4) broken on Perc 4/Di on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 12:36:25 -0000 --XvKFcGCOAo53UbWW Content-Type: multipart/mixed; boundary="3siQDZowHQqNOShm" Content-Disposition: inline --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Recent -CURRENT seems to have broken aac(4) on a Dell Perc 4/Di. The system is a Dell PowerEdge 2650 with 4 36GB IBM disks in a RAID0+1 configuration. It runs fine on a 5-STABLE kernel, but when booting -CURRENT it prints a lot of errors from the RAID controller and then fails to mount the root file-system. I have attached dmesg from 6-CURRENT and 5-STABLE, but the main interesting parts from -CURRENT are: aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pc= i4 aac0: [FAST] aacd0: on aac0 aacd0: 69425MB (142182912 sectors) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: COMMAND 0xc2409438 TIMEOUT AFTER 41 SECONDS --=20 Simon L. Nielsen --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=2650-aac-faildmesg DB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2004 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-CURRENT #3: Wed Dec 22 13:01:23 CET 2004 simon@c0.s:/usr/obj/d/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2390.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073610752 (1023 MB) avail memory = 1041965056 (993 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: irq 5 on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 14.0 (no driver attached) atapci0: port 0x8b0-0x8bf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ohci0: mem 0xfe100000-0xfe100fff irq 5 at device 15.2 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: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 pci4: on pcib1 pcib2: at device 8.0 on pci4 pci5: on pcib2 pci5: at device 6.0 (no driver attached) pci5: at device 6.1 (no driver attached) aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 aac0: [FAST] pcib3: on acpi0 pci3: on pcib3 pcib4: on acpi0 pci2: on pcib4 em0: port 0xdcc0-0xdcff mem 0xfcf00000-0xfcf3ffff,0xfcf40000-0xfcf5ffff irq 24 at device 6.0 on pci2 em0: Ethernet address: 00:0e:0c:22:2a:86 em0: Speed:N/A Duplex:N/A pcib5: on acpi0 pci1: on pcib5 pci_link1: on acpi0 pci_link2: on acpi0 pci_link3: on acpi0 pci_link4: irq 11 on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci_link8: irq 10 on acpi0 pci_link9: irq 11 on acpi0 pci_link10: on acpi0 pci_link11: on acpi0 pci_link12: irq 7 on acpi0 pci_link13: on acpi0 pci_link14: on acpi0 pci_link15: irq 10 on acpi0 pci_link16: irq 7 on acpi0 pci_link17: on acpi0 pci_link18: on acpi0 pci_link19: on acpi0 pci_link20: on acpi0 pci_link21: on acpi0 pci_link22: on acpi0 pci_link23: on acpi0 pci_link24: on acpi0 pci_link25: on acpi0 pci_link26: on acpi0 pci_link27: on acpi0 pci_link28: on acpi0 pci_link29: on acpi0 pci_link30: on acpi0 pci_link31: on acpi0 pci_link32: on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 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 IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pmtimer0 on isa0 orm0: at iomem 0xec000-0xeffff,0xcc800-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 aacd0: on aac0 aacd0: 69425MB (142182912 sectors) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: **Monitor** <...repeats 1 more times> aac0: **Monitor** ID(0:02:0) Timeout detected on cmd[0x28] aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: **Monitor** <...repeats 10 more times> aac0: **Monitor** ID(0:03:0) Timeout detected on cmd[0x28] aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: **Monitor** <...repeats 10 more times> aac0: **Monitor** SCSI Channel[0]: Timeout Detected On 2 Command(s) aac0: **Monitor** ID(0:02:0); Abort Timeout. Resetting Bus 0 aac0: **Monitor** SCSI bus reset issued on channel 0 aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: COMMAND 0xc2409438 TIMEOUT AFTER 41 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 61 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 81 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 101 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 121 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 141 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 161 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 181 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 201 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 221 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 242 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 262 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 282 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 302 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 322 SECONDS aac0: **Monitor** <...repeats 1423672 more times> aac0: **Monitor** SCSI Channel[0]: Timeout Detected On 1 Command(s) aac0: **Monitor** ID(0:02:0); Abort Timeout. Resetting Bus 0 aac0: **Monitor** SCSI bus reset issued on channel 0 aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR aac0: COMMAND 0xc2409438 TIMEOUT AFTER 358 SECONDS [.... - lot of similar repetitions] aac0: COMMAND 0xc2409438 TIMEOUT AFTER 3240 SECONDS aac0: COMMAND 0xc2409438 TIMEOUT AFTER 3260 SECONDS aac0: **Monitor** <...repeats 1423660 more times> aac0: **Monitor** ID(0:01:0) - IO failed, Cmd[0x28] aac0: **Monitor** Non Redundant Container:62 Returning Error. aac0: **Monitor** Both Drives on Mirror Container 62 failed aacd0: hard error cmd=read fsbn 20964825 aacd0: hard error cmd=read 20964825-20964826 aacd0: hard error cmd=read fsbn 41929651 aacd0: hard error cmd=read fsbn 41929650 aacd0: hard error cmd=read 41929650-41929651 aacd0: hard error cmd=read fsbn 64 aacd0: hard error cmd=read fsbn 63 aacd0: hard error cmd=read 63-64 aacd0: hard error cmd=read fsbn 64 aacd0: hard error cmd=read fsbn 63 aacd0: hard error cmd=read 63-64 Trying to mount root from ufs:/dev/aacd0s1a aacd0: hard error cmd=read 191-206 g_vfs_done():aacd0s1a[READ(offset=65536, length=8192)]error = 5 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> aa --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=2650-aac-okdmesg Copyright (c) 1992-2004 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.3-STABLE #0: Thu Dec 23 12:36:09 CET 2004 simon@c0.s:/usr/obj/d/5-STABLE/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2390.18-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073610752 (1023 MB) avail memory = 1041158144 (992 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 14.0 (no driver attached) atapci0: port 0x8b0-0x8bf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ohci0: mem 0xfe100000-0xfe100fff irq 5 at device 15.2 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: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 pci4: on pcib1 pcib2: at device 8.0 on pci4 pci5: on pcib2 pci5: at device 6.0 (no driver attached) pci5: at device 6.1 (no driver attached) aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 aac0: [FAST] aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.7-1, Build 3170, S/N f810d3 aac0: Supported Options=75c pcib3: on acpi0 pci3: on pcib3 pcib4: on acpi0 pci2: on pcib4 em0: port 0xdcc0-0xdcff mem 0xfcf00000-0xfcf3ffff,0xfcf40000-0xfcf5ffff irq 24 at device 6.0 on pci2 em0: Ethernet address: 00:0e:0c:22:2a:86 em0: Speed:N/A Duplex:N/A pcib5: on acpi0 pci1: on pcib5 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 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 IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xec000-0xeffff,0xcc800-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec acd0: CDROM at ata0-master UDMA33 aacd0: on aac0 aacd0: 69425MB (142182912 sectors) SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Mounting root from ufs:/dev/aacd0s1a --3siQDZowHQqNOShm-- --XvKFcGCOAo53UbWW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByrvFh9pcDSc1mlERAiqzAJ4i5uvWK0xPWYV945EUr95sfxQGewCfaPNG PHBpDd+euGzru9/dXf7/ZEk= =YLtM -----END PGP SIGNATURE----- --XvKFcGCOAo53UbWW-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 18:43:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 651D316A4CE for ; Wed, 22 Dec 2004 18:43:07 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BFECA43D1D for ; Wed, 22 Dec 2004 18:43:06 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 56055 invoked from network); 22 Dec 2004 18:43:06 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 22 Dec 2004 18:43:06 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 22 Dec 2004 12:43:04 -0600 (CST) From: Mike Silbersack To: current@freebsd.org Message-ID: <20041222123952.O14143@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 23 Dec 2004 13:01:30 +0000 Subject: if_wi (minor) problems with recent 80211 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 18:43:07 -0000 Since Sam fixed the WEP problem with if_wi, my wi card has been working well - for the most part. However, I have seen a problem twice in the last week that I had not seen before. Whenever I get messages like the following: wi0: timeout in wi_cmd 0x0021; event status 0x8080 wi0: timeout in wi_cmd 0x0021; event status 0x8080 wi0: wi_cmd: busy bit won't clear. The card does not seem to recover, like it used to in the past. Simply ejecting and inserting the card again fixes the problem, so it's not a big deal. Anyway, I was just wondering if others were seeing this problem as well. When I get a chance, I might go try to hunt it down, sounds like we're just doing something wrong when reinitializing. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Wed Dec 22 21:28:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23C2E16A4CE; Wed, 22 Dec 2004 21:28:30 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05C9143D1D; Wed, 22 Dec 2004 21:28:30 +0000 (GMT) (envelope-from justin@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id iBMLSTuR015337; Wed, 22 Dec 2004 13:28:29 -0800 (PST) Received: from [24.6.153.138] (c-24-6-153-138.client.comcast.net [24.6.153.138]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id iBMLSROR009054 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 22 Dec 2004 13:28:29 -0800 (PST) In-Reply-To: <41C9E437.5040309@freebsd.org> References: <00CDF9AA240E204FA6E923BD35BC643607C4803C@bcs-mail.internal.cacheflow.com> <41C9E437.5040309@freebsd.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A79A3D3-5460-11D9-99AD-00306544D642@mac.com> Content-Transfer-Encoding: 7bit From: Justin Walker Date: Wed, 22 Dec 2004 13:28:26 -0800 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Thu, 23 Dec 2004 13:01:30 +0000 cc: freebsd-current@freebsd.org Subject: Re: TCP URG point X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 22 Dec 2004 21:28:30 -0000 On Dec 22, 2004, at 13:16, Andre Oppermann wrote: > Li, Qing wrote: >> It appears the TCP urgent pointer is off by 1. >> In RFC-1122, section 4.2.2.4 on Page 83 describes the >> urgent pointer error in RFC-793. >> The 6.0-CURRENT code has the urgent pointer set >> to (LAST+1). >> Any comments before I sent a PR ? > > No, please do and send me the PR number. It may be well-known here, but this is a long-standing issue. It's been around since 4.2 days. Cf. the discussions in Stevens's UNPv12e (p. 566) and TCP/IP Illustrated, v1 (p 292-296). It may be impolitic to change this :=} Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | "Weaseling out of things is what | separates us from the animals. | Well, except the weasel." | - Homer J Simpson *--------------------------------------*-------------------------------* From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 14:50:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BF3E16A4CE; Thu, 23 Dec 2004 14:50:01 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D929E43D2F; Thu, 23 Dec 2004 14:50:00 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBNErb4l089030; Thu, 23 Dec 2004 07:53:37 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41CADACC.9050607@freebsd.org> Date: Thu, 23 Dec 2004 07:48:44 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Simon L. Nielsen" References: <20041223123621.GB17515@eddie.nitro.dk> In-Reply-To: <20041223123621.GB17515@eddie.nitro.dk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=3.8 tests=UPPERCASE_25_50 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: aac(4) broken on Perc 4/Di on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 14:50:01 -0000 Simon L. Nielsen wrote: > Hello > > Recent -CURRENT seems to have broken aac(4) on a Dell Perc 4/Di. The > system is a Dell PowerEdge 2650 with 4 36GB IBM disks in a RAID0+1 > configuration. > > It runs fine on a 5-STABLE kernel, but when booting -CURRENT it prints > a lot of errors from the RAID controller and then fails to mount the > root file-system. > > I have attached dmesg from 6-CURRENT and 5-STABLE, but the main > interesting parts from -CURRENT are: > > aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 > aac0: [FAST] > aacd0: on aac0 > aacd0: 69425MB (142182912 sectors) > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR > aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR > aac0: COMMAND 0xc2409438 TIMEOUT AFTER 41 SECONDS > > There are very few differences between the driver in 6-CURRENT and 5-STABLE, and none of the differences look like ones that could cause problems. Would you get able to step the source backwards until you find the point where it starts working again? Scott From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 15:39:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C4B16A4CE; Thu, 23 Dec 2004 15:39:50 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C8443D2F; Thu, 23 Dec 2004 15:39:49 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBNFhQrV089243; Thu, 23 Dec 2004 08:43:26 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41CAE67C.60201@freebsd.org> Date: Thu, 23 Dec 2004 08:38:36 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <41CA4240.3050605@freebsd.org> <20041223064020.GA81788@ip.net.ua> In-Reply-To: <20041223064020.GA81788@ip.net.ua> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 15:39:50 -0000 Ruslan Ermilov wrote: > Hi Scott, > > On Wed, Dec 22, 2004 at 08:57:52PM -0700, Scott Long wrote: > >>Got this while trying to build a kernel from today's sources in >>/sys/i386/compile/. I assume that we are still allowed >>to build kernels in this way, yes? >> >>===> aic7xxx (all) >>===> aic7xxx/aicasm (all) >>make: don't know how to make aicasm.1. Stop >>*** Error code 2 >>1 error >> > > We never guarantee this. What we guarantee though, is that > you'll be able to build your kernel through this sequence: > > make buildworld > make buildkernel > > This takes care of upgrade issues. In this case, the > upgrade issue is that sys/dev/aic7xxx/aicasm/Makefile > relies on the new spelling of NO_MAN, and you still > have your /usr/share/mk filled with the old stuff. > Two options: > > 1. You follow the supported upgrade path above, which > is also documented in src/UPDATING (COMMON ITEMS, > "To build a kernel"). > > 2. You follow "To just build a kernel when you know > that it won't mess you up" also from src/UPDATING, > after manually updating your /usr/share/mk: > > cd /usr/src/share/mk > make install > > > Cheers, Ok, fair enough. I think that the NO_* change warrants an UPDATING entry that describes the problem. I know that I'm not the only person who was bitten by this. Scott From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 16:04:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 980CF16A4CE; Thu, 23 Dec 2004 16:04:50 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D70C43D4C; Thu, 23 Dec 2004 16:04:49 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBNG4m0M044490; Thu, 23 Dec 2004 18:04:48 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 92897-18; Thu, 23 Dec 2004 18:04:45 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBNG3h6q044414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Dec 2004 18:03:44 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBNG3pDe031049; Thu, 23 Dec 2004 18:03:51 +0200 (EET) (envelope-from ru) Date: Thu, 23 Dec 2004 18:03:51 +0200 From: Ruslan Ermilov To: Scott Long Message-ID: <20041223160351.GB30747@ip.net.ua> References: <41CA4240.3050605@freebsd.org> <20041223064020.GA81788@ip.net.ua> <41CAE67C.60201@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <41CAE67C.60201@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@freebsd.org Subject: Re: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 16:04:50 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 23, 2004 at 08:38:36AM -0700, Scott Long wrote: > Ok, fair enough. I think that the NO_* change warrants an UPDATING > entry that describes the problem. I know that I'm not the only > person who was bitten by this. >=20 Checked in as src/UPDATING,v 1.385. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByuxnqRfpzJluFF4RAgCIAJwOX2KNZw7PA0JpbBejrqukNm37UwCcC6lE tdvZ3Qr602SYswWhuAx6mTk= =EZ3z -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 16:06:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2A7C16A4CE; Thu, 23 Dec 2004 16:06:30 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F84E43D3F; Thu, 23 Dec 2004 16:06:30 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBNGA7uk089359; Thu, 23 Dec 2004 09:10:07 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41CAECBD.8070209@freebsd.org> Date: Thu, 23 Dec 2004 09:05:17 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <41CA4240.3050605@freebsd.org> <20041223064020.GA81788@ip.net.ua> <41CAE67C.60201@freebsd.org> <20041223160351.GB30747@ip.net.ua> In-Reply-To: <20041223160351.GB30747@ip.net.ua> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 16:06:30 -0000 Ruslan Ermilov wrote: > On Thu, Dec 23, 2004 at 08:38:36AM -0700, Scott Long wrote: > >>Ok, fair enough. I think that the NO_* change warrants an UPDATING >>entry that describes the problem. I know that I'm not the only >>person who was bitten by this. >> > > Checked in as src/UPDATING,v 1.385. > > > Cheers, Ah, apparently I missed that update. Sorry =-) Scott From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 16:14:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B356616A4CE; Thu, 23 Dec 2004 16:14:35 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E59EB43D39; Thu, 23 Dec 2004 16:14:34 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBNGEYao045118; Thu, 23 Dec 2004 18:14:34 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 04775-11; Thu, 23 Dec 2004 18:14:30 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBNGAvH4044867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Dec 2004 18:10:58 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBNGB506031156; Thu, 23 Dec 2004 18:11:05 +0200 (EET) (envelope-from ru) Date: Thu, 23 Dec 2004 18:11:05 +0200 From: Ruslan Ermilov To: Scott Long Message-ID: <20041223161104.GC30747@ip.net.ua> References: <41CA4240.3050605@freebsd.org> <20041223064020.GA81788@ip.net.ua> <41CAE67C.60201@freebsd.org> <20041223160351.GB30747@ip.net.ua> <41CAECBD.8070209@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8X7/QrJGcKSMr1RN" Content-Disposition: inline In-Reply-To: <41CAECBD.8070209@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: Re: Kernel build failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 16:14:35 -0000 --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 23, 2004 at 09:05:17AM -0700, Scott Long wrote: > Ruslan Ermilov wrote: > >On Thu, Dec 23, 2004 at 08:38:36AM -0700, Scott Long wrote: > > > >>Ok, fair enough. I think that the NO_* change warrants an UPDATING > >>entry that describes the problem. I know that I'm not the only > >>person who was bitten by this. > >> > > > >Checked in as src/UPDATING,v 1.385. > > > > > >Cheers, >=20 > Ah, apparently I missed that update. Sorry =3D-) >=20 No, you didn't -- it was in reply to your email. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8X7/QrJGcKSMr1RN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFByu4YqRfpzJluFF4RApo5AJ0Yct0ruAncpab4PaT8eOcP3kQVPACfVo4w L4r/1gAQGn0jFZeR61nihv4= =YyZb -----END PGP SIGNATURE----- --8X7/QrJGcKSMr1RN-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 17:32:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 251F216A4CE for ; Thu, 23 Dec 2004 17:32:43 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 6532D43D48 for ; Thu, 23 Dec 2004 17:32:43 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 2611 invoked from network); 23 Dec 2004 17:32:41 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 23 Dec 2004 17:32:41 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id iBNHWfZQ038258 for ; Thu, 23 Dec 2004 18:32:41 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id iBNHWfn1038257 for current@freebsd.org; Thu, 23 Dec 2004 18:32:41 +0100 (CET) (envelope-from pho) Date: Thu, 23 Dec 2004 18:32:38 +0100 From: Peter Holm To: current@freebsd.org Message-ID: <20041223173238.GA38245@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: lock (sleep mutex) vm object not locked @ vm_map.c:1433 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 17:32:44 -0000 With GENERIC HEAD from Dec 20 12:18 UTC I got: panic(c082f17c,c08448df,c0845279,c084494b,599) at panic+0xd8 witness_unlock(c105d8c4,8,c0844942,599) at witness_unlock+0x170 _mtx_unlock_flags(c105d8c4,0,c0844942,599,0,0,1d000,0) at _mtx_unlock_flags+0x3b vm_map_insert(c2072960,c105d8c4,0,0,28060000,1d000,5,7,0,c2072960,c0827d62,156) at vm_map_insert+0x1ad elf32_map_insert(0,0,28060000,2807d000,5,7,10a) at elf32_map_insert+0x21e elf32_load_section(c1787114,c105d8c4,0,28060000,1c96a,1c96a,5,1000) at elf32_load_section+0x202 elf32_load_file(cf68faa8,cf68fbd0,1000) at elf32_load_file+0x3a6 exec_elf32_imgact(cf68fb94) at exec_elf32_imgact+0x413 kern_execve(c35a68a0,8068384,80683a4,8068404,0) at kern_execve+0x3fa execve(c35a68a0,cf68fd14,3,0,286) at execve+0x18 syscall(2f,2f,2f,0,8068384) at syscall+0x128 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip = 0x28127767, esp = 0xbfbfe7fc, ebp = 0xbfbfe828 --- Details at http://www.holm.cc/stress/log/cons97.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 18:10:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89CD716A4CE for ; Thu, 23 Dec 2004 18:10:44 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C55A43D1D for ; Thu, 23 Dec 2004 18:10:44 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) iBNIAhKO023807; Thu, 23 Dec 2004 10:10:43 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)iBNIAhHk023806; Thu, 23 Dec 2004 10:10:43 -0800 (PST) (envelope-from sgk) Date: Thu, 23 Dec 2004 10:10:43 -0800 From: Steve Kargl To: Peter Holm Message-ID: <20041223181043.GA23763@troutmask.apl.washington.edu> References: <20041223173238.GA38245@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041223173238.GA38245@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: lock (sleep mutex) vm object not locked @ vm_map.c:1433 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 18:10:44 -0000 On Thu, Dec 23, 2004 at 06:32:38PM +0100, Peter Holm wrote: > With GENERIC HEAD from Dec 20 12:18 UTC I got: > > panic(c082f17c,c08448df,c0845279,c084494b,599) at panic+0xd8 > witness_unlock(c105d8c4,8,c0844942,599) at witness_unlock+0x170 > _mtx_unlock_flags(c105d8c4,0,c0844942,599,0,0,1d000,0) at > _mtx_unlock_flags+0x3b > vm_map_insert(c2072960,c105d8c4,0,0,28060000,1d000,5,7,0,c2072960,c0827d62,156) > at vm_map_insert+0x1ad > elf32_map_insert(0,0,28060000,2807d000,5,7,10a) at > elf32_map_insert+0x21e > elf32_load_section(c1787114,c105d8c4,0,28060000,1c96a,1c96a,5,1000) > at elf32_load_section+0x202 > elf32_load_file(cf68faa8,cf68fbd0,1000) at elf32_load_file+0x3a6 > exec_elf32_imgact(cf68fb94) at exec_elf32_imgact+0x413 > kern_execve(c35a68a0,8068384,80683a4,8068404,0) at > kern_execve+0x3fa > execve(c35a68a0,cf68fd14,3,0,286) at execve+0x18 > syscall(2f,2f,2f,0,8068384) at syscall+0x128 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (59, FreeBSD ELF32, execve), eip = 0x28127767, esp = > 0xbfbfe7fc, ebp = 0xbfbfe828 --- > > Details at http://www.holm.cc/stress/log/cons97.html I'm seeing something similiar. Trying to mount root from ufs:/dev/ad0s3a Memory modified after free 0xc1bcb800 (508) val=ff0ff70 @ 0xc1bcb800 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xff70ff90 fault code = supervisor read, page not present instruction pointer = 0x8:0xc064776d stack pointer = 0x10:0xd539291c frame pointer = 0x10:0xd539293c code segement = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enable, resume, IOPL=0 current process = 49 (init) db> trace mtrash_ctor at mtrash_ctor+0x63 uma_zalloc_arg at uma_zalloc_arg+0x46c malloc at malloc+0x87 elf32_load_file at elf32_load_file+0x4b exec_elf32_imgact at exec_elf32_imgact+0x483 kern_execve at kern_execve+0x454 execve at execve+0x30 syscall at syscal+0x13b Xint0x80_syscall at Xint0x80_syscall+0x1f -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 19:57:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF96B16A4CE for ; Thu, 23 Dec 2004 19:57:08 +0000 (GMT) Received: from post.com2com.ru (Post.com2com.ru [195.98.162.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 183B143D1F for ; Thu, 23 Dec 2004 19:57:08 +0000 (GMT) (envelope-from apeter.subscribe@mail.ru) Received: from [172.30.12.177] (home-pool-173-10.com2com.ru [195.98.173.10]) by post.com2com.ru (8.13.1/8.13.1) with ESMTP id iBNJv38T016295 for ; Thu, 23 Dec 2004 22:57:05 +0300 (MSK) Resent-Date: Thu, 23 Dec 2004 22:57:03 +0300 (MSK) Resent-Message-Id: <200412231957.iBNJv38T016295@post.com2com.ru> Date: Thu, 23 Dec 2004 22:56:50 +0300 From: "Peter E. Antonov" X-Mailer: The Bat! (v2.11) Business X-Priority: 3 (Normal) Message-ID: <742845244.20041223225650@mail.ru> To: freebsd-current@freebsd.org Resent-From: "Peter E. Antonov" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Some questions about Dynamic disks support in FreeBSD and about NTFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Peter E. Antonov" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 19:57:09 -0000 Hello, freebsd-questions. Whether support of the dynamic disks created in Windows XP/2000 is planned in the near future? And how affairs with support NTFS are? Some links: http://www.jankratochvil.net/project/captive/ - project implements the first full read/write free access to NTFS disk drives in GNU/Linux. http://linux-ntfs.sourceforge.net - NTFS support in Linux http://linux-ntfs.sourceforge.net/info/ldm.html - some information about Windows Dynamic Disks -- WBR, Peter mailto: apeter.subscribe [{at}] mail.ru From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 20:08:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58CF016A4CE for ; Thu, 23 Dec 2004 20:08:18 +0000 (GMT) Received: from mail.snowfall.se (guldivar.globalwire.se [212.112.184.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C27443D3F for ; Thu, 23 Dec 2004 20:08:17 +0000 (GMT) (envelope-from stefan@snowfall.se) Received: from [192.168.0.102] (h147n2fls303o851.telia.com [81.224.229.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.snowfall.se (Postfix) with ESMTP id 9CA3BB8F for ; Thu, 23 Dec 2004 21:08:14 +0100 (CET) Message-ID: <41CB25AE.6050503@snowfall.se> Date: Thu, 23 Dec 2004 21:08:14 +0100 From: Stefan Cars 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: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 20:08:18 -0000 Hi! How stable is amd64 on Intel Xeon with EMT64 ? We have a new PE 1850 with 4GB memory and two dual 2.8 Xeons. Should I go with i386 or amd64 ? Which one is most stable and what will I gain from amd64 ? Kind Regards, Stefan Cars From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 21:10:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73B8E16A4CE for ; Thu, 23 Dec 2004 21:10:15 +0000 (GMT) Received: from supermail.ispro.net.tr (supermail.ispro.net.tr [217.21.68.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0616043D46 for ; Thu, 23 Dec 2004 21:10:14 +0000 (GMT) (envelope-from yurtesen-dated-1104700211.19ba42@ispro.net.tr) Received: (qmail 45520 invoked by uid 89); 23 Dec 2004 21:10:11 -0000 Received: from [84.248.198.116] (dsl-aur-x74.dial.inet.fi [84.248.198.116]) by supermail.ispro.net.tr (tmda-ofmipd) with ESMTP; Thu, 23 Dec 2004 23:10:08 +0200 (EET) Message-ID: <41CBC0B4.6020005@ispro.net.tr> Date: Thu, 23 Dec 2004 23:09:40 -0800 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Cars References: <41CB25AE.6050503@snowfall.se> In-Reply-To: <41CB25AE.6050503@snowfall.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Evren Yurtesen X-Primary-Address: yurtesen@ispro.net.tr cc: freebsd-current@freebsd.org Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 21:10:15 -0000 amd64 on intel? I dont think it would work. You should use i386. To use amd64, you should get an 64bit AMD processor like AMD Athlon 64 http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_9484,00.html Evren Stefan Cars wrote: > Hi! > > How stable is amd64 on Intel Xeon with EMT64 ? We have a new PE 1850 > with 4GB memory and two dual 2.8 Xeons. Should I go with i386 or amd64 ? > Which one is most stable and what will I gain from amd64 ? > > Kind Regards, > Stefan Cars > _______________________________________________ > 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 Dec 23 21:14:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A44D316A4CE for ; Thu, 23 Dec 2004 21:14:32 +0000 (GMT) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id D707F43D2F for ; Thu, 23 Dec 2004 21:14:31 +0000 (GMT) (envelope-from bsd-current@epcdirect.co.uk) Received: from lfarr (lfarr.adsl.gemsoft.co.uk [195.10.239.114]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 517A667AF4; Thu, 23 Dec 2004 21:14:30 +0000 (GMT) From: "Lawrence Farr" To: "'Evren Yurtesen'" , "'Stefan Cars'" Date: Thu, 23 Dec 2004 21:14:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTpM/B0sZnxsZPaRdCF3UiGYzgnrAAAFJQA In-Reply-To: <41CBC0B4.6020005@ispro.net.tr> Message-Id: <20041223211430.517A667AF4@gunfright.epcdirect.co.uk> cc: freebsd-current@freebsd.org Subject: RE: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 21:14:32 -0000 The Xeon EMT64 is 64 bit, and the amd64 port of FreeBSD runs on it just fine apparently. > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Evren Yurtesen > Sent: 24 December 2004 07:10 > To: Stefan Cars > Cc: freebsd-current@freebsd.org > Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 > > amd64 on intel? I dont think it would work. > > You should use i386. > > To use amd64, you should get an 64bit AMD processor like AMD Athlon 64 > http://www.amd.com/us-en/Processors/ProductInformation/0,,30_1 18_9484,00.html > > Evren > > Stefan Cars wrote: > > Hi! > > > > How stable is amd64 on Intel Xeon with EMT64 ? We have a > new PE 1850 > > with 4GB memory and two dual 2.8 Xeons. Should I go with > i386 or amd64 ? > > Which one is most stable and what will I gain from amd64 ? > > > > Kind Regards, > > Stefan Cars > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 21:14:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9584A16A4CE for ; Thu, 23 Dec 2004 21:14:46 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 233ED43D31 for ; Thu, 23 Dec 2004 21:14:46 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iBNLIOCD090555; Thu, 23 Dec 2004 14:18:24 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41CB34FC.6000104@freebsd.org> Date: Thu, 23 Dec 2004 14:13:32 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Evren Yurtesen References: <41CB25AE.6050503@snowfall.se> <41CBC0B4.6020005@ispro.net.tr> In-Reply-To: <41CBC0B4.6020005@ispro.net.tr> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org cc: Stefan Cars Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 21:14:46 -0000 Evren Yurtesen wrote: > amd64 on intel? I dont think it would work. > > You should use i386. > > To use amd64, you should get an 64bit AMD processor like AMD Athlon 64 > http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_9484,00.html > No, this is not correct. The EM64T 'extentions' from Intel implement the amd64 ISA. To answer the original question, FreeBSD/amd64 runs fine on EM64T processors. Scott From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 21:23:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 374DF16A4CE for ; Thu, 23 Dec 2004 21:23:26 +0000 (GMT) Received: from kirk.fuqn.ca (kirk.fuqn.ca [66.38.165.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D63E43D1F for ; Thu, 23 Dec 2004 21:23:25 +0000 (GMT) (envelope-from jtregunna@fuqn.ca) Received: from [192.168.0.14] (scotty.fuqn.ca [66.38.165.231]) (authenticated bits=0) by kirk.fuqn.ca (8.13.1/8.13.1) with ESMTP id iBNLMA7X038547 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Thu, 23 Dec 2004 21:22:10 GMT (envelope-from jtregunna@fuqn.ca) In-Reply-To: <41CB25AE.6050503@snowfall.se> References: <41CB25AE.6050503@snowfall.se> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jeremy Tregunna Date: Thu, 23 Dec 2004 16:22:46 -0500 To: Stefan Cars X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) Received-SPF: pass (kirk.fuqn.ca: 66.38.165.231 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 21:09:44 2004 clamav-milter version 0.80j on kirk.fuqn.ca X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 21:23:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 23, 2004, at 3:08 PM, Stefan Cars wrote: > How stable is amd64 on Intel Xeon with EMT64 ? We have a new PE 1850 > with 4GB memory and two dual 2.8 Xeons. Should I go with i386 or amd64 > ? Which one is most stable and what will I gain from amd64 ? I've not had any major issues running on my EM64T system. That being said, I'd probably recommend you run amd64 on it. - -- Jeremy Tregunna jtregunna@fuqn.ca "Under communism, man exploits man. Under capitalism, it's just the opposite." -- J.K. Galbraith -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFByzcqE2T6/THbyegRAhvuAKC2o+NqJxd2J0S/GRHJ/5OVyl9ktACfWg0b 4bfjT9sFEPEi60dZyz0bKhg= =QbRh -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 21:27:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31BAC16A4CE for ; Thu, 23 Dec 2004 21:27:03 +0000 (GMT) Received: from web80603.mail.yahoo.com (web80603.mail.yahoo.com [66.218.79.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 2122843D2D for ; Thu, 23 Dec 2004 21:27:03 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20041223212703.37253.qmail@web80603.mail.yahoo.com> Received: from [207.126.239.39] by web80603.mail.yahoo.com via HTTP; Thu, 23 Dec 2004 13:27:03 PST Date: Thu, 23 Dec 2004 13:27:03 -0800 (PST) From: Mohan Srinivasan To: alex.wilkinson@dsto.defence.gov.au, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: NFS flakiness since @ last Friday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 21:27:03 -0000 NFS Direct IO completely bypasses the client cache and is useful in situations where - The application does caching. - The application knows that the data read/written is not going to be accessed again anytime soon. I did stress testing of NFS direct IO, but need to replicate the environments/tests that you guys are seeing problems in. I am going to turn off NFS direct IO support till the problems are fixed. mohan From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 21:51:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E17E16A4CE for ; Thu, 23 Dec 2004 21:51:22 +0000 (GMT) Received: from web14126.mail.yahoo.com (web14126.mail.yahoo.com [66.163.171.117]) by mx1.FreeBSD.org (Postfix) with SMTP id 44F3243D1F for ; Thu, 23 Dec 2004 21:51:22 +0000 (GMT) (envelope-from cguttesen@yahoo.dk) Received: (qmail 18164 invoked by uid 60001); 23 Dec 2004 21:51:22 -0000 Message-ID: <20041223215122.18162.qmail@web14126.mail.yahoo.com> Received: from [194.248.174.50] by web14126.mail.yahoo.com via HTTP; Thu, 23 Dec 2004 22:51:22 CET Date: Thu, 23 Dec 2004 22:51:22 +0100 (CET) From: Claus Guttesen To: Evren Yurtesen , Stefan Cars In-Reply-To: <41CBC0B4.6020005@ispro.net.tr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-current@freebsd.org Subject: Re: amd64 or i386 on PE 1850 Intel Xeon with EMT64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 21:51:22 -0000 > amd64 on intel? I dont think it would work. Why not? > You should use i386. I have two Dell PE 1850's with the exact same amd64 setup as two other servers with opteron. > To use amd64, you should get an 64bit AMD processor > like AMD Athlon 64 My impression is that the amd64-port performs slightly faster than it's i386-cousin on the same hardware. regards Claus From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:10:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EB7116A4CE; Thu, 23 Dec 2004 22:10:43 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E64A43D45; Thu, 23 Dec 2004 22:10:42 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBNMAfZb066358; Fri, 24 Dec 2004 00:10:41 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 07669-17; Fri, 24 Dec 2004 00:10:40 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBNMAelP066355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Dec 2004 00:10:40 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBNMAlWF018398; Fri, 24 Dec 2004 00:10:47 +0200 (EET) (envelope-from ru) Date: Fri, 24 Dec 2004 00:10:47 +0200 From: Ruslan Ermilov To: Soren Schmidt Message-ID: <20041223221047.GB6049@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org Subject: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 22:10:43 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Soren, Finally, I had time today to track it down to a single commit. So, the following change breaks my Promise SATA150 controller: : sos 2004-12-08 10:02:41 UTC :=20 : FreeBSD src repository :=20 : Modified files: : sys/dev/ata ata-chipset.c ata-pci.h=20 : Log: : Add first shot on support for the new Promise SATAII chips. : =20 : HW donated by: pil.dk : =20 : Revision Changes Path : 1.93 +109 -49 src/sys/dev/ata/ata-chipset.c : 1.36 +10 -2 src/sys/dev/ata/ata-pci.h Here's the difference in "ata" output before and after this commit: --- ata.ok Thu Dec 23 23:52:37 2004 +++ ata.bad Fri Dec 24 00:01:53 2004 @@ -1,12 +1,14 @@ atapci0: port 0xffa0-0xffaf,0x376,0x17= 0-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xd000-0xd07f,0xd400-0= xd40f,0xd800-0xd83f mem 0xfc960000-0xfc97ffff,0xfc99f000-0xfc99ffff irq 5 a= t device 8.0 on pci1 atapci1: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 ata4: channel #2 on atapci1 ad0: 76319MB [155061/16/63] at ata0-master UDMA100 ata1-slave: DMA limited to UDMA33, non-ATA66 cable or device acd0: CDRW at ata1-slave UDMA33 -ad8: 76319MB [155061/16/63] at ata4-master UDMA100 +ata4-master: FAILURE - ATA_IDENTIFY timed out +ata4-master: FAILURE - ATA_IDENTIFY timed out +ata4-master: FAILURE - ATA_IDENTIFY timed out As others have pointed out already, the next commit : sos 2004-12-08 11:16:33 UTC :=20 : FreeBSD src repository :=20 : Modified files: : sys/dev/ata ata-queue.c=20 : Log: : Reset timeout when we are back from interrupt. : =20 : Revision Changes Path : 1.41 +3 -0 src/sys/dev/ata/ata-queue.c made things even worse (the system now panics). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBy0JnqRfpzJluFF4RAkjlAJsEnb9ahvxx74yCqGeFtUNADuhPSgCfQeS1 81k7+BK8qLO/4MZdw32zRX4= =KR6O -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:11:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF5D216A4CE; Thu, 23 Dec 2004 22:11:50 +0000 (GMT) Received: from eddie.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CE2E43D58; Thu, 23 Dec 2004 22:11:50 +0000 (GMT) (envelope-from simon@eddie.nitro.dk) Received: by eddie.nitro.dk (Postfix, from userid 1000) id 96FAB119CD9; Thu, 23 Dec 2004 23:11:49 +0100 (CET) Date: Thu, 23 Dec 2004 23:11:49 +0100 From: "Simon L. Nielsen" To: Scott Long Message-ID: <20041223221149.GB22614@eddie.nitro.dk> References: <20041223123621.GB17515@eddie.nitro.dk> <41CADACC.9050607@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <41CADACC.9050607@freebsd.org> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: aac(4) broken on Perc 4/Di on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 22:11:51 -0000 --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.12.23 07:48:44 -0700, Scott Long wrote: >=20 > Simon L. Nielsen wrote: > >Hello > > > >Recent -CURRENT seems to have broken aac(4) on a Dell Perc 4/Di. The > >system is a Dell PowerEdge 2650 with 4 36GB IBM disks in a RAID0+1 > >configuration. > > > >It runs fine on a 5-STABLE kernel, but when booting -CURRENT it prints > >a lot of errors from the RAID controller and then fails to mount the > >root file-system. > > > >I have attached dmesg from 6-CURRENT and 5-STABLE, but the main > >interesting parts from -CURRENT are: > > > >aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on= =20 > >pci4 > >aac0: [FAST] > >aacd0: on aac0 > >aacd0: 69425MB (142182912 sectors) > >SMP: AP CPU #3 Launched! > >SMP: AP CPU #1 Launched! > >SMP: AP CPU #2 Launched! > >aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR > >aac0: **Monitor** NMI ISR: NMI_SECONDARY_ATU_ERROR > >aac0: COMMAND 0xc2409438 TIMEOUT AFTER 41 SECONDS >=20 > There are very few differences between the driver in 6-CURRENT and > 5-STABLE, and none of the differences look like ones that could > cause problems. Would you get able to step the source backwards until > you find the point where it starts working again? Sure, it might be some days before I can really try it, since I will not be near the server, so if I rearlly crash it I won't be able to get it back up :-). BTW. it is a Perc 3/Di, not Perc 4/Di, as I wrote by mistake. --=20 Simon L. Nielsen --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBy0Klh9pcDSc1mlERAiVpAJwK999GpqeXuZoN7bnBJwLMCd8kCQCgqoWH 1gb6wd4lKfE9wA4fUOV1zO8= =MwSz -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:28:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37B6316A4CE for ; Thu, 23 Dec 2004 22:28:56 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EBA043D1D for ; Thu, 23 Dec 2004 22:28:56 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 0D89172DD4; Thu, 23 Dec 2004 14:28:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 0886572DCB; Thu, 23 Dec 2004 14:28:56 -0800 (PST) Date: Thu, 23 Dec 2004 14:28:55 -0800 (PST) From: Doug White To: "Peter E. Antonov" In-Reply-To: <742845244.20041223225650@mail.ru> Message-ID: <20041223142734.V97437@carver.gumbysoft.com> References: <742845244.20041223225650@mail.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Some questions about Dynamic disks support in FreeBSD and about NTFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 22:28:56 -0000 On Thu, 23 Dec 2004, Peter E. Antonov wrote: > Whether support of the dynamic disks created in Windows XP/2000 is > planned in the near future? I'm not aware of any projects to implement this on FreeBSD. > And how affairs with support NTFS are? It seems to work for most cases. Note the restrictions under WRITING on the mount_ntfs(8) manpage. > Some links: > http://www.jankratochvil.net/project/captive/ - project implements > the first full read/write free access to NTFS disk drives in > GNU/Linux. > > http://linux-ntfs.sourceforge.net - NTFS support in Linux > http://linux-ntfs.sourceforge.net/info/ldm.html - some information > about Windows Dynamic Disks Unfortunately filesystems don't port from Linux that easily. While perhaps useful for reference data, most of the code would have to be reimplemented for our kernel API. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:43:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6ADA16A4CE for ; Thu, 23 Dec 2004 22:43:15 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 786A543D4C for ; Thu, 23 Dec 2004 22:43:15 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from [192.168.0.10] (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id iBNMhEXI029653 for ; Thu, 23 Dec 2004 14:43:15 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Thu, 23 Dec 2004 15:42:11 -0700 User-Agent: KMail/1.7.2 References: <200412221315.47189.lists@jnielsen.net> <200412222048.32037.lists@jnielsen.net> <20041223060854.GB28133@odin.ac.hmc.edu> In-Reply-To: <20041223060854.GB28133@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412231542.11950.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 22:43:15 -0000 On Wednesday 22 December 2004 11:08 pm, Brooks Davis wrote: > On Wed, Dec 22, 2004 at 08:48:31PM -0700, John Nielsen wrote: > > What would be needed to simply have the controller recognized > > and able to support UDMA 150 (or even 133)? > > At least in current, there's an nForce2 MCP device id that is supposed > to support UDMA6 so I suspect you may just need to wait a bit and it > will arrive. It's possiable you have a board with a non-standard > PCI-id. You might make sure "pciconf -lv" shows that your controler > shows a device ID of 0x008510de. If not, you may be a simple matter of > adding it to the necessicary two lines. Thanks, I'll try booting off a -current snapshot and see what shows up. JN From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:45:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EA8416A4CE for ; Thu, 23 Dec 2004 22:45:24 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D0443D1F for ; Thu, 23 Dec 2004 22:45:24 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 1866 invoked from network); 23 Dec 2004 22:45:24 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 23 Dec 2004 22:45:24 -0000 Received: from hydrogen.funkthat.com (clejqd@localhost.funkthat.com [127.0.0.1])iBNMjMGH056395; Thu, 23 Dec 2004 14:45:22 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id iBNMjLa5056394; Thu, 23 Dec 2004 14:45:21 -0800 (PST) Date: Thu, 23 Dec 2004 14:45:21 -0800 From: John-Mark Gurney To: Maxim Sobolev Message-ID: <20041223224521.GI19624@funkthat.com> Mail-Followup-To: Maxim Sobolev , Poul-Henning Kamp , "current@freebsd.org" References: <97664.1102797317@critter.freebsd.dk> <41BD850A.5060001@portaone.com> <41BDEBFB.7010204@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BDEBFB.7010204@portaone.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Poul-Henning Kamp cc: "current@freebsd.org" Subject: Re: GBDE write performance really sucks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 22:45:24 -0000 Maxim Sobolev wrote this message on Mon, Dec 13, 2004 at 21:22 +0200: > Little more investigation revealed that the problem was due to disabled > write cache in ata(4). It would be interesting to compare FreeBSD > behaviour to behaviour of other operating systems in such situation, > since the drop of sequental writing performance in the case of 8KB > blocks and disabled write cache in FreeBSD is about 20x (from more than > 20MB/sec to merely 1MB/sec), which doesn't look reasonably to me. I've heard (though not confirmed) that many hard disks use larger than 512byte blocks for on disk data.. If this is the case, when you turn off write cacheing you maybe requiring the hard disk to do a read/write of the same block significantly impacting performance... Don't forget that doing purely sequental writes introduces a bandwidth product into the mix.. If it always takes your hd 5ms to respond to a command, and you only do 8KB/sec, then we end up with a max data rate of 1600KB. With write caching disabled, you prevent the hd from optimizing how it does the writes. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:46:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B44F516A5F5 for ; Thu, 23 Dec 2004 22:46:35 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C00143D1F for ; Thu, 23 Dec 2004 22:46:35 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from [192.168.0.10] (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id iBNMkZXI032185 for ; Thu, 23 Dec 2004 14:46:35 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Thu, 23 Dec 2004 15:45:32 -0700 User-Agent: KMail/1.7.2 References: <200412221315.47189.lists@jnielsen.net> <20041223121128.G21793@sbk-gw.sibnet.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412231545.32246.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 22:46:37 -0000 On Wednesday 22 December 2004 11:32 pm, Jeremy Messenger wrote: > On Thu, 23 Dec 2004 12:19:58 +0600 (NOVT), Maxim M. Kazachek > > wrote: > > MCP 2 doesn't have ANY SATA support. MCP have 6ch codec, 2xATA133, > > I have the same (maybe, mine is 7N2 Delta2 Platinum) motherboard as his > and it does has SATA support. Mine SATA is disabled in BIOS, which I > don't have any SATA HD. > > ===================================== > ? nVIDIA nForce2 Gigabit MCP Chipset > - Integrated Ethernet MAC > - Integrated Hardware Sound Blaster/Direct Sound AC97 audio > - Ultra DMA 66/100/133 master mode PCI EIDE controller > - Supports USB 2.0 > - Integrated SATA Interface > ===================================== It is indeed integrated on this mainboard. Just from looking at the chips on the board, it appears that the Ethernet and SATA are both handled by the same MCP2 chip. I was surprised myself not to see a Silicon Image or silicon image controller/BIOS when I booted it up. I haven't yet had any luck with the onboard ethernet, even with the net/nvnet port. I guess that's what PCI slots are for.. :) JN From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 22:55:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B5A116A4CE for ; Thu, 23 Dec 2004 22:55:00 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C82243D1D for ; Thu, 23 Dec 2004 22:54:59 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao01.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041223225452.QDSL27357.lakermmtao01.cox.net@mezz.mezzweb.com>; Thu, 23 Dec 2004 17:54:52 -0500 Date: Thu, 23 Dec 2004 16:55:37 -0600 To: "John Nielsen" References: <200412221315.47189.lists@jnielsen.net> <20041223121128.G21793@sbk-gw.sibnet.ru> <200412231545.32246.lists@jnielsen.net> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200412231545.32246.lists@jnielsen.net> User-Agent: Opera M2/7.54u1 (Linux, build 892) cc: freebsd-current@freebsd.org Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 22:55:00 -0000 On Thu, 23 Dec 2004 15:45:32 -0700, John Nielsen wrote: > On Wednesday 22 December 2004 11:32 pm, Jeremy Messenger wrote: >> On Thu, 23 Dec 2004 12:19:58 +0600 (NOVT), Maxim M. Kazachek >> >> wrote: >> > MCP 2 doesn't have ANY SATA support. MCP have 6ch codec, 2xATA133, >> >> I have the same (maybe, mine is 7N2 Delta2 Platinum) motherboard as his >> and it does has SATA support. Mine SATA is disabled in BIOS, which I >> don't have any SATA HD. >> >> ===================================== >> ? nVIDIA nForce2 Gigabit MCP Chipset >> - Integrated Ethernet MAC >> - Integrated Hardware Sound Blaster/Direct Sound AC97 audio >> - Ultra DMA 66/100/133 master mode PCI EIDE controller >> - Supports USB 2.0 >> - Integrated SATA Interface >> ===================================== > > It is indeed integrated on this mainboard. Just from looking at the > chips on the board, it appears that the Ethernet and SATA are both > handled by the same MCP2 chip. I was surprised myself not to see a > Silicon Image or silicon image controller/BIOS when I booted it up. > > I haven't yet had any luck with the onboard ethernet, even with the > net/nvnet port. I guess that's what PCI slots are for.. :) nvnet and ndis don't work for me too, but I haven't test with updated nvnet in ports yet. I disabled it in BIOS. I usually disable many stuff in BIOS if I don't use them or don't work with FreeBSD. :-) Cheers, Mezz > JN -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 01:12:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA4A816A4CE; Fri, 24 Dec 2004 01:12:15 +0000 (GMT) Received: from av7-2-sn4.m-sp.skanova.net (av7-2-sn4.m-sp.skanova.net [81.228.10.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A7543D5D; Fri, 24 Dec 2004 01:12:15 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 6F94B37E65; Fri, 24 Dec 2004 02:12:14 +0100 (CET) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 602E837E63; Fri, 24 Dec 2004 02:12:14 +0100 (CET) Received: from sentinel (h211n1fls11o822.telia.com [213.64.66.211]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 3006337E46; Fri, 24 Dec 2004 02:12:14 +0100 (CET) From: "Daniel Eriksson" To: "'Ruslan Ermilov'" , "'Soren Schmidt'" Date: Fri, 24 Dec 2004 02:14:12 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20041223221047.GB6049@ip.net.ua> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTpPN98SyJn0xDgSAqFRaDIajDluQAFwdUQ cc: current@freebsd.org Subject: RE: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 01:12:16 -0000 Ruslan Ermilov wrote: > Finally, I had time today to track it down to a single > commit. So, the following change breaks my Promise > SATA150 controller: I'm running a Promise SATA150 TX4 on a recent 6-CURRENT (2004.12.20.16.00.00) machine without any problems. I only have 3 discs hooked up to it though (plus 2 more on the on-board VIA SATA = controller). Also, I had some problems with ACPI and ATA/SATA on this machine after = the last big commit (a few weeks ago) so I turned it off. You might want to = try that if you haven't already. The machine is head-less, so I haven't = tried re-enabling ACPI since then. Maybe I should also note that this is the machine that I tried to use ataraid to create a 1.2TB array. It doesn't work (possible overflow =3D strange array size). S=F6ren, you might want to look into 1+TB ataraid = arrays. /Daniel Eriksson atapci0: port 0xb000-0xb0ff,0xb400-0xb403,0xb800-0xb807,0xd000-0xd003,0xd400-0xd407 = irq 10 at device 14.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0x9400-0x94ff,0x9800-0x9803,0xa000-0xa007,0xa400-0xa403,0xa800-0xa807 = irq 10 at device 14.1 on pci0 ata4: channel #0 on atapci1 ata5: channel #1 on atapci1 atapci2: port 0x7400-0x74ff,0x7800-0x780f,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9= 000 -0x9007 irq 5 at device 15.0 on pci0 ata6: channel #0 on atapci2 ata7: channel #1 on atapci2 atapci3: port 0x7000-0x700f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 7 at device 15.1 = on pci0 ata0: channel #0 on atapci3 ata1: channel #1 on atapci3 ... atapci4: port 0x4400-0x447f,0x4800-0x480f,0x5000-0x503f mem 0xeb800000-0xeb81ffff,0xec000000-0xec000fff irq 12 at device 19.0 on = pci0 atapci4: failed: rid 0x20 is memory, requested 4 ata8: channel #0 on atapci4 ata9: channel #1 on atapci4 ata10: channel #2 on atapci4 ata11: channel #3 on atapci4 ... ad0: 26059MB [52946/16/63] at ata0-master = UDMA66 ad4: 190782MB [387621/16/63] at ata2-master UDMA100 ad5: 190782MB [387621/16/63] at ata2-slave UDMA100 ad6: 190782MB [387621/16/63] at ata3-master UDMA100 ad7: 190782MB [387621/16/63] at ata3-slave UDMA100 ad8: 190782MB [387621/16/63] at ata4-master UDMA100 ad9: 190782MB [387621/16/63] at ata4-slave UDMA100 ad12: 238475MB [484521/16/63] at = ata6-master SATA150 ad14: 238475MB [484521/16/63] at = ata7-master SATA150 ad16: 238475MB [484521/16/63] at = ata8-master SATA150 ad18: 239372MB [486344/16/63] at ata9-master SATA150 ad20: 239372MB [486344/16/63] at ata10-master SATA150 From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 01:33:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1AEA16A4CE for ; Fri, 24 Dec 2004 01:33:56 +0000 (GMT) Received: from mail.iinet.net.au (mail-04.iinet.net.au [203.59.3.36]) by mx1.FreeBSD.org (Postfix) with SMTP id B55D943D4C for ; Fri, 24 Dec 2004 01:33:55 +0000 (GMT) (envelope-from spikey1101@iinet.net.au) Received: (qmail 20492 invoked from network); 24 Dec 2004 01:33:54 -0000 Received: from unknown (HELO ?10.100.6.10?) (203.206.229.203) by mail.iinet.net.au with SMTP; 24 Dec 2004 01:33:54 -0000 From: Warren Liddell To: freebsd-current@freebsd.org Date: Fri, 24 Dec 2004 11:33:47 +1000 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412241133.47629.spikey1101@iinet.net.au> Subject: Wine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: shinjii@virusinfo.rdksupportinc.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, 24 Dec 2004 01:33:57 -0000 Just a quick thought on Wine ... It is presently set in the ports with the latest version which is all very well and good, except for those of us who dont run 5.3, so perhaps there could be an alteration done or an added port for wine so there is a version compat with older 4.x and 5.x systems that cant run the latest version of wine. -- Yours Sincerely Shinjii http://virusinfo.rdksupportinc.com From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 02:10:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE79A16A4CE for ; Fri, 24 Dec 2004 02:10:52 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 795B343D39 for ; Fri, 24 Dec 2004 02:10:52 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 276B651255; Thu, 23 Dec 2004 18:10:50 -0800 (PST) Date: Thu, 23 Dec 2004 18:10:50 -0800 From: Kris Kennaway To: shinjii@virusinfo.rdksupportinc.com Message-ID: <20041224021049.GA34494@xor.obsecurity.org> References: <200412241133.47629.spikey1101@iinet.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <200412241133.47629.spikey1101@iinet.net.au> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Wine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 02:10:52 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 24, 2004 at 11:33:47AM +1000, Warren Liddell wrote: > Just a quick thought on Wine ... It is presently set in the ports with th= e=20 > latest version which is all very well and good, except for those of us wh= o=20 > dont run 5.3, so perhaps there could be an alteration done or an added po= rt=20 > for wine so there is a version compat with older 4.x and 5.x systems that= =20 > cant run the latest version of wine. Perhaps there is..but you should talk to the port maintainer and/or software authors. Kris --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBy3qpWry0BWjoQKURAuirAJ97VDj63MWL1wfzXeVZs+oSRYT0ZgCffgPK a/JbptFqyG/ijyTdYWeSN/U= =z/TF -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 04:35:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A07016A4CE for ; Fri, 24 Dec 2004 04:35:45 +0000 (GMT) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3A5143D66 for ; Fri, 24 Dec 2004 04:35:44 +0000 (GMT) (envelope-from lists@jnielsen.net) Received: from [192.168.0.10] (jn@c-24-2-72-123.client.comcast.net [24.2.72.123]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id iBO4ZhXI048452 for ; Thu, 23 Dec 2004 20:35:44 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Thu, 23 Dec 2004 21:34:38 -0700 User-Agent: KMail/1.7.2 References: <200412221315.47189.lists@jnielsen.net> <20041223060854.GB28133@odin.ac.hmc.edu> <200412231542.11950.lists@jnielsen.net> In-Reply-To: <200412231542.11950.lists@jnielsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412232134.38577.lists@jnielsen.net> X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on ns1.jnielsen.net X-Virus-Status: Clean Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 04:35:45 -0000 On Thursday 23 December 2004 03:42 pm, John Nielsen wrote: > On Wednesday 22 December 2004 11:08 pm, Brooks Davis wrote: > > On Wed, Dec 22, 2004 at 08:48:31PM -0700, John Nielsen wrote: > > > What would be needed to simply have the controller recognized > > > and able to support UDMA 150 (or even 133)? > > > > At least in current, there's an nForce2 MCP device id that is supposed > > to support UDMA6 so I suspect you may just need to wait a bit and it > > will arrive. It's possiable you have a board with a non-standard > > PCI-id. You might make sure "pciconf -lv" shows that your controler > > shows a device ID of 0x008510de. If not, you may be a simple matter of > > adding it to the necessicary two lines. > > Thanks, I'll try booting off a -current snapshot and see what shows up. No difference in -current. After looking at the output of pciconf a little closer, I noticed that the standard IDE controller has the device ID you mentioned and it is recognized properly. The SATA controller has a device ID of 0x00e510de. My amateur hackery (consisting of adding entries to ata-pci.h and ata-chipset.c) yielded a nicer-looking identification of the controller at startup, but the drive is still being accessed using UDMA33. Anyway, thanks for the help. I'll keep my eyes open and play with it as I have time. JN From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 05:46:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14BBA16A4CE for ; Fri, 24 Dec 2004 05:46:25 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 696D343D1F for ; Fri, 24 Dec 2004 05:46:24 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.13.1/8.12.11) with ESMTP id iBO6B46E046088 for ; Fri, 24 Dec 2004 01:11:04 -0500 (EST) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost)iBO6B42e046085 for ; Fri, 24 Dec 2004 01:11:04 -0500 (EST) (envelope-from chuckr@chuckr.org) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Fri, 24 Dec 2004 01:11:04 -0500 (EST) From: Chuck Robey To: freebsd-current@FreeBSD.org Message-ID: <20041224010759.N1763@april.chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: fingerprints X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 05:46:25 -0000 Has there been any work on getting fingerprint readers working on FreeBSD? I *really* disilked the fact that (apparently) the only fingerprint reader is supplied via Microsoft, but beyond that, it's a USB device, which ought to mean, a simple implementation. I guess I have to read how USB works, but before I give too much time to it, I wanted to ask if anyone has done anything yet. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ---------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 07:27:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F81D16A4CE for ; Fri, 24 Dec 2004 07:27:08 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91B2443D39 for ; Fri, 24 Dec 2004 07:27:07 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id iBO7Qvrn062026; Fri, 24 Dec 2004 17:56:57 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 24 Dec 2004 17:56:56 +1030 User-Agent: KMail/1.7.1 References: <20041224010759.N1763@april.chuckr.org> In-Reply-To: <20041224010759.N1763@april.chuckr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart50177071.zVoWHCIJEy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412241756.56900.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Chuck Robey Subject: Re: fingerprints X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 07:27:08 -0000 --nextPart50177071.zVoWHCIJEy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 24 Dec 2004 16:41, Chuck Robey wrote: > Has there been any work on getting fingerprint readers working on FreeBSD? > I *really* disilked the fact that (apparently) the only fingerprint > reader is supplied via Microsoft, but beyond that, it's a USB device, > which ought to mean, a simple implementation. I guess I have to read how Ahaha.. Ahem, sorry.. USB !=3D simple. > USB works, but before I give too much time to it, I wanted to ask if > anyone has done anything yet. Ask the maker for specs on how to talk to it.. =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 --nextPart50177071.zVoWHCIJEy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBy8TA5ZPcIHs/zowRAglmAKCj9F2hBSrxqu3Ldtdf+MIiEHfGwQCggY1G DbH2EA1yaldb82rn9Dpj3hc= =0eHh -----END PGP SIGNATURE----- --nextPart50177071.zVoWHCIJEy-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 08:39:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEA1E16A4CE for ; Fri, 24 Dec 2004 08:39:03 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 550FC43D3F for ; Fri, 24 Dec 2004 08:39:03 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])iBO8cxe2225886 for ; Fri, 24 Dec 2004 03:39:01 -0500 Message-ID: <41CBD5A3.7080808@elischer.org> Date: Fri, 24 Dec 2004 00:38:59 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bluetooth and mobile phones (motorola) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 08:39:04 -0000 Anyone banged a Motorola V series phone together with a Bluetooth enabled FreeBSD box and seen what happenned? Looking for a good way of getting pictures off the cellphone.. emailing them to onself works but takes 1/ 50c each. (25 c per email + 1 c per KB) (Cingular in the US) (one sees why the cell phone companies are pushing cameraphones). 2/ a lot of pushing small buttons. There is a USB connector kit available and a bluetooth kit. Both require a PC with windows. If there is nothing known about the bluetooth I'll get the USB cable and throw it on the USB sniffer and see if something can't be done.. From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 09:41:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF36E16A4CE; Fri, 24 Dec 2004 09:41:50 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D1F43D41; Fri, 24 Dec 2004 09:41:37 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBO9fLTI004869; Fri, 24 Dec 2004 11:41:21 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 69956-01; Fri, 24 Dec 2004 11:41:20 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBO9fJts004863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Dec 2004 11:41:20 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBO9fRDv075982; Fri, 24 Dec 2004 11:41:27 +0200 (EET) (envelope-from ru) Date: Fri, 24 Dec 2004 11:41:27 +0200 From: Ruslan Ermilov To: Daniel Eriksson Message-ID: <20041224094127.GA75931@ip.net.ua> References: <20041223221047.GB6049@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 09:41:51 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 24, 2004 at 02:14:12AM +0100, Daniel Eriksson wrote: > Ruslan Ermilov wrote: >=20 > > Finally, I had time today to track it down to a single > > commit. So, the following change breaks my Promise > > SATA150 controller: >=20 > I'm running a Promise SATA150 TX4 on a recent 6-CURRENT > (2004.12.20.16.00.00) machine without any problems. I only have 3 discs > hooked up to it though (plus 2 more on the on-board VIA SATA controller). > Also, I had some problems with ACPI and ATA/SATA on this machine after the > last big commit (a few weeks ago) so I turned it off. You might want to t= ry > that if you haven't already. The machine is head-less, so I haven't tried > re-enabling ACPI since then. >=20 Nope, turning ACPI off doesn't make any difference except for assigning a different IRQ: : atapci0: port 0xffa0-0xffaf,0x376,0x= 170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 : ata0: channel #0 on atapci0 : ata1: channel #1 on atapci0 : -atapci1: port 0xd000-0xd07f,0xd400= -0xd40f,0xd800-0xd83f mem 0xfc960000-0xfc97ffff,0xfc99f000-0xfc99ffff irq 5= at device 8.0 on pci1 : +atapci1: port 0xd000-0xd07f,0xd400= -0xd40f,0xd800-0xd83f mem 0xfc960000-0xfc97ffff,0xfc99f000-0xfc99ffff irq 1= 1 at device 8.0 on pci1 : atapci1: failed: rid 0x20 is memory, requested 4 : ata2: channel #0 on atapci1 : ata3: channel #1 on atapci1 : ata4: channel #2 on atapci1 : ad0: 76319MB [155061/16/63] at ata0-master UDMA100 : ata1-slave: DMA limited to UDMA33, non-ATA66 cable or device : acd0: CDRW at ata1-slave UDMA33 : ata4-master: FAILURE - ATA_IDENTIFY timed out : ata4-master: FAILURE - ATA_IDENTIFY timed out : ata4-master: FAILURE - ATA_IDENTIFY timed out Besides, I love my ACPI, and it's a clear regression -- if I revert this commit, it all works again. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBy+RGqRfpzJluFF4RAmORAJ43zABgDa/OM9mN7RvETM2WOQyEoACfYQ34 FYjHNW5YLxanNu1dDvTBYRE= =LwXb -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 12:14:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D5116A4CE for ; Fri, 24 Dec 2004 12:14:11 +0000 (GMT) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF09543D5E for ; Fri, 24 Dec 2004 12:14:09 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id iBOCE0Lc066738; Fri, 24 Dec 2004 14:14:00 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.12.11/8.12.11) with ESMTP id iBOCDoxm044238; Fri, 24 Dec 2004 14:13:54 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <41CC07F6.3020601@ebs.gr> Date: Fri, 24 Dec 2004 14:13:42 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <41CBD5A3.7080808@elischer.org> In-Reply-To: <41CBD5A3.7080808@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: bluetooth and mobile phones (motorola) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 12:14:11 -0000 Julian Elischer wrote: > > Anyone banged a Motorola V series phone together with a Bluetooth > enabled FreeBSD box and seen what happenned? > > Looking for a good way of getting pictures off the cellphone.. > emailing them to onself works but takes > 1/ 50c each. (25 c per email + 1 c per KB) (Cingular in the US) > (one sees why the cell phone companies are pushing cameraphones). > 2/ a lot of pushing small buttons. > > There is a USB connector kit available and a bluetooth kit. > Both require a PC with windows. > > If there is nothing known about the bluetooth I'll get the > USB cable and throw it on the USB sniffer and see if something can't > be done.. It works with my Nokia 6600, so I can't see why it wouldn't work with a Motorola. The only thing is that setting up bluetooth (the stack, hcsecd and the OBEX server) is not very automated curently in FreeBSD, but there have been some useful suggestions in the freebsd-bluetooth list, not to mention the handbook chapter. If you get into trouble setting this up I could dig up the configuration files form my home machine and pass them on. Cheers, Panagiotis From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 14:57:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49DB316A4CE for ; Fri, 24 Dec 2004 14:57:46 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC64143D41 for ; Fri, 24 Dec 2004 14:57:45 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.13.1/8.12.11) with ESMTP id iBOFMImO048136; Fri, 24 Dec 2004 10:22:18 -0500 (EST) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost)iBOFMFF0048133; Fri, 24 Dec 2004 10:22:18 -0500 (EST) (envelope-from chuckr@chuckr.org) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Fri, 24 Dec 2004 10:22:15 -0500 (EST) From: Chuck Robey To: "Daniel O'Connor" In-Reply-To: <200412241756.56900.doconnor@gsoft.com.au> Message-ID: <20041224101921.X1763@april.chuckr.org> References: <20041224010759.N1763@april.chuckr.org> <200412241756.56900.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: fingerprints X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 14:57:46 -0000 On Fri, 24 Dec 2004, Daniel O'Connor wrote: > On Fri, 24 Dec 2004 16:41, Chuck Robey wrote: > > Has there been any work on getting fingerprint readers working on FreeBSD? > > I *really* disilked the fact that (apparently) the only fingerprint > > reader is supplied via Microsoft, but beyond that, it's a USB device, > > which ought to mean, a simple implementation. I guess I have to read how > > Ahaha.. > Ahem, sorry.. USB != simple. > > > USB works, but before I give too much time to it, I wanted to ask if > > anyone has done anything yet. > > Ask the maker for specs on how to talk to it.. Can't (and won't), it's Micrsoft, I won't stoop that low. There's only so many possibilities here, I'll just how to see how I can download whatever the mindless little thing has, and begin comparing with what it could be. The only problem is figuring out how to open it up in general, so I can get that listing. I'll figure it out, the usb site is on the web, it's got docs, I just hope they're not too huge. > > ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ---------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Thu Dec 23 15:01:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7671216A4CE for ; Thu, 23 Dec 2004 15:01:58 +0000 (GMT) Received: from sanne.nlnetlabs.nl (sanne.nlnetlabs.nl [213.154.224.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id D78CE43D5C for ; Thu, 23 Dec 2004 15:01:57 +0000 (GMT) (envelope-from ted@sanne.nlnetlabs.nl) Received: from sanne.nlnetlabs.nl (localhost [127.0.0.1]) by sanne.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id iBNF1s97003219; Thu, 23 Dec 2004 16:01:54 +0100 (CET) (envelope-from ted@sanne.nlnetlabs.nl) Received: (from ted@localhost) by sanne.nlnetlabs.nl (8.13.1/8.13.1/Submit) id iBNF1sSM003218; Thu, 23 Dec 2004 16:01:54 +0100 (CET) (envelope-from ted) Message-Id: <200412231501.iBNF1sSM003218@sanne.nlnetlabs.nl> From: ted@sanne.nlnetlabs.nl (Ted Lindgreen) Date: Thu, 23 Dec 2004 16:01:54 +0100 In-Reply-To: "Ted Lindgreen's message as of Dec 14, 17:02" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: freebsd-current@freebsd.org X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on sanne.nlnetlabs.nl X-Mailman-Approved-At: Fri, 24 Dec 2004 16:09:59 +0000 cc: Ted Lindgreen Subject: Re: acpi is broken since about 2004/12/01 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 23 Dec 2004 15:01:58 -0000 Following up on my previous posting: [Quoting Ted Lindgreen, on Dec 14, 17:02, in "acpi is broken since ..."] > Maksim Yevmenkin reported the problem already on Mon Dec 6 15:15:28 in > "help! acpi kills my laptop", and also Andrey Chernovache reported > it on Thu Dec 9 09:13:58 in "Lots of ACPI warnings with recent -current". This ACPI problem is caused by an update on 2004/12/01 called: "Vendor import of Intel ACPI-CA 20041119" The wlan_wep problem, which I encountered at the same time, appeared to be unrelated and fixed shortly after my previous posting. The new ACPI version no longer works around broken DSDT info, in which "implicit returns" are used. If the vendor of your hardware does not provide a new bios with fixed DSDT info (like Toshiba for instance) you have this problem. The workaround I found was to dump the DSDT (using an older kernel) into a file with acpidump(8). Then edit the .asl file to fix all the implicit returns. This means for instance: --- foo.asl Thu Dec 23 10:20:00 2004 +++ new.asl Thu Dec 23 15:15:23 2004 @@ -102,17 +102,17 @@ Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { - STAL (0x60) + Return (STAL (0x60)) } Method (_PRS, 0, NotSerialized) { - PRSL (0x60) + Return (PRSL (0x60)) } Method (_CRS, 0, NotSerialized) { - CRSL (0x60) + Return (CRSL (0x60)) } Etcetera, etcetera... You can easily find these errors by compiling the .asl file with: iasl foo.asl iasl(8) flags the problems with warnings (in contrast to the new ACPI code in the kernel, which now stumbles on them, causing the bootprocess to hang). When the new.asl file is warning-free, move the result of iasl to /boot: mv DSDT.aml /boot/acpi_dsdt.aml and tell the loader to use this instead of the bios: echo 'acpi_dsdt_load="YES"' >> /boot/loader.conf I sure hope that the workaround as present in the previous Intel ACPI-CA versions will return again, Regards, -- ted From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 00:17:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9C1E16A4CE; Fri, 24 Dec 2004 00:17:41 +0000 (GMT) Received: from sccimhc91.asp.att.net (sccimhc91.asp.att.net [63.240.76.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D3643D3F; Fri, 24 Dec 2004 00:17:41 +0000 (GMT) (envelope-from freebsd@nbritton.org) Received: from [192.168.1.10] (12-223-129-46.client.insightbb.com[12.223.129.46]) by sccimhc91.asp.att.net (sccimhc91) with ESMTP id <20041224001739i9100rfi18e>; Fri, 24 Dec 2004 00:17:40 +0000 Message-ID: <41CB6020.3050805@nbritton.org> Date: Thu, 23 Dec 2004 18:17:36 -0600 From: Nikolas Britton User-Agent: Mozilla Thunderbird 1.0 (X11/20041219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mervin McDougall References: <20041223224620.62812.qmail@web61205.mail.yahoo.com> In-Reply-To: <20041223224620.62812.qmail@web61205.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Dec 2004 16:09:59 +0000 cc: freebsd-current@freebsd.org cc: freebsd-newbies@freebsd.org cc: cyrille.lefevre@laposte.net Subject: Re: kern/71142; VESA 1024x768; (Poor Console resolution on Compaq 2103US) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 00:17:42 -0000 Mervin McDougall wrote: >I have one experience to share as a newbie, that of >trying to get a proper console resolution on my >laptop. I chose to stick with FreeBSD over Slackware >for my laptop for the simplicity in its init system >and fewer init levels, its ports and packages system >which reduces the stress of looking for a file and all >its dependencies and getting it downloaded, compiled >and using on my laptop and basically its speed of >booting- in 2/3 the time it takes slackware linux to >boot, bsd is at the loging prompt.However,getting the >proper console resolution was a pain as I favour >console over X. > >I tried recompiling the kernel including support for >Vesa by including options VESA and SC_PIXEL_MODE and >that didn't work.I tried compiling the kernel with >suppor for VGA_90WIDTH and that still did not provide >me with adequate space on my screen to get anything >else done. My console only the center of my screen and >only occupied a 1/3 rd of the entire screen. I was >very stressed until I cam across a website of someone >who had successfully installed FreeBSD 5.2.1 on a >similar laptop. I contacted him and he explained that >he had similar problem but got over the issue by >making use of a patch which allowed me to achieve >screen resolutions of 1024x768. > >I have gotten over the problem happily but there are >still some issues that the patch created in making use >of it as slower performance in switching from console >to X and the printing of error information when the >kernel is initiating vidcontrol but I get to use >console more often thankfully. > >I wish that the freebsd team would look into fixing >any errors in vidcontrol to get the problem with >screen resolutions on laptops fixed. I was able to do >this with ease using linux framebuffer settings with >slackware but had so much difficulty getting that done >under freebsd 5.3. > >I could have chosen to give up and simply use linux >but I like the way freebsd performs something about it >is just magically and wouldn't want to miss out on >using it. I just wish somethng could be done to better >the performance of the system as is and get rid of >some of those escape errors. or gett a better patch >from the freebsd team. > >If anyone has a similar laptop and wants to get some >specifics about what works and what doesn't feel free >to visit >http://demira.shopkeeper.de/~sascha/nx9005/ >its pretty informative. > >Mervin McDougall > > > > > (For FreeBSD current mailing list and Cyrille Lefevre): What is the current status of this patch, is there an updated version of this patch that address console slowness, etc., and when will it be MFC'd to 5-STABLE? (5.4_RELEASE?) ---------------- This is a problem with most ATI RAGE cards including my laptop (Armada 1750, ATI Rage LT Pro) I have successfully applied this patch to that system and can now use 1024x768 at the console, the patch is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71142 Please note that at Lines 790, 982, and 1000 are hard returns that brake the patch when run though the awk script so fix them before you run "qp2txt patch.eml | patch" or "patch Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBE6016A4CE for ; Fri, 24 Dec 2004 09:18:31 +0000 (GMT) Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E74F43D1F for ; Fri, 24 Dec 2004 09:18:31 +0000 (GMT) (envelope-from avalon@cairo.anu.edu.au) Received: from cairo.anu.edu.au (localhost [127.0.0.1]) by cairo.anu.edu.au (8.12.9/8.12.0) with ESMTP id iBO9IRWn028140 for ; Fri, 24 Dec 2004 20:18:30 +1100 (EST) Received: (from avalon@localhost) by cairo.anu.edu.au (8.12.9/8.12.0.Beta16) id iBO9IRlo028138 for current@freebsd.org; Fri, 24 Dec 2004 20:18:27 +1100 (EST) Date: Fri, 24 Dec 2004 20:18:27 +1100 (EST) From: Darren Reed Message-Id: <200412240918.iBO9IRlo028138@cairo.anu.edu.au> To: current@freebsd.org X-Mailman-Approved-At: Fri, 24 Dec 2004 16:09:59 +0000 Subject: IPFilter patched for SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 09:18:32 -0000 I've just committed some changes to IPFilter in FreeBSD-current that remove the "needs giant" flag and enables fine grained locking. I'd really like to hear back from anyone who can stress test this out on a multi-cpu machine. The locking used is the same as for Solaris and IRIX, so I'm relatively confident it shouldn't cause any deadlocks but I'd still like to see it tested. Merry Christmas, Darren From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 16:23:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A0716A4CE; Fri, 24 Dec 2004 16:23:31 +0000 (GMT) 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 6FB2243D1D; Fri, 24 Dec 2004 16:23:30 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBOGNPNv021747; Fri, 24 Dec 2004 17:23:27 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41CC425C.7050906@DeepCore.dk> Date: Fri, 24 Dec 2004 17:22:52 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> In-Reply-To: <20041224094127.GA75931@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@FreeBSD.ORG cc: Daniel Eriksson cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 16:23:31 -0000 Ruslan Ermilov wrote: >>>Finally, I had time today to track it down to a single >>>commit. So, the following change breaks my Promise >>>SATA150 controller: >> >>I'm running a Promise SATA150 TX4 on a recent 6-CURRENT >>(2004.12.20.16.00.00) machine without any problems. I only have 3 discs= >>hooked up to it though (plus 2 more on the on-board VIA SATA controller= ). >>Also, I had some problems with ACPI and ATA/SATA on this machine after = the >>last big commit (a few weeks ago) so I turned it off. You might want to= try >>that if you haven't already. The machine is head-less, so I haven't tri= ed >>re-enabling ACPI since then. >> > Nope, turning ACPI off doesn't make any difference except for assigning= > a different IRQ: OK, saw this thread a little late, but I committed some updates to this=20 area earlier today, let me know if that changes anything... --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 18:28:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C2BF16A4CE for ; Fri, 24 Dec 2004 18:28:15 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8927E43D3F for ; Fri, 24 Dec 2004 18:28:14 +0000 (GMT) (envelope-from avleeuwen@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so106349rnz for ; Fri, 24 Dec 2004 10:28:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=PeJJpWAOMumEEWz7umpNY8g1Di+wvC7ket9Swjblr986+RUG0Izgsi6s9B8+3eCIWkX5ngaD3LW+mtEl47Mq7LGU24I4vmm23ses8N/W4FxRO7fA2vtYW3TajxwgW9UwGHEYUseRujsfac3ceiT03vk1lpd7n9vjqZwy1wLZRq8= Received: by 10.38.26.40 with SMTP id 40mr305655rnz; Fri, 24 Dec 2004 10:28:11 -0800 (PST) Received: by 10.38.206.10 with HTTP; Fri, 24 Dec 2004 10:28:11 -0800 (PST) Message-ID: Date: Fri, 24 Dec 2004 19:28:11 +0100 From: Arjan Van Leeuwen To: Darren Reed In-Reply-To: <200412240918.iBO9IRlo028138@cairo.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200412240918.iBO9IRlo028138@cairo.anu.edu.au> cc: current@freebsd.org Subject: Re: IPFilter patched for SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Arjan Van Leeuwen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 18:28:15 -0000 Hi Darren, On Fri, 24 Dec 2004 20:18:27 +1100 (EST), Darren Reed wrote: > > I've just committed some changes to IPFilter in FreeBSD-current that > remove the "needs giant" flag and enables fine grained locking. > > I'd really like to hear back from anyone who can stress test this out > on a multi-cpu machine. The locking used is the same as for Solaris > and IRIX, so I'm relatively confident it shouldn't cause any deadlocks > but I'd still like to see it tested. Thanks, that's a nice christmas present! I'm getting some build errors though: cc -O2 -pipe -DUSE_INET6 -I/usr/src/sys/modules/ipfilter/../../contrib/ipfilter -DIPFILTER=1-DIPFILTER_LKM -DIPFILTER_LOG -DPFIL_HOOKS -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/ipfilter/../../contrib/ipfilter -include /usr/obj/usr/src/sys/VINCENT/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/VINCENT -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 /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c In file included from /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:109: /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined :6:1: warning: this is the location of the previous definition /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex'undeclared (first use in this function) /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': /usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/modules/ipfilter. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/VINCENT. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Arjan > > Merry Christmas, > Darren > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 19:21:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CB1716A4CE; Fri, 24 Dec 2004 19:21:57 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2804043D31; Fri, 24 Dec 2004 19:21:57 +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.1/8.13.1) with ESMTP id iBOJLun7038633; Fri, 24 Dec 2004 14:21:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBOJLuWB043204; Fri, 24 Dec 2004 14:21:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 47AFD7306E; Fri, 24 Dec 2004 14:21:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041224192156.47AFD7306E@freebsd-current.sentex.ca> Date: Fri, 24 Dec 2004 14:21:56 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 19:21:57 -0000 TB --- 2004-12-24 18:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-24 18:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-12-24 18:00:00 - checking out the source tree TB --- 2004-12-24 18:00:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-12-24 18:00:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-24 18:06:06 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-24 18:06:06 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-24 18:06:06 - /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 --- 2004-12-24 19:12:39 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-24 19:12:39 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-12-24 19:12:39 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 24 19:12:39 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined :5:1: warning: this is the location of the previous definition /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-12-24 19:21:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-24 19:21:56 - ERROR: failed to build generic kernel TB --- 2004-12-24 19:21:56 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 20:45:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D516616A4CE; Fri, 24 Dec 2004 20:45:53 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2C343D5D; Fri, 24 Dec 2004 20:45:53 +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.1/8.13.1) with ESMTP id iBOKjqIG096549; Fri, 24 Dec 2004 15:45:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBOKjq7k008577; Fri, 24 Dec 2004 15:45:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2A5277306E; Fri, 24 Dec 2004 15:45:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041224204552.2A5277306E@freebsd-current.sentex.ca> Date: Fri, 24 Dec 2004 15:45:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 20:45:54 -0000 TB --- 2004-12-24 19:21:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-24 19:21:56 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-12-24 19:21:56 - checking out the source tree TB --- 2004-12-24 19:21:56 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-12-24 19:21:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-24 19:28:03 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-24 19:28:03 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-12-24 19:28:03 - /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 --- 2004-12-24 20:34:49 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-24 20:34:49 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-12-24 20:34:49 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 24 20:34:50 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined :6:1: warning: this is the location of the previous definition /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-12-24 20:45:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-24 20:45:51 - ERROR: failed to build generic kernel TB --- 2004-12-24 20:45:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 22:08:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B96F616A4CE; Fri, 24 Dec 2004 22:08:34 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0EDC43D4C; Fri, 24 Dec 2004 22:08:33 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBOM8RGn051630; Sat, 25 Dec 2004 00:08:27 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 48567-10; Sat, 25 Dec 2004 00:08:24 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBOM8DWC051622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Dec 2004 00:08:13 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBOM8Lwc018370; Sat, 25 Dec 2004 00:08:21 +0200 (EET) (envelope-from ru) Date: Sat, 25 Dec 2004 00:08:21 +0200 From: Ruslan Ermilov To: S?ren Schmidt Message-ID: <20041224220821.GB86330@ip.net.ua> References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <41CC425C.7050906@DeepCore.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@freebsd.org cc: Daniel Eriksson cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 22:08:34 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 24, 2004 at 05:22:52PM +0100, S?ren Schmidt wrote: > OK, saw this thread a little late, but I committed some updates to this= =20 > area earlier today, let me know if that changes anything... >=20 Unfortunately not. With $FreeBSD: src/sys/dev/ata/ata-chipset.c,v 1.97 2004/12/24 13:36:04 sos Exp $ $FreeBSD: src/sys/dev/ata/ata-lowlevel.c,v 1.51 2004/12/24 13:38:25 sos Exp= $ I still get, atapci0: port 0xffa0-0xffaf,0x376,0x170= -0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xd000-0xd07f,0xd400-0x= d40f,0xd800-0xd83f mem 0xfc960000-0xfc97ffff,0xfc99f000-0xfc99ffff irq 5 at= device 8.0 on pci1 atapci1: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 ata4: channel #2 on atapci1 ad0: 76319MB [155061/16/63] at ata0-master UDMA100 ata1-slave: DMA limited to UDMA33, non-ATA66 cable or device acd0: CDRW at ata1-slave UDMA33 ata4-master: FAILURE - ATA_IDENTIFY timed out ata4-master: FAILURE - ATA_IDENTIFY timed out ata4-master: FAILURE - ATA_IDENTIFY timed out followed by the instant panic. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzJNVqRfpzJluFF4RAsRtAJ4xh2d6rnj+TLVXUJoAAMLsgZnC3wCgi0yc 9cv/4FcyptsEz0eRbmzpQKA= =pBcf -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 22:11:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2B3F16A4CE; Fri, 24 Dec 2004 22:11:21 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BDCE43D45; Fri, 24 Dec 2004 22:11:21 +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.1/8.13.1) with ESMTP id iBOMBL6w046472; Fri, 24 Dec 2004 17:11:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBOMBLOL078286; Fri, 24 Dec 2004 17:11:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EBB087306E; Fri, 24 Dec 2004 17:11:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041224221120.EBB087306E@freebsd-current.sentex.ca> Date: Fri, 24 Dec 2004 17:11:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 22:11:22 -0000 TB --- 2004-12-24 20:45:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-24 20:45:52 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-12-24 20:45:52 - checking out the source tree TB --- 2004-12-24 20:45:52 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-12-24 20:45:52 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-24 20:52:03 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-24 20:52:03 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-12-24 20:52:03 - /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 --- 2004-12-24 21:58:47 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-24 21:58:47 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-12-24 21:58:47 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 24 21:58:48 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined :6:1: warning: this is the location of the previous definition /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-12-24 22:11:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-24 22:11:20 - ERROR: failed to build generic kernel TB --- 2004-12-24 22:11:20 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 22:45:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DE4C16A4CE; Fri, 24 Dec 2004 22:45:20 +0000 (GMT) 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 7F7A343D1F; Fri, 24 Dec 2004 22:45:19 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iBOMjFPH025112; Fri, 24 Dec 2004 23:45:17 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41CC9BDA.7020203@DeepCore.dk> Date: Fri, 24 Dec 2004 23:44:42 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> In-Reply-To: <20041224220821.GB86330@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@FreeBSD.ORG cc: Daniel Eriksson cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 22:45:20 -0000 Ruslan Ermilov wrote: > On Fri, Dec 24, 2004 at 05:22:52PM +0100, S?ren Schmidt wrote: >=20 >>OK, saw this thread a little late, but I committed some updates to this= =20 >>area earlier today, let me know if that changes anything... >> > Unfortunately not. With >=20 > $FreeBSD: src/sys/dev/ata/ata-chipset.c,v 1.97 2004/12/24 13:36:04 sos = Exp $ > $FreeBSD: src/sys/dev/ata/ata-lowlevel.c,v 1.51 2004/12/24 13:38:25 sos= Exp $ >=20 > I still get, >=20 > atapci0: port 0xffa0-0xffaf,0x376,0= x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > atapci1: port 0xd000-0xd07f,0xd40= 0-0xd40f,0xd800-0xd83f mem 0xfc960000-0xfc97ffff,0xfc99f000-0xfc99ffff ir= q 5 at device 8.0 on pci1 > atapci1: failed: rid 0x20 is memory, requested 4 > ata2: channel #0 on atapci1 > ata3: channel #1 on atapci1 > ata4: channel #2 on atapci1 > ad0: 76319MB [155061/16/63] at ata0-master UDMA100 > ata1-slave: DMA limited to UDMA33, non-ATA66 cable or device > acd0: CDRW at ata1-slave UDMA33 > ata4-master: FAILURE - ATA_IDENTIFY timed out > ata4-master: FAILURE - ATA_IDENTIFY timed out > ata4-master: FAILURE - ATA_IDENTIFY timed out >=20 > followed by the instant panic. The panic message and traceback would be helpfull, as I have a semilar=20 setup here that works "just fine" (tm)... --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 23:07:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C60516A4E1; Fri, 24 Dec 2004 23:07:08 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84FB843D39; Fri, 24 Dec 2004 23:07:06 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from gothmog.gr (patr530-a130.otenet.gr [212.205.215.130]) iBON6sA9023014; Sat, 25 Dec 2004 01:06:58 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id iBON6qGO070680; Sat, 25 Dec 2004 01:06:52 +0200 (EET) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id iBON6diO070592; Sat, 25 Dec 2004 01:06:39 +0200 (EET) (envelope-from keramida@linux.gr) Date: Sat, 25 Dec 2004 01:06:39 +0200 From: Giorgos Keramidas To: FreeBSD Tinderbox Message-ID: <20041224230639.GA64800@gothmog.gr> References: <20041224221120.EBB087306E@freebsd-current.sentex.ca> <20041224222601.GB39539@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041224222601.GB39539@gothmog.gr> cc: current@freebsd.org cc: i386@freebsd.org Subject: Re: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 23:07:09 -0000 On 2004-12-25 00:26, Giorgos Keramidas wrote: > On 2004-12-24 17:11, FreeBSD Tinderbox wrote: > > >>> stage 3.2: building everything > > [...] > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined > > :6:1: warning: this is the location of the previous definition > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': > > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) > > *** Error code 1 > > Apparently, ipf_rw is not defined for FreeBSD builds of `fil.c'. > The following will probably fix the build (I'm running a test build now): > > % gothmog:/usr/src# cvs -q di -u sys/contrib/ipfilter/netinet > % Index: sys/contrib/ipfilter/netinet/fil.c > % =================================================================== > % RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/fil.c,v > % retrieving revision 1.40 > % diff -u -r1.40 fil.c > % --- sys/contrib/ipfilter/netinet/fil.c 16 Dec 2004 21:02:15 -0000 1.40 > % +++ sys/contrib/ipfilter/netinet/fil.c 24 Dec 2004 22:19:19 -0000 > % @@ -115,10 +115,10 @@ > % # define FR_VERBOSE(verb_pr) > % # define FR_DEBUG(verb_pr) > % # define IPLLOG(a, c, d, e) ipflog(a, c, d, e) > % -# if SOLARIS || defined(__sgi) > % +# if SOLARIS || defined(__sgi) || defined(__FreeBSD_version) > % extern KRWLOCK_T ipf_mutex, ipf_auth, ipf_nat; > % extern kmutex_t ipf_rw; > % -# endif /* SOLARIS || __sgi */ > % +# endif /* SOLARIS || __sgi || __FreeBSD_version */ > % #endif /* _KERNEL */ > % > % > % gothmog:/usr/src# I sent this message too hastily. The full fix for the buildkernel problems of today's CURRENT is a bit longer: %%% gothmog:/usr/src# cvs -q di -u sys/contrib/ipfilter Index: sys/contrib/ipfilter/netinet/fil.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/fil.c,v retrieving revision 1.40 diff -u -r1.40 fil.c --- sys/contrib/ipfilter/netinet/fil.c 16 Dec 2004 21:02:15 -0000 1.40 +++ sys/contrib/ipfilter/netinet/fil.c 24 Dec 2004 22:49:58 -0000 @@ -115,10 +115,10 @@ # define FR_VERBOSE(verb_pr) # define FR_DEBUG(verb_pr) # define IPLLOG(a, c, d, e) ipflog(a, c, d, e) -# if SOLARIS || defined(__sgi) +# if SOLARIS || defined(__sgi) || (__FreeBSD_version >= 500043) extern KRWLOCK_T ipf_mutex, ipf_auth, ipf_nat; extern kmutex_t ipf_rw; -# endif /* SOLARIS || __sgi */ +# endif /* SOLARIS || __sgi || __FreeBSD_version */ #endif /* _KERNEL */ Index: sys/contrib/ipfilter/netinet/ip_fil.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_fil.c,v retrieving revision 1.49 diff -u -r1.49 ip_fil.c --- sys/contrib/ipfilter/netinet/ip_fil.c 29 Sep 2004 04:54:32 -0000 1.49 +++ sys/contrib/ipfilter/netinet/ip_fil.c 24 Dec 2004 22:49:49 -0000 @@ -171,6 +171,9 @@ extern int tcp_mtudisc; extern kmutex_t ipf_rw; extern KRWLOCK_T ipf_mutex; +# elif (__FreeBSD_version >= 500043) +extern kmutex_t ipf_rw; +extern KRWLOCK_T ipf_mutex; # endif #else void init_ifp __P((void)); gothmog:/usr/src# %%% From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 23:30:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1126416A4CE; Fri, 24 Dec 2004 23:30:22 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5421B43D49; Fri, 24 Dec 2004 23:30:21 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBONUFZG055261; Sat, 25 Dec 2004 01:30:15 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 18423-18; Sat, 25 Dec 2004 01:30:14 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iBONUE9s055257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Dec 2004 01:30:14 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iBONUM83043483; Sat, 25 Dec 2004 01:30:22 +0200 (EET) (envelope-from ru) Date: Sat, 25 Dec 2004 01:30:21 +0200 From: Ruslan Ermilov To: S?ren Schmidt Message-ID: <20041224233021.GA43419@ip.net.ua> References: <20041223221047.GB6049@ip.net.ua> <20041224094127.GA75931@ip.net.ua> <41CC425C.7050906@DeepCore.dk> <20041224220821.GB86330@ip.net.ua> <41CC9BDA.7020203@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <41CC9BDA.7020203@DeepCore.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: current@FreeBSD.org cc: Daniel Eriksson cc: Soren Schmidt Subject: Re: ATA regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 23:30:22 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 24, 2004 at 11:44:42PM +0100, S?ren Schmidt wrote: > Ruslan Ermilov wrote: > >On Fri, Dec 24, 2004 at 05:22:52PM +0100, S?ren Schmidt wrote: > > > >>OK, saw this thread a little late, but I committed some updates to this= =20 > >>area earlier today, let me know if that changes anything... > >> > >Unfortunately not. With > > > >$FreeBSD: src/sys/dev/ata/ata-chipset.c,v 1.97 2004/12/24 13:36:04 sos E= xp=20 > >$ > >$FreeBSD: src/sys/dev/ata/ata-lowlevel.c,v 1.51 2004/12/24 13:38:25 sos= =20 > >Exp $ > > > >I still get, > > > >atapci0: port=20 > >0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 > >ata0: channel #0 on atapci0 > >ata1: channel #1 on atapci0 > >atapci1: port=20 > >0xd000-0xd07f,0xd400-0xd40f,0xd800-0xd83f mem=20 > >0xfc960000-0xfc97ffff,0xfc99f000-0xfc99ffff irq 5 at device 8.0 on pci1 > >atapci1: failed: rid 0x20 is memory, requested 4 > >ata2: channel #0 on atapci1 > >ata3: channel #1 on atapci1 > >ata4: channel #2 on atapci1 > >ad0: 76319MB [155061/16/63] at ata0-master UDMA100 > >ata1-slave: DMA limited to UDMA33, non-ATA66 cable or device > >acd0: CDRW at ata1-slave UDMA33 > >ata4-master: FAILURE - ATA_IDENTIFY timed out > >ata4-master: FAILURE - ATA_IDENTIFY timed out > >ata4-master: FAILURE - ATA_IDENTIFY timed out > > > >followed by the instant panic. >=20 > The panic message and traceback would be helpfull, as I have a semilar=20 > setup here that works "just fine" (tm)... >=20 I don't have a serial console attached here, so below was cut-n-pasted by hands: : ata4-master: FAILURE - ATA_IDENTIFY timed out : ata4-master: FAILURE - ATA_IDENTIFY timed out : ata4-master: FAILURE - ATA_IDENTIFY timed out : Trying to mount root from ufs:/dev/ad0a : ata4-master: FAILURE - ATA_IDENTIFY timed out : Slab at 0xffffff003d7e1f38, freei 15 =3D 0. : panic: Duplicate free of item 0xffffff003d7e1ca8 from zone 0xffffff003ffa= f500(g_bio) :=20 : cpuid =3D 0 : KDB: enter: panic : [thread pid 3 tid 100029 ] : Stopped at kdb_enter+0x2f: nop : db> where : kdb_enter() at ... : panic() at ... : uma_dbg_free() at ... : uma_zfree_arg() at ... : g_disk_done() at ... : ad_done() at ... : ata_completed() at ... : g_io_schedule_up() at ... : g_up_procbody() at ... : fork_exit() at ... : fork_trampoline() at ... : --- trap 0, rip =3D 0, rsp =3D 0xffffffffa509dd00, rbp =3D 0 --- : db> A panic can be avoided by reverting the ata-queue.c,v 1.41. But even after this, I get ATA_IDENTIFY failures. And as I said, reverting to a somewhat earlier version makes it all work. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzKaNqRfpzJluFF4RAlhyAJoCQa5tNYwEyQMdCzoZYAs1NIc+rQCgl/xP A0U99AySi8O4iYjwhDtUuwo= =oyF+ -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 23:34:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E78016A4CE; Fri, 24 Dec 2004 23:34:35 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEFD743D2D; Fri, 24 Dec 2004 23:34:34 +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.1/8.13.1) with ESMTP id iBONYY0m003609; Fri, 24 Dec 2004 18:34:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id iBONYYtT033951; Fri, 24 Dec 2004 18:34:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 110317306E; Fri, 24 Dec 2004 18:34:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041224233433.110317306E@freebsd-current.sentex.ca> Date: Fri, 24 Dec 2004 18:34:33 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 23:34:35 -0000 TB --- 2004-12-24 22:11:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-24 22:11:21 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-12-24 22:11:21 - checking out the source tree TB --- 2004-12-24 22:11:21 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-12-24 22:11:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-24 22:17:36 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-24 22:17:36 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-12-24 22:17:36 - /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 --- 2004-12-24 23:24:48 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-24 23:24:48 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-12-24 23:24:48 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Dec 24 23:24:48 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined :6:1: warning: this is the location of the previous definition /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-12-24 23:34:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-24 23:34:33 - ERROR: failed to build generic kernel TB --- 2004-12-24 23:34:33 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 00:24:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26EE216A4CE for ; Sat, 25 Dec 2004 00:24:08 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id D312443D48 for ; Sat, 25 Dec 2004 00:24:07 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 2132D530C; Sat, 25 Dec 2004 01:24:03 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 505525308; Sat, 25 Dec 2004 01:23:31 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id E2950B874; Sat, 25 Dec 2004 01:23:30 +0100 (CET) To: John Nielsen References: <200412221315.47189.lists@jnielsen.net> <20041223060854.GB28133@odin.ac.hmc.edu> <200412231542.11950.lists@jnielsen.net> <200412232134.38577.lists@jnielsen.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 25 Dec 2004 01:23:30 +0100 In-Reply-To: <200412232134.38577.lists@jnielsen.net> (John Nielsen's message of "Thu, 23 Dec 2004 21:34:38 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: freebsd-current@freebsd.org Subject: Re: nForce2 RAID MCP (SATA) support? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 00:24:08 -0000 John Nielsen writes: > The SATA controller has a device ID of 0x00e510de. ...so it's not a real SATA controller at all, but a PATA controller with a converter chip in front. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 00:37:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7904516A4CE for ; Sat, 25 Dec 2004 00:37:01 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 321DD43D48 for ; Sat, 25 Dec 2004 00:37:01 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id B1722530C; Sat, 25 Dec 2004 01:36:59 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id D43875308; Sat, 25 Dec 2004 01:36:31 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 8BA44B874; Sat, 25 Dec 2004 01:36:31 +0100 (CET) To: Chuck Robey References: <20041224010759.N1763@april.chuckr.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 25 Dec 2004 01:36:31 +0100 In-Reply-To: <20041224010759.N1763@april.chuckr.org> (Chuck Robey's message of "Fri, 24 Dec 2004 01:11:04 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: freebsd-current@FreeBSD.org Subject: Re: fingerprints X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 00:37:01 -0000 Chuck Robey writes: > Has there been any work on getting fingerprint readers working on FreeBSD? > I *really* disilked the fact that (apparently) the only fingerprint > reader is supplied via Microsoft, but beyond that, it's a USB device, > which ought to mean, a simple implementation. I guess I have to read how > USB works, but before I give too much time to it, I wanted to ask if > anyone has done anything yet. AFAIK, fingerprint readers (a) rely on a lot of proprietary, patented software to actually compare the captured fingerprint to the stored fingerprint, and (b) are ridiculously easy to fool (some have been known to read and accept latent prints left by the previous user when a plastic bag filled with warm water is pressed down on the plate). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 01:25:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE1316A4CF; Sat, 25 Dec 2004 01:25:11 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4061943D49; Sat, 25 Dec 2004 01:25:11 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBP1PAjQ054176; Fri, 24 Dec 2004 20:25:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id iBP1P9vQ060557; Fri, 24 Dec 2004 20:25:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 250837306E; Fri, 24 Dec 2004 20:25:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20041225012510.250837306E@freebsd-current.sentex.ca> Date: Fri, 24 Dec 2004 20:25:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 14:53:11 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2004 01:25:12 -0000 TB --- 2004-12-24 23:34:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-12-24 23:34:34 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-12-24 23:34:34 - checking out the source tree TB --- 2004-12-24 23:34:34 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-12-24 23:34:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-12-24 23:40:26 - building world (CFLAGS=-O2 -pipe) TB --- 2004-12-24 23:40:26 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-12-24 23:40:26 - /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 --- 2004-12-25 01:11:19 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-12-25 01:11:19 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-12-25 01:11:19 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Dec 25 01:11:19 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined :6:1: warning: this is the location of the previous definition /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules/ipfilter. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-12-25 01:25:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-12-25 01:25:09 - ERROR: failed to build generic kernel TB --- 2004-12-25 01:25:09 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 01:42:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 662AE16A4CE; Sat, 25 Dec 2004 01:42:02 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BAAB43D2F; Sat, 25 Dec 2004 01:42:02 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7DD53512C1; Fri, 24 Dec 2004 17:42:08 -0800 (PST) Date: Fri, 24 Dec 2004 17:42:08 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20041225014208.GB14172@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: phk@FreeBSD.org Subject: fstat triggered INVARIANTS panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 01:42:02 -0000 --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I ran fstat | more on a SMP 6.0 machine with kernel from about a month ago, which had a lot of files open. It panicked with: panic: vm_fault: fau and got no further on the console, but I was able to break to DBB and obtain the following traceback from fstat: db> tr 94874 Tracing pid 94874 tid 100815 td 0xc9ec1780 sched_switch(c9ec1780,c34dc480,1,11a,88a1da96) at sched_switch+0x105 mi_switch(6,c34dc480,c06d4ca0,271,c34dc5d0) at mi_switch+0x1d3 maybe_preempt(c34dc480,1,c06d4c85,3d6,46) at maybe_preempt+0x11d sched_add(c34dc480,4,c06d4ca0,1ce,c9ec1780,0,c06d11f3,197,197,c06d11f3) at sched_add+0x299 setrunqueue(c34dc480,4,c06d11f3,197,c077a900) at setrunqueue+0x109 ithread_schedule(c34d4380,0,eed96788,a0f1b,c9ec1780) at ithread_schedule+0xaf intr_execute_handlers(c34d2ea8,eed967b8,eed96810,c0686583,45) at intr_execute_handlers+0x74 lapic_handle_intr(45) at lapic_handle_intr+0x2d Xapic_isr2() at Xapic_isr2+0x33 --- interrupt, eip = 0xc0519495, esp = 0xeed967fc, ebp = 0xeed96810 --- critical_exit(c0768120,0,c06ea261,a23,1) at critical_exit+0x75 siocnputc(c071b960,75,5,75,eed9696c) at siocnputc+0x9b cnputc(75,10,1,0,c06d396c) at cnputc+0x65 putchar(75,eed9696c,c0524e6c,30,13) at putchar+0xa8 kvprintf(c06d3963,c0524780,eed9696c,a,eed96990) at kvprintf+0x87d printf(c06d3963,c072c680,c06e688a,eed969bc,c9ec1780) at printf+0x54 panic(c06e688a,deae6000,1,eed96aa8,eed96a98) at panic+0xe1 vm_fault(c1059000,deae6000,1,0,c9ec1780) at vm_fault+0x1327 trap_pfault(deae6000,c9ec1780,eed96ba8,c050e2c3,deae6000) at trap_pfault+0x82 trap(c06e0018,10,c1050010,8058f20,deae5ffe) at trap+0x363 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0697f2a, esp = 0xeed96bcc, ebp = 0xeed96c04 --- generic_copyout(deadc0de,7ab7037c,eed96c84,54,5964d000) at generic_copyout+0x36 memrw(c34fad00,eed96c84,0,398,7ab7037c) at memrw+0x18a devfs_read_f(c51773b8,eed96c84,ca75c800,0,c9ec1780) at devfs_read_f+0x142 dofileread(4,804f000,7ab7037c,ffffffff,ffffffff) at dofileread+0x92 read(c9ec1780,eed96d14,c,3ff,3) at read+0x75 syscall(2f,2f,2f,7ab7037c,80b1078) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x280d347f, esp = 0xbfbfe34c, ebp = 0xbfbfe378 --- Note the deadc0de in generic_copyout(). There seem to be several other bugs here that show off the well-known brokenness of panic() and related code on SMP machines. Kris --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzMVwWry0BWjoQKURApMeAKDko197FsfHkFxkK7xMwa+0V0VhgACg2uvy cPzEL8Md2JuO3lYr85AocVY= =bGce -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 01:45:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49ED116A4CE; Sat, 25 Dec 2004 01:45:45 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA5343D2D; Sat, 25 Dec 2004 01:45:45 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B892C514EE; Fri, 24 Dec 2004 17:45:51 -0800 (PST) Date: Fri, 24 Dec 2004 17:45:51 -0800 From: Kris Kennaway To: Kris Kennaway Message-ID: <20041225014551.GA14267@xor.obsecurity.org> References: <20041225014208.GB14172@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20041225014208.GB14172@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: phk@FreeBSD.org Subject: Re: fstat triggered INVARIANTS panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 01:45:45 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 24, 2004 at 05:42:08PM -0800, Kris Kennaway wrote: > I ran fstat | more on a SMP 6.0 machine with kernel from about a month > ago, which had a lot of files open. It panicked with: >=20 > panic: vm_fault: fau I reproduced it on another SMP machine with 6.0 dated from a few days ago: panic: vm_fault: fault on nofault entry, addr: deae2000 cpuid =3D 2 KDB: enter: panic [thread pid 23563 tid 100231 ] Stopped atK kdb_enter+0x32: leave _sich(1,,c06312e0 ti_sith+0x0 rk_mpoline)t fork_tramone0x1, ei =3D 0, ep =3D xa0fd7, bp 0- -db> db> Which did at least manage to display the entire panic string and enter DDB, but then it locked up. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzMZPWry0BWjoQKURAk2OAJ4qvWTdj2Tm2dQH3JEQm9VurgD0jgCg551T LpxIYRUHtnDs8+PN5V4a0Os= =Ubge -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 05:52:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42EED16A4CE for ; Sat, 25 Dec 2004 05:52:23 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17B6E43D1D for ; Sat, 25 Dec 2004 05:52:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 79BD151288; Fri, 24 Dec 2004 21:52:33 -0800 (PST) Date: Fri, 24 Dec 2004 21:52:33 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20041225055233.GA77161@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: mi_switch: did not reenter debugger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 05:52:23 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline -current updated a few hours ago: # sysctl debug.kdb.stop_cpus=0 debug.kdb.stop_cpus: 1 -> 0 # ~KDB: enter: Break sequence on console [thread pid 11 tid 100004 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> cont KDB: stack backtrace: ^Bmi_switch(2,0,c06e7f4b,24f,0) at mi_switch+0x31d critical_exit(c0734020,24d,0,ea07ec60,c347f730) at critical_exit+0xd3 intr_execute_handlers(c0734020,ea07ec78,c3504d00,ea07ec70,0) at intr_execute_handlers+0x130 atpic_handle_intr(0) at atpic_handle_intr+0x53 Xatpic_intr0() at Xatpic_intr0+0x20 --- interrupt, eip = 0xc0691855, esp = 0xea07ecbc, ebp = 0xea07ecbc --- acpi_cpu_c1(c347f730,fffffffe,0,ea07ece4,c051d4f2) at acpi_cpu_c1+0x5 acpi_cpu_idle(c073e9c0,2,c06e437c,73,c06e7f4b) at acpi_cpu_idle+0x180 idle_proc(0,ea07ed48,c06e4254,30e,ffffffff) at idle_proc+0x95 fork_exit(c04f1c80,0,ea07ed48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xea07ed7c, ebp = 0 --- panic: mi_switch: did not reenter debugger cpuid = 0 KDB: enter: panic [thread pid 12 tid 100005 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi kris --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzQAhWry0BWjoQKURAqT9AJ9KGzq8gHbXgTZMLsoLVZok+kgPQACeM/hT 9pMFKcm7biAlE1bQzVgUcvs= =VTqI -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 07:00:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DD016A4CF; Sat, 25 Dec 2004 07:00:21 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D43343D2D; Sat, 25 Dec 2004 07:00:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8DC22512C2; Fri, 24 Dec 2004 23:00:22 -0800 (PST) Date: Fri, 24 Dec 2004 23:00:22 -0800 From: Kris Kennaway To: mohans , ps@FreeBSD.org, current@FreeBSD.org Message-ID: <20041225070022.GA93123@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 07:00:21 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Since updating pointyhat to tonight's 6.0 sources (previously from about a month ago), I'm having processes locking up in state nfsreq. I confirmed that directio was disabled. This is a cvs update from repoman (mounted via NFS with the following options: repoman:/r /repoman/r nfs ro,bg,intr,soft,nodev,nosuid 0 00 db> tr 22402 Tracing pid 22402 tid 100161 td 0xc3a99170 sched_switch(c3a99170,0,1,120,b08c87ee) at sched_switch+0x115 mi_switch(1,0,c06e61e4,1ab,1) at mi_switch+0x1d3 sleepq_switch(1,c06e2b19,18e,1,1) at sleepq_switch+0x10d sleepq_wait_sig(c7acb980,0,c06e3e0f,dc,0) at sleepq_wait_sig+0xf msleep(c7acb980,c076f520,153,c06f1e45,0) at msleep+0x21e nfs_request(c39c1cf0,c4355c00,3,c3a99170,c3c0b300) at nfs_request+0x762 nfs_lookup(ee15fb84,c3a99170,c3a99170,c3a99170,ee15fc38) at nfs_lookup+0x2f8 lookup(ee15fc24,c35bb400,0,a7,8) at lookup+0x274 namei(ee15fc24,108,c06e3d30,8,c073b9c8) at namei+0x27d stat(c3a99170,ee15fd14,c06fecb7,3ad,2) at stat+0x4f syscall(2f,80c002f,bfbf002f,80ce0e0,283aaf60) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x28316b1f, esp = 0xbfbfeb8c, ebp = 0xbfbfec08 --- db> show lockedvnods Locked vnodes 0xc5ccd9b4: tag ufs, type VDIR usecount 6, writecount 0, refcount 9 mountedhere 0 flags (VV_OBJBUF) lock type ufs: EXCL (count 1) by thread 0xc3cdc170 (pid 5840) ino 14110529, on dev twed0s1f (232, 7) 0xc5512114: tag ufs, type VREG usecount 1, writecount 0, refcount 240 mountedhere 0 flags (VV_OBJBUF) lock type ufs: EXCL (count 1) by thread 0xc9bc85c0 (pid 4717) ino 35135903, on dev twed0s1f (232, 7) 0xc6ebb9b4: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_OBJBUF) lock type ufs: EXCL (count 1) by thread 0xc9bc8cf0 (pid 4700) ino 16275165, on dev twed0s1f (232, 7) 0xc79f8564: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_OBJBUF) lock type ufs: EXCL (count 1) by thread 0xc3c78170 (pid 5835) ino 17405819, on dev twed0s1f (232, 7) 0xc5d3a8a0: tag ufs, type VNON usecount 1, writecount 0, refcount 0 mountedhere 0 lock type ufs: EXCL (count 1) by thread 0xc3cdc170 (pid 5840) ino 14146443, on dev twed0s1f (232, 7) 0xc39c1cf0: tag nfs, type VDIR usecount 3, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT) lock type nfs: EXCL (count 1) by thread 0xc3a99170 (pid 22402) with 1 pending fileid 2 fsid 0x100ff01 After the first cvs update froze, I started a tcpdump to see if any traffic was being sent to repoman, but it did not show anything. Kris --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzRAEWry0BWjoQKURAritAKDg0dYKmoTqkgkrbvvXtswAr9QCHQCfY3NM vvDAeFfTuV3dPC7syrpWPTs= =S4A1 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 07:57:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D2BF16A4CE; Sat, 25 Dec 2004 07:57:18 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB9D643D41; Sat, 25 Dec 2004 07:57:17 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-b133.otenet.gr [212.205.244.141]) iBP7vCEs015860; Sat, 25 Dec 2004 09:57:15 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id iBP7v9sl000639; Sat, 25 Dec 2004 09:57:09 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id iBP7v9CL000638; Sat, 25 Dec 2004 09:57:09 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Sat, 25 Dec 2004 09:57:09 +0200 From: Giorgos Keramidas To: freebsd-current@freebsd.org Message-ID: <20041225075709.GA558@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: Scott Long Subject: LORs in ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 07:57:18 -0000 The locking changes of ipfilter have introduced a few LORs, which became visible right after the build fixes committed by Scott. Here are the ones I've seen so far. : lock order reversal : 1st 0xc072d0a0 ifnet (ifnet) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:2146 : 2nd 0xc06f9380 ipf IP NAT rwlock (ipf IP NAT rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:2836 : KDB: stack backtrace: : kdb_backtrace(0,ffffffff,c0708df8,c07083f8,c06d9aac) at kdb_backtrace+0x29 : witness_checkorder(c06f9380,9,c0676e6c,b14) at witness_checkorder+0x54c : _sx_xlock(c06f9380,c0676e6c,b14,3,c1e9a000) at _sx_xlock+0x50 : ip_natsync(c1e9a000,0,d95f9c84,c0448dd9,0) at ip_natsync+0x20 : frsync(0,c04f7994,c1d55fac,0,c068949f) at frsync+0x2e : iplioctl(c1e98b00,80047249,c1fa09e0,3,c1fba450) at iplioctl+0x551 : devfs_ioctl_f(c1ff1d48,80047249,c1fa09e0,c1d67d80,c1fba450) at devfs_ioctl_f+0x87 : ioctl(c1fba450,d95f9d14,3,1,246) at ioctl+0x370 : syscall(2f,2f,2f,280556c0,bfbfeed4) at syscall+0x213 : Xint0x80_syscall() at Xint0x80_syscall+0x1f : --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280c67e7, esp = 0xbfbfea7c, ebp = 0xbfbfea98 --- : lock order reversal : 1st 0xc2103c84 inp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:772 : 2nd 0xc06f92c0 ipf filter rwlock (ipf filter rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:1116 : KDB: stack backtrace: : kdb_backtrace(0,ffffffff,c0709c30,c0708470,c06d9aac) at kdb_backtrace+0x29 : witness_checkorder(c06f92c0,1,c0676ca7,45c) at witness_checkorder+0x54c : _sx_slock(c06f92c0,c0676ca7,45c,0,0) at _sx_slock+0x50 : fr_check(c1f9de84,14,c1e9a000,1,d9623ad4) at fr_check+0x330 : fr_check_wrapper(0,d9623ad4,c1e9a000,2,c2103bf4) at fr_check_wrapper+0x2a : pfil_run_hooks(c072f5e0,d9623b48,c1e9a000,2,c2103bf4) at pfil_run_hooks+0xbd : ip_output(c1f9de00,0,d9623b14,0,0) at ip_output+0x57e : udp_output(c2103bf4,c1f9de00,c1e46830,0,c1fbca10) at udp_output+0x47d : udp_send(c21013cc,0,c1f9de00,c1e46830,0) at udp_send+0x1a : sosend(c21013cc,c1e46830,d9623c4c,c1f9de00,0) at sosend+0x70f : kern_sendit(c1fbca10,16,d9623cc4,0,0) at kern_sendit+0x104 : sendit(c1fbca10,16,d9623cc4,0,c1e4e780) at sendit+0x159 : sendmsg(c1fbca10,d9623d14,3,0,286) at sendmsg+0x5a : syscall(2f,2f,2f,1,82c34ec) at syscall+0x213 : Xint0x80_syscall() at Xint0x80_syscall+0x1f : --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x28322a27, esp = 0xbfaed8fc, ebp = 0xbfaeda78 --- Converting the sx locks used by ipfilter to mutexes fixed these LORs but introduced a new one, which I'm not sure how to fix: : 1st 0xc06f8ba0 ipf IP state rwlock (ipf IP state rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/ip_state.c:793 : 2nd 0xc072c8e0 ifnet (ifnet) @ /usr/src/sys/net/if.c:1068 : KDB: stack backtrace: : kdb_backtrace(0,ffffffff,c0707c38,c0708638,c06d7e5c) at kdb_backtrace+0x29 : witness_checkorder(c072c8e0,9,c0695132,42c) at witness_checkorder+0x54c : _mtx_lock_flags(c072c8e0,0,c0695132,42c,2) at _mtx_lock_flags+0x5b : ifunit(c2138cdc,da7bca2c,c2138c00,5006,da7bc9f8) at ifunit+0x1e : fr_stinsert(c2138c00,1,1,0,0) at fr_stinsert+0x67 : fr_addstate(c1f9a8ac,da7bca2c,0,0) at fr_addstate+0x5f7 : fr_check(c1f9a8ac,14,c1e93414,1,da7bcad4) at fr_check+0x7cc : fr_check_wrapper(0,da7bcad4,c1e93414,2,c2101bf4) at fr_check_wrapper+0x2a : pfil_run_hooks(c072ee20,da7bcb48,c1e93414,2,c2101bf4) at pfil_run_hooks+0xbd : ip_output(c1f9a800,0,da7bcb14,0,0) at ip_output+0x57e : udp_output(c2101bf4,c1f9a800,c1e903d0,0,c20132e0) at udp_output+0x47d : udp_send(c20ff3cc,0,c1f9a800,c1e903d0,0) at udp_send+0x1a : sosend(c20ff3cc,c1e903d0,da7bcc4c,c1f9a800,0) at sosend+0x70f : kern_sendit(c20132e0,16,da7bccc4,0,0) at kern_sendit+0x104 : sendit(c20132e0,16,da7bccc4,0,c1e90410) at sendit+0x159 : sendmsg(c20132e0,da7bcd14,3,0,282) at sendmsg+0x5a : syscall(2f,2f,2f,1,82cb1ac) at syscall+0x213 : Xint0x80_syscall() at Xint0x80_syscall+0x1f : --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x28322a27, esp = 0xbfaed73c, ebp = 0xbfaed8b8 --- Any ideas about why this is a lock order reversal and how I can fix it? :-) From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 07:59:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B84C816A4CE; Sat, 25 Dec 2004 07:59:42 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB2E943D41; Sat, 25 Dec 2004 07:59:41 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-b133.otenet.gr [212.205.244.141]) iBP7xdsC027587; Sat, 25 Dec 2004 09:59:39 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id iBP7xcQe000694; Sat, 25 Dec 2004 09:59:38 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id iBP7xcEP000693; Sat, 25 Dec 2004 09:59:38 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Sat, 25 Dec 2004 09:59:38 +0200 From: Giorgos Keramidas To: freebsd-current@freebsd.org Message-ID: <20041225075938.GA669@gothmog.gr> References: <20041225075709.GA558@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041225075709.GA558@gothmog.gr> cc: Scott Long Subject: Re: LORs in ipfilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 07:59:42 -0000 On 2004-12-25 09:57, Giorgos Keramidas wrote: > The locking changes of ipfilter have introduced a few LORs, [...] It may help to send over the changes I locally made to use mutexes instead of sx locks: %%% Index: sys/contrib/ipfilter/netinet/ip_compat.h =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_compat.h,v retrieving revision 1.24 diff -u -r1.24 ip_compat.h --- sys/contrib/ipfilter/netinet/ip_compat.h 24 Dec 2004 09:14:26 -0000 1.24 +++ sys/contrib/ipfilter/netinet/ip_compat.h 25 Dec 2004 07:49:31 -0000 @@ -424,15 +424,6 @@ # undef MUTEX_INIT # undef MUTEX_DESTROY #endif -#if defined(__FreeBSD_version) && (__FreeBSD_version >= 500043) -# include -# include -# include -# define USE_MUTEX 1 -# define kmutex_t struct mtx -# define KRWLOCK_T struct sx -# define NETBSD_PF -#endif #ifdef KERNEL # if SOLARIS # if SOLARIS2 >= 6 @@ -525,30 +516,26 @@ # else /* __sgi */ # if defined(__FreeBSD_version) && (__FreeBSD_version >= 500043) # include -# include # include # define USE_MUTEX 1 +# define NETBSD_PF # define kmutex_t struct mtx -# define KRWLOCK_T struct sx +# define KRWLOCK_T kmutex_t # define ATOMIC_INC(x) { MUTEX_ENTER(&ipf_rw); \ (x)++; MUTEX_EXIT(&ipf_rw); } # define ATOMIC_DEC(x) { MUTEX_ENTER(&ipf_rw); \ (x)--; MUTEX_EXIT(&ipf_rw); } # define MUTEX_ENTER(x) mtx_lock(x) -# define READ_ENTER(x) sx_slock(x) -# define WRITE_ENTER(x) sx_xlock(x) +# define READ_ENTER(x) MUTEX_ENTER(x) +# define WRITE_ENTER(x) MUTEX_ENTER(x) # define RW_UPGRADE(x) ; -# define MUTEX_DOWNGRADE(x) sx_downgrade(x) -# define RWLOCK_INIT(x, y, z) sx_init((x), (y)) -# define RWLOCK_EXIT(x) do { \ - if ((x)->sx_cnt < 0) \ - sx_xunlock(x); \ - else \ - sx_sunlock(x); \ - } while (0) +# define MUTEX_DOWNGRADE(x) ; # define MUTEX_EXIT(x) mtx_unlock(x) +# define RWLOCK_EXIT(x) mtx_unlock(x) # define MUTEX_INIT(x,y,z) mtx_init((x), (y), NULL, MTX_DEF) # define MUTEX_DESTROY(x) mtx_destroy(x) +# define RWLOCK_INIT(x,y,z) mtx_init((x), (y), NULL, MTX_DEF) +# define RW_DESTROY(x) MUTEX_DESTROY(x) # else # define ATOMIC_INC(x) (x)++ # define ATOMIC_DEC(x) (x)-- %%% From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 22:26:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E93A216A4D1; Fri, 24 Dec 2004 22:26:08 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAC0C43D39; Fri, 24 Dec 2004 22:26:06 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a130.otenet.gr [212.205.215.130]) iBOMQ2hU017704; Sat, 25 Dec 2004 00:26:04 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id iBOMQ1e1051419; Sat, 25 Dec 2004 00:26:01 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id iBOMQ1xk051415; Sat, 25 Dec 2004 00:26:01 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 25 Dec 2004 00:26:01 +0200 From: Giorgos Keramidas To: FreeBSD Tinderbox Message-ID: <20041224222601.GB39539@gothmog.gr> References: <20041224221120.EBB087306E@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041224221120.EBB087306E@freebsd-current.sentex.ca> X-Mailman-Approved-At: Sat, 25 Dec 2004 17:35:12 +0000 cc: current@freebsd.org cc: i386@freebsd.org Subject: Re: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 24 Dec 2004 22:26:09 -0000 On 2004-12-24 17:11, FreeBSD Tinderbox wrote: > >>> stage 3.2: building everything > [...] > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.h:501:1: warning: "PFIL_HOOKS" redefined > :6:1: warning: this is the location of the previous definition > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `fr_forgetifp': > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: `ipf_mutex' undeclared (first use in this function) > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: (Each undeclared identifier is reported only once > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:922: error: for each function it appears in.) > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c: In function `ipfr_fastroute': > /tinderbox/CURRENT/i386/i386/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil.c:1779: error: `ipf_rw' undeclared (first use in this function) > *** Error code 1 Apparently, ipf_rw is not defined for FreeBSD builds of `fil.c'. The following will probably fix the build (I'm running a test build now): % gothmog:/usr/src# cvs -q di -u sys/contrib/ipfilter/netinet % Index: sys/contrib/ipfilter/netinet/fil.c % =================================================================== % RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/fil.c,v % retrieving revision 1.40 % diff -u -r1.40 fil.c % --- sys/contrib/ipfilter/netinet/fil.c 16 Dec 2004 21:02:15 -0000 1.40 % +++ sys/contrib/ipfilter/netinet/fil.c 24 Dec 2004 22:19:19 -0000 % @@ -115,10 +115,10 @@ % # define FR_VERBOSE(verb_pr) % # define FR_DEBUG(verb_pr) % # define IPLLOG(a, c, d, e) ipflog(a, c, d, e) % -# if SOLARIS || defined(__sgi) % +# if SOLARIS || defined(__sgi) || defined(__FreeBSD_version) % extern KRWLOCK_T ipf_mutex, ipf_auth, ipf_nat; % extern kmutex_t ipf_rw; % -# endif /* SOLARIS || __sgi */ % +# endif /* SOLARIS || __sgi || __FreeBSD_version */ % #endif /* _KERNEL */ % % % gothmog:/usr/src# From owner-freebsd-current@FreeBSD.ORG Fri Dec 24 22:51:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5E8216A4CE; Fri, 24 Dec 2004 22:51:08 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (84-72-30-72.dclient.hispeed.ch [84.72.30.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9C243D49; Fri, 24 Dec 2004 22:51:04 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:5448:1e48:0:210:60ff:fe25:f1e5]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id iBOMoun33058 verified NO); Fri, 24 Dec 2004 23:51:01 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id iBOMot433057; Fri, 24 Dec 2004 23:50:56 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Fri, 24 Dec 2004 23:50:56 +0100 (CET) Message-Id: <200412242250.iBOMot433057@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: Chuck Robey References: <20041224010759.N1763@april.chuckr.org> <200412241756.56900.doconnor@gsoft.com.au> <20041224101921.X1763@april.chuckr.org> Mail-Followup-To: freebsd-usb@freebsd.org X-Mailman-Approved-At: Sat, 25 Dec 2004 17:35:12 +0000 cc: freebsd-current@freebsd.org cc: freebsd-usb@freebsd.org Subject: Re: fingerprints X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barry Bouwsma List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2004 22:51:08 -0000 > > > Has there been any work on getting fingerprint readers working on FreeBSD? > > > I *really* disilked the fact that (apparently) the only fingerprint > > > reader is supplied via Microsoft, but beyond that, it's a USB device, > > > which ought to mean, a simple implementation. I guess I have to read how > > Ahem, sorry.. USB != simple. > Can't (and won't), it's Micrsoft, I won't stoop that low. There's only so > many possibilities here, I'll just how to see how I can download whatever > the mindless little thing has, and begin comparing with what it could be. > The only problem is figuring out how to open it up in general, so I can > get that listing. I'll figure it out, the usb site is on the web, it's > got docs, I just hope they're not too huge. I suggest you consult the friendly folx hanging out on the USB list (usb@ or freebsd-usb@), where I'm sending followups to this as well as a copy of this. Bernd Walter (ticso) has a ports skeleton for the NetBSD USB utilities that can tell you details about the endpoints and protocols of your device. I thought I had another program that gave even more info, but I'll have to look around to try and find it. I'm not aware of any user utilities that can do useful things like extract strings from the device, but it's so trivial to do that such a thing certainly exists, which can tell you a bit more about the device. Perhaps something in libusb is what I'm thinking of. That may be enough to get you started without reinventing the wheel. barry bouwsma From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 03:11:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 347DF16A4CE for ; Sat, 25 Dec 2004 03:11:39 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id A096743D1D for ; Sat, 25 Dec 2004 03:11:38 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 27929 invoked from network); 25 Dec 2004 03:11:37 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 25 Dec 2004 03:11:37 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 24 Dec 2004 21:11:36 -0600 (CST) From: Mike Silbersack To: current@freebsd.org Message-ID: <20041224210649.D72855@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 25 Dec 2004 17:35:12 +0000 Subject: Disk access SOLVES sound stutter! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 03:11:39 -0000 My laptop has built-in sound: pcm0: port 0x1000-0x10ff mem 0xd0001000-0xd0001fff irq 5 at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] I haven't played with it much, but I started doing so again recently. The sound quality is rather poor when the system is idle, it sounds as if it's playing too slowly. However, while there is disk activity going on (start Konqueror, OO, opening my huge inbox, etc), the sound is perfect. systat -vm shows this to be due to interrupt rates. Although irq 5 is not shared with anything else, disk activity causes the interrupt rate for irq 5 to increase from ~79 per second to ~84 per second. This is a 6.0-current UP system. 4BSD scheduler, preemption enabled. Any clue as to why this might be happening? Sounds like something very interesting going on in some low level system somewhere. :) BTW, mpg123 and xmms were both used for testing, with and without X running; results always seem to fix the above profile. Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 17:35:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9211116A5AB for ; Sat, 25 Dec 2004 17:35:24 +0000 (GMT) Received: from web80606.mail.yahoo.com (web80606.mail.yahoo.com [66.218.79.95]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D90043D3F for ; Sat, 25 Dec 2004 17:35:24 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20041225173524.33634.qmail@web80606.mail.yahoo.com> Received: from [209.79.46.127] by web80606.mail.yahoo.com via HTTP; Sat, 25 Dec 2004 09:35:24 PST Date: Sat, 25 Dec 2004 09:35:24 -0800 (PST) From: Mohan Srinivasan To: Kris Kennaway , mohans , ps@FreeBSD.org, current@FreeBSD.org In-Reply-To: <20041225070022.GA93123@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 17:35:24 -0000 Hi, If the box is still in that state, can you force a core ? The trace below shows the process blocked on nfs_request()->msleep. If the process shows up as waiting on "nfsreq", it would be msleep'ing from nfs_reply(), not from nfs_request(). There's only one msleep() call in nfs_request() (nfs_socket.c:1125), but that is for "nqnfstry". The msleep("nfsreq") only happens from nfs_reply() (unless nfs_reply() has gotten inlined). mohan --- Kris Kennaway wrote: > Since updating pointyhat to tonight's 6.0 sources (previously from > about a month ago), I'm having processes locking up in state nfsreq. > I confirmed that directio was disabled. > > This is a cvs update from repoman (mounted via NFS with the following > options: > > repoman:/r /repoman/r nfs ro,bg,intr,soft,nodev,nosuid 0 00 > > db> tr 22402 > Tracing pid 22402 tid 100161 td 0xc3a99170 > sched_switch(c3a99170,0,1,120,b08c87ee) at sched_switch+0x115 > mi_switch(1,0,c06e61e4,1ab,1) at mi_switch+0x1d3 > sleepq_switch(1,c06e2b19,18e,1,1) at sleepq_switch+0x10d > sleepq_wait_sig(c7acb980,0,c06e3e0f,dc,0) at sleepq_wait_sig+0xf > msleep(c7acb980,c076f520,153,c06f1e45,0) at msleep+0x21e > nfs_request(c39c1cf0,c4355c00,3,c3a99170,c3c0b300) at nfs_request+0x762 > nfs_lookup(ee15fb84,c3a99170,c3a99170,c3a99170,ee15fc38) at nfs_lookup+0x2f8 > lookup(ee15fc24,c35bb400,0,a7,8) at lookup+0x274 > namei(ee15fc24,108,c06e3d30,8,c073b9c8) at namei+0x27d > stat(c3a99170,ee15fd14,c06fecb7,3ad,2) at stat+0x4f > syscall(2f,80c002f,bfbf002f,80ce0e0,283aaf60) at syscall+0x137 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (188, FreeBSD ELF32, stat), eip = 0x28316b1f, esp = 0xbfbfeb8c, ebp = 0xbfbfec08 --- > > db> show lockedvnods > Locked vnodes > 0xc5ccd9b4: tag ufs, type VDIR > usecount 6, writecount 0, refcount 9 mountedhere 0 > flags (VV_OBJBUF) > lock type ufs: EXCL (count 1) by thread 0xc3cdc170 (pid 5840) > ino 14110529, on dev twed0s1f (232, 7) > 0xc5512114: tag ufs, type VREG > usecount 1, writecount 0, refcount 240 mountedhere 0 > flags (VV_OBJBUF) > lock type ufs: EXCL (count 1) by thread 0xc9bc85c0 (pid 4717) > ino 35135903, on dev twed0s1f (232, 7) > 0xc6ebb9b4: tag ufs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_OBJBUF) > lock type ufs: EXCL (count 1) by thread 0xc9bc8cf0 (pid 4700) > ino 16275165, on dev twed0s1f (232, 7) > 0xc79f8564: tag ufs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_OBJBUF) > lock type ufs: EXCL (count 1) by thread 0xc3c78170 (pid 5835) > ino 17405819, on dev twed0s1f (232, 7) > 0xc5d3a8a0: tag ufs, type VNON > usecount 1, writecount 0, refcount 0 mountedhere 0 > > lock type ufs: EXCL (count 1) by thread 0xc3cdc170 (pid 5840) > ino 14146443, on dev twed0s1f (232, 7) > 0xc39c1cf0: tag nfs, type VDIR > usecount 3, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT) > lock type nfs: EXCL (count 1) by thread 0xc3a99170 (pid 22402) with 1 pending > fileid 2 fsid 0x100ff01 > > After the first cvs update froze, I started a tcpdump to see if any > traffic was being sent to repoman, but it did not show anything. > > Kris > > ATTACHMENT part 2 application/pgp-signature From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 18:27:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68DAD16A4CE for ; Sat, 25 Dec 2004 18:27:36 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9C9D43D49 for ; Sat, 25 Dec 2004 18:27:35 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 19F86530C; Sat, 25 Dec 2004 19:27:34 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id E615E5308 for ; Sat, 25 Dec 2004 19:26:57 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 6A21EB869; Sat, 25 Dec 2004 19:26:57 +0100 (CET) To: current@freebsd.org From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 25 Dec 2004 19:26:57 +0100 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 Subject: fxp EEPROM checksum mismatch in recent -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 18:27:36 -0000 Yesterday's -CURRENT fails to attach the onboard fxp on my Gigabyte motherboard: fxp0: port 0xb000-0xb03f mem 0xf= b050000-0xfb050fff irq 20 at device 8.0 on pci2 fxp0: Disabling dynamic standby mode in EEPROM fxp0: New EEPROM ID: 0xfffd fxp0: EEPROM checksum @ 0xff: 0xffff -> 0xbbb9 fxp0: MII without any PHY! device_attach: fxp0 attach returned 6 Older kernels have no trouble at all: fxp0: port 0xb000-0xb03f mem 0xf= b050000-0xfb050fff irq 20 at device 8.0 on pci2 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:0d:61:0a:3b:12 I haven't managed to narrow down the breakage yet. pciconf -lv says: fxp0@pci2:8:0: class=3D0x020000 card=3D0x30138086 chip=3D0x10508086 rev=3D= 0x82 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801EB/ER PRO/100 VE Network Connection' class =3D network subclass =3D ethernet DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 20:06:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7482516A4CE; Sat, 25 Dec 2004 20:06:49 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B8DC43D41; Sat, 25 Dec 2004 20:06:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DADCB512BF; Sat, 25 Dec 2004 12:06:33 -0800 (PST) Date: Sat, 25 Dec 2004 12:06:33 -0800 From: Kris Kennaway To: Mohan Srinivasan Message-ID: <20041225200633.GC56931@xor.obsecurity.org> References: <20041225070022.GA93123@xor.obsecurity.org> <20041225173524.33634.qmail@web80606.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: <20041225173524.33634.qmail@web80606.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i cc: ps@FreeBSD.org cc: current@FreeBSD.org cc: mohans cc: Kris Kennaway Subject: Re: Processes stuck in nfsreq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 20:06:49 -0000 --+xNpyl7Qekk2NvDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 25, 2004 at 09:35:24AM -0800, Mohan Srinivasan wrote: > Hi, >=20 > If the box is still in that state, can you force a core ? >=20 > The trace below shows the process blocked on nfs_request()->msleep. > If the process shows up as waiting on "nfsreq", it would be msleep'ing > from nfs_reply(), not from nfs_request(). There's only one msleep() > call in nfs_request() (nfs_socket.c:1125), but that is for "nqnfstry". > The msleep("nfsreq") only happens from nfs_reply() (unless nfs_reply()=20 > has gotten inlined). It's possible the sleep channel was something else, I transcribed that from memory because by that time I couldn't get back in to the box to do anything. Kris --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzchIWry0BWjoQKURAhSvAJ9VWFF1Jca520VJE3EGMoOfNPrznQCgp7XI SqzEM9q36F3nWOk3lcc8pZI= =0Wzg -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 20:33:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8C1916A4CE for ; Sat, 25 Dec 2004 20:33:11 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B8D443D31 for ; Sat, 25 Dec 2004 20:33:11 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iBPKTwFr044967 for ; Sat, 25 Dec 2004 15:29:58 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iBPKTw8f044964 for ; Sat, 25 Dec 2004 20:29:58 GMT (envelope-from robert@fledge.watson.org) Date: Sat, 25 Dec 2004 20:29:58 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Problem with 802.11 ad hoc with WEP: NULL pointer dereference X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 20:33:12 -0000 I recently upgraded a kernel on my notebook to Dec 23. I don't have the date of the previous kernel on-hand, but I suspect it was late November from before I was on travel. I have a local configuration I sometimes use with adhoc 802.11 on a prism card using WEP, using a FreeBSD notebook as a proxy to reach a wired network. The other system is a Mac OS X notebook.= =20 As of the upgrade, I get a kernel page fault on the FreeBSD system whenever I attempt to use the Mac OS X box with wireless. In fact, booting the Mac OS X box causes the FreeBSD box to panic, presumably as the Mac OS X box says "Hi, I'm here!". The panic is a NULL pointer derefernece in ieee80211_find_rxnode(). I don't have the complete trap message due to not having a serial console for the box, but below is some core information. This is highly reproduceable; please let me know if more information is needed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research #21 0x00000002 in ?? () #22 0xc05a6b2b in ieee80211_find_rxnode (ic=3D0xc1bcf25c, wh=3D0xc1bb8730) at atomic.h:365 #23 0xc04ca7c7 in wi_intr (arg=3D0xc1bcf000) at /usr/src/sys/dev/wi/if_wi.c:1533 #24 0xc0506d8d in ithread_loop (arg=3D0xc197b780) at /usr/src/sys/kern/kern_intr.c:547 #25 0xc0505e8c in fork_exit (callout=3D0xc0506ce0 ,=20 arg=3D0xc197b780, frame=3D0xd418fd48) at /usr/src/sys/kern/kern_fork.c:= 790 #26 0xc069619c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) frame 22 #22 0xc05a6b2b in ieee80211_find_rxnode (ic=3D0xc1bcf25c, wh=3D0xc1bb8730) at atomic.h:365 365 { (kgdb) list=20 360 #define atomic_readandclear_32 atomic_readandclear_int 361 362 #if !defined(WANT_FUNCTIONS) 363 static __inline int 364 atomic_cmpset_ptr(volatile void *dst, void *exp, void *src) 365 { 366 367 return (atomic_cmpset_int((volatile u_int *)dst, (u_int)exp= , 368 (u_int)src)); 369 } (kgdb) inspect nt $1 =3D (struct ieee80211_node_table *) 0x0 # # I'm not sure how to get gdb to tell me what line in the 802.11 code this # is, but I'm assuming it's the call to IEEE80211_NODE_LOCK() that's # failing due to a NULL nt. # (kgdb) inspect ic $2 =3D (struct ieee80211com *) 0xc1bcf25c (kgdb) inspect *ic $3 =3D {ic_next =3D {sle_next =3D 0x0}, ic_ifp =3D 0xc1bcf000, ic_stats =3D= { is_rx_badversion =3D 0, is_rx_tooshort =3D 0, is_rx_wrongbss =3D 0,=20 is_rx_dup =3D 0, is_rx_wrongdir =3D 0, is_rx_mcastecho =3D 0,=20 is_rx_notassoc =3D 0, is_rx_noprivacy =3D 0, is_rx_unencrypted =3D 0,= =20 is_rx_wepfail =3D 0, is_rx_decap =3D 0, is_rx_mgtdiscard =3D 0, is_rx_c= tl =3D 0,=20 is_rx_beacon =3D 0, is_rx_rstoobig =3D 0, is_rx_elem_missing =3D 0,=20 is_rx_elem_toobig =3D 0, is_rx_elem_toosmall =3D 0, is_rx_elem_unknown = =3D 0,=20 is_rx_badchan =3D 0, is_rx_chanmismatch =3D 0, is_rx_nodealloc =3D 0,= =20 is_rx_ssidmismatch =3D 0, is_rx_auth_unsupported =3D 0, is_rx_auth_fail= =3D 0,=20 is_rx_auth_countermeasures =3D 0, is_rx_assoc_bss =3D 0,=20 is_rx_assoc_notauth =3D 0, is_rx_assoc_capmismatch =3D 0,=20 is_rx_assoc_norate =3D 0, is_rx_assoc_badwpaie =3D 0, is_rx_deauth =3D = 0,=20 is_rx_disassoc =3D 0, is_rx_badsubtype =3D 0, is_rx_nobuf =3D 0,=20 is_rx_decryptcrc =3D 0, is_rx_ahdemo_mgt =3D 0, is_rx_bad_auth =3D 0,= =20 is_rx_unauth =3D 0, is_rx_badkeyid =3D 0, is_rx_ccmpreplay =3D 0,=20 is_rx_ccmpformat =3D 0, is_rx_ccmpmic =3D 0, is_rx_tkipreplay =3D 0,=20 is_rx_tkipformat =3D 0, is_rx_tkipmic =3D 0, is_rx_tkipicv =3D 0,=20 is_rx_badcipher =3D 0, is_rx_nocipherctx =3D 0, is_rx_acl =3D 0,=20 is_tx_nobuf =3D 0, is_tx_nonode =3D 0, is_tx_unknownmgt =3D 0,=20 is_tx_badcipher =3D 0, is_tx_nodefkey =3D 0, is_tx_noheadroom =3D 0,=20 is_scan_active =3D 0, is_scan_passive =3D 0, is_node_timeout =3D 0,=20 is_crypto_nomem =3D 0, is_crypto_tkip =3D 0, is_crypto_tkipenmic =3D 0,= =20 is_crypto_tkipdemic =3D 0, is_crypto_tkipcm =3D 0, is_crypto_ccmp =3D 0= ,=20 is_crypto_wep =3D 0, is_crypto_setkey_cipher =3D 0,=20 is_crypto_setkey_nokey =3D 0, is_crypto_delkey =3D 0, is_crypto_badciph= er =3D 0,=20 is_crypto_nocipher =3D 1, is_crypto_attachfail =3D 0,=20 is_crypto_swfallback =3D 0, is_crypto_keyfail =3D 0, is_ibss_capmismatc= h =3D 0,=20 is_ibss_norate =3D 0, is_ps_unassoc =3D 0, is_ps_badaid =3D 0,=20 is_ps_qempty =3D 0}, ic_sysctl =3D 0xc1bd2050, ic_debug =3D 0, ic_vap = =3D 0,=20 ic_beaconlock =3D {mtx_object =3D {lo_class =3D 0xc0719364,=20 lo_name =3D 0xc06eaf51 "beacon",=20 lo_type =3D 0xc06eaf3e "802.11 beacon lock", lo_flags =3D 196608, lo_list =3D { tqe_next =3D 0x0, tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_lock = =3D 4,=20 mtx_recurse =3D 0}, ic_reset =3D 0,=20 ic_recv_mgmt =3D 0xc059e63c ,=20 ic_send_mgmt =3D 0xc05a9948 ,=20 ic_newstate =3D 0xc04c8e2c , ic_newassoc =3D 0, ic_updateslo= t =3D 0,=20 ic_set_tim =3D 0xc05a8b8c , ic_myaddr =3D "\000\t[1'= =A4",=20 ic_sup_rates =3D {{rs_nrates =3D 0 '\0', rs_rates =3D '\0' }, { rs_nrates =3D 0 '\0', rs_rates =3D '\0' }, { rs_nrates =3D 4 '\004',=20 rs_rates =3D "\002\004\v\026\000\000\000\000\000\000\000\000\000\000"}, { rs_nrates =3D 0 '\0', rs_rates =3D '\0' }, { rs_nrates =3D 0 '\0', rs_rates =3D '\0' }, { rs_nrates =3D 0 '\0', rs_rates =3D '\0' }, { rs_nrates =3D 0 '\0', rs_rates =3D '\0' }}, ic_channels =3D { {ic_freq =3D 0, ic_flags =3D 0}, {ic_freq =3D 2412, ic_flags =3D 160}, = { ic_freq =3D 2417, ic_flags =3D 160}, {ic_freq =3D 2422, ic_flags =3D = 160}, { ic_freq =3D 2427, ic_flags =3D 160}, {ic_freq =3D 2432, ic_flags =3D = 160}, { ic_freq =3D 2437, ic_flags =3D 160}, {ic_freq =3D 2442, ic_flags =3D = 160}, { ic_freq =3D 2447, ic_flags =3D 160}, {ic_freq =3D 2452, ic_flags =3D = 160}, { ic_freq =3D 2457, ic_flags =3D 160}, {ic_freq =3D 2462, ic_flags =3D = 160}, { ic_freq =3D 0, ic_flags =3D 0} },=20 ic_chan_avail =3D "=FE\017", '\0' ,=20 ic_chan_active =3D "=FE\017", '\0' ,=20 ic_chan_scan =3D '\0' , ic_scan =3D {nt_ic =3D 0xc1bcf2= 5c,=20 nt_nodelock =3D {mtx_object =3D {lo_class =3D 0xc0719364,=20 lo_name =3D 0xc1bcf00c "wi0", lo_type =3D 0xc06ebe51 "802.11 node table",=20 lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x= 0},=20 lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0}, nt_node = =3D { tqh_first =3D 0xc1a6d800, tqh_last =3D 0xc1a6d808}, nt_hash =3D {{ lh_first =3D 0x0}, {lh_first =3D 0x0}, {lh_first =3D 0x0}, {lh_firs= t =3D 0x0},=20 {lh_first =3D 0xc1a6d800}, {lh_first =3D 0x0} },=20 nt_name =3D 0xc06f7e21 "scan", nt_scanlock =3D {mtx_object =3D { lo_class =3D 0xc0719364, lo_name =3D 0xc1bcf00c "wi0",=20 lo_type =3D 0xc06ebe63 "802.11 scangen", lo_flags =3D 196608, lo_li= st =3D { tqe_next =3D 0x0, tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_loc= k =3D 4,=20 mtx_recurse =3D 0}, nt_scangen =3D 1, nt_inact_timer =3D 13,=20 nt_inact_init =3D 20,=20 nt_timeout =3D 0xc05a7c0c }, ic_mgtq =3D { ifq_head =3D 0x0, ifq_tail =3D 0x0, ifq_len =3D 0, ifq_maxlen =3D 0,=20 ifq_drops =3D 0, ifq_mtx =3D {mtx_object =3D {lo_class =3D 0xc0719364,= =20 lo_name =3D 0xc1bcf00c "wi0", lo_type =3D 0xc06ec7bb "mgmt send q",= =20 lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x= 0},=20 lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0}},=20 ic_flags =3D 2228240, ic_caps =3D 67329, ic_modecaps =3D 5, ic_curmode = =3D 0,=20 ic_phytype =3D IEEE80211_T_DS, ic_opmode =3D IEEE80211_M_IBSS,=20 ic_state =3D IEEE80211_S_RUN, ic_protmode =3D IEEE80211_PROT_CTSONLY,=20 ic_roaming =3D IEEE80211_ROAMING_AUTO, ic_sta =3D 0x0,=20 ic_aid_bitmap =3D 0xc1bd37e0, ic_max_aid =3D 256, ic_sta_assoc =3D 0,=20 ic_ps_sta =3D 0, ic_ps_pending =3D 0, ic_tim_bitmap =3D 0xc1bd3780 "",=20 ic_tim_len =3D 32, ic_dtim_period =3D 1, ic_media =3D {ifm_mask =3D 0,=20 ifm_media =3D 384, ifm_cur =3D 0xc1bd3760, ifm_list =3D {lh_first =3D 0xc1a6fc20},=20 ifm_change =3D 0xc04c7130 ,=20 ifm_status =3D 0xc04c7490 }, ic_rawbpf =3D 0x0,=20 ic_bss =3D 0xc1a6d800, ic_ibss_chan =3D 0xc1bcf46e, ic_fixed_rate =3D -1,= =20 ic_rtsthreshold =3D 2312, ic_fragthreshold =3D 2346,=20 ic_node_alloc =3D 0xc05a5f9c ,=20 ic_node_free =3D 0xc05a6140 ,=20 ic_node_cleanup =3D 0xc05a5fb8 ,=20 ic_node_getrssi =3D 0xc05a61bc , ic_lintval =3D 100,=20 ic_holdover =3D 0, ic_txmin =3D 0, ic_txmax =3D 0, ic_txlifetime =3D 0,= =20 ic_txpowlimit =3D 100, ic_bmisstimeout =3D 700, ic_nonerpsta =3D 0,=20 ic_longslotsta =3D 0, ic_mgt_timer =3D 0, ic_inact_timer =3D 0, ic_des_es= slen =3D 5,=20 ic_des_essid =3D "XXXXX", '\0' , ic_des_chan =3D 0xffff= ,=20 ic_des_bssid =3D "\000\000\000\000\000", ic_opt_ie =3D 0x0, ic_opt_ie_len= =3D 0,=20 ic_inact_init =3D 2, ic_inact_auth =3D 12, ic_inact_run =3D 20,=20 ic_inact_probe =3D 2, ic_wme =3D {wme_flags =3D 0, wme_hipri_traffic =3D = 0,=20 wme_hipri_switch_thresh =3D 0, wme_hipri_switch_hysteresis =3D 3,=20 wme_params =3D {{wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '\0= ',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}, {wmep_acm =3D 0 '\0', wmep_aifsn =3D = 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '\0= ',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}}, wme_wmeChanParams =3D {cap_info =3D = 0 '\0',=20 cap_wmeParams =3D {{wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}, {wmep_acm =3D 0 '\0', wmep_aifsn = =3D 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}}}, wme_wmeBssChanParams =3D { cap_info =3D 0 '\0', cap_wmeParams =3D {{wmep_acm =3D 0 '\0',=20 wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '\0', wmep_logcwmax = =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}, {wmep_acm =3D 0 '\0', wmep_aifsn = =3D 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}}}, wme_chanParams =3D {cap_info =3D = 0 '\0',=20 cap_wmeParams =3D {{wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}, {wmep_acm =3D 0 '\0', wmep_aifsn = =3D 0 '\0', wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}}}, wme_bssChanParams =3D { cap_info =3D 0 '\0', cap_wmeParams =3D {{wmep_acm =3D 0 '\0',=20 wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '\0', wmep_logcwmax = =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}, {wmep_acm =3D 0 '\0', wmep_aifsn = =3D 0 '\0',=20 wmep_logcwmin =3D 0 '\0', wmep_logcwmax =3D 0 '\0',=20 wmep_txopLimit =3D 0 '\0', wmep_noackPolicy =3D 0 '\0'}, { wmep_acm =3D 0 '\0', wmep_aifsn =3D 0 '\0', wmep_logcwmin =3D 0 '= \0',=20 wmep_logcwmax =3D 0 '\0', wmep_txopLimit =3D 0 '\0',=20 wmep_noackPolicy =3D 0 '\0'}}}, wme_update =3D 0}, ic_crypto =3D = { cs_nw_keys =3D {{wk_keylen =3D 13 '\r', wk_flags =3D 3 '\003', wk_keyix= =3D 0,=20 wk_key =3D "XXXXXXXXXXXX\021", '\0' , wk_keyrsc = =3D 0,=20 wk_keytsc =3D 0, wk_cipher =3D 0xc1f7b080, wk_private =3D 0xc1a8f01= 0}, { wk_keylen =3D 0 '\0', wk_flags =3D 3 '\003', wk_keyix =3D 1,=20 wk_key =3D '\0' , wk_keyrsc =3D 0, wk_keytsc =3D = 0,=20 wk_cipher =3D 0xc06c2ac0, wk_private =3D 0xc1bcf25c}, {wk_keylen = =3D 0 '\0',=20 wk_flags =3D 3 '\003', wk_keyix =3D 2, wk_key =3D '\0' ,=20 wk_keyrsc =3D 0, wk_keytsc =3D 0, wk_cipher =3D 0xc06c2ac0,=20 wk_private =3D 0xc1bcf25c}, {wk_keylen =3D 0 '\0', wk_flags =3D 3 '\003',=20 wk_keyix =3D 3, wk_key =3D '\0' , wk_keyrsc =3D 0= ,=20 wk_keytsc =3D 0, wk_cipher =3D 0xc06c2ac0, wk_private =3D 0xc1bcf25= c}},=20 cs_def_txkey =3D 0, cs_key_alloc =3D 0xc059d048 ,=20 cs_key_delete =3D 0xc059d054 ,=20 cs_key_set =3D 0xc059d060 ,=20 cs_key_update_begin =3D 0xc059d06c ,=20 cs_key_update_end =3D 0xc059d06c }, ic_auth =3D 0xc06c3160,=20 ic_ec =3D 0x0, ic_acl =3D 0x0, ic_as =3D 0x0} Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 21:40:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A78F16A4CE for ; Sat, 25 Dec 2004 21:40:39 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B8C843D55 for ; Sat, 25 Dec 2004 21:40:39 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.13.1/8.12.11) with ESMTP id iBPM4oIB054168 for ; Sat, 25 Dec 2004 17:04:50 -0500 (EST) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost)iBPM4o1Y054165 for ; Sat, 25 Dec 2004 17:04:50 -0500 (EST) (envelope-from chuckr@chuckr.org) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Sat, 25 Dec 2004 17:04:50 -0500 (EST) From: Chuck Robey To: FreeBSD-current@FreeBSD.org Message-ID: <20041225165511.O54135@april.chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: an accidental way to pull the plug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 21:40:39 -0000 I got a little too fast just now, and did something that I shouldn't have done, but what's interesting is, FreeBSD decided to pull the plug and instantly reboot, which is usually something to be regarded as pathological, so I am letting you folks know. I haven't analyzed exactly what happened to cause it, actually. Anyhow, I have been using FreeBSD as a fine platform for a Free database I am constructing for a buddy of mine who has a video rental store. The database, which was active at the time (the app is nearly complete) is made with Python, gtk, pygtk (obviously) and the Sleepycat database. I called those folks up and got the opinion that, as long as I didn't try to distribute the software, the way I'm handling it (for free) it generally falls under their free license, so I'm ok on that. Anyhow, I was talking screen dump pictures of the 6 data entry screens, in X11, using xv to grab the windows. I got a bit confused with mouse clicks, and actually asked it to do a grab while another grab was in delay wait (it has a timer delay, which I set to 5 seconds). Result: reboot, instant. I think that's it, although I will try to answer any questions. If you folks are all too tied up with your own projects, it won't bother me, I'm only trying to be conscientious about things. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ---------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 21:43:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AD7316A4CE for ; Sat, 25 Dec 2004 21:43:31 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6E2C43D58 for ; Sat, 25 Dec 2004 21:43:30 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iBPLeHUo046287; Sat, 25 Dec 2004 16:40:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iBPLeHn0046284; Sat, 25 Dec 2004 21:40:17 GMT (envelope-from robert@fledge.watson.org) Date: Sat, 25 Dec 2004 21:40:17 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Chuck Robey In-Reply-To: <20041225165511.O54135@april.chuckr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-current@FreeBSD.org Subject: Reboot instead of debugger/dump from X11? (Re: an accidental way to pull the plug) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 21:43:31 -0000 On Sat, 25 Dec 2004, Chuck Robey wrote: > I got a little too fast just now, and did something that I shouldn't > have done, but what's interesting is, FreeBSD decided to pull the plug > and instantly reboot, which is usually something to be regarded as > pathological, so I am letting you folks know. I haven't analyzed > exactly what happened to cause it, actually. With the recent 802.11 panic I posted about a bit earlier, I saw something rather odd: when the panic took place on the normal text console, the system dropped to the debugger. However, when it took place with X11 running, I got an "instant reboot" -- no dump, etc. So something odd is happening during even normal failure modes when X11 is running for me. I wonder if anyone else is seeing this? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > Anyhow, I have been using FreeBSD as a fine platform for a Free database I > am constructing for a buddy of mine who has a video rental store. The > database, which was active at the time (the app is nearly complete) is > made with Python, gtk, pygtk (obviously) and the Sleepycat database. I > called those folks up and got the opinion that, as long as I didn't try to > distribute the software, the way I'm handling it (for free) it generally > falls under their free license, so I'm ok on that. > > Anyhow, I was talking screen dump pictures of the 6 data entry screens, in > X11, using xv to grab the windows. I got a bit confused with mouse > clicks, and actually asked it to do a grab while another grab was in delay > wait (it has a timer delay, which I set to 5 seconds). Result: reboot, > instant. > > I think that's it, although I will try to answer any questions. If you > folks are all too tied up with your own projects, it won't bother me, I'm > only trying to be conscientious about things. > > ---------------------------------------------------------------------------- > Chuck Robey | Interests include C & Java programming, FreeBSD, > chuckr@chuckr.org | electronics, communications, and SF/Fantasy. > > New Year's Resolution: I will not sphroxify gullible people into looking up > fictitious words in the dictionary (on the wall at my old fraternity, > Signa Phi Nothing). > ---------------------------------------------------------------------------- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 21:55:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C75A616A513; Sat, 25 Dec 2004 21:55:25 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76A7643D2D; Sat, 25 Dec 2004 21:55:25 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id iBPLtMdI037484; Sat, 25 Dec 2004 13:55:22 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id iBPLtMhx037483; Sat, 25 Dec 2004 13:55:22 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Robert Watson In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 25 Dec 2004 13:55:21 -0800 Message-Id: <1104011721.856.73.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: Chuck Robey cc: FreeBSD-current@freebsd.org Subject: Re: Reboot instead of debugger/dump from X11? (Re: an accidental way to pull the plug) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 21:55:25 -0000 On Sat, 2004-12-25 at 21:40 +0000, Robert Watson wrote: > On Sat, 25 Dec 2004, Chuck Robey wrote: > > > I got a little too fast just now, and did something that I shouldn't > > have done, but what's interesting is, FreeBSD decided to pull the plug > > and instantly reboot, which is usually something to be regarded as > > pathological, so I am letting you folks know. I haven't analyzed > > exactly what happened to cause it, actually. > > With the recent 802.11 panic I posted about a bit earlier, I saw something > rather odd: when the panic took place on the normal text console, the > system dropped to the debugger. However, when it took place with X11 > running, I got an "instant reboot" -- no dump, etc. So something odd is > happening during even normal failure modes when X11 is running for me. I > wonder if anyone else is seeing this? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research I've been having mysterious reboots on my amd64 when using gdb for just about anything, and I'm always in X. I'm supposed to be dropping to debugger on panic, but that's obviously not happening. I've been waiting for a good time (hah) to reproduce it in the console to see if it's X related, but haven't yet. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 22:34:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F2E016A4CE for ; Sat, 25 Dec 2004 22:34:05 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 126B943D1F for ; Sat, 25 Dec 2004 22:34:05 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4F054516D1; Sat, 25 Dec 2004 14:33:46 -0800 (PST) Date: Sat, 25 Dec 2004 14:33:46 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20041225223346.GA49395@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: xorg 6.8.1 packages uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 22:34:05 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline A package set built against xorg 6.8.1 has been uploaded to ftp-master and will make its' way to the mirrors when next they update. After checking that your ftp mirror has the updates, you can use portupgrade -P to update your ports, if you want to avoid recompiling everything. Kris --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBzerIWry0BWjoQKURAl9mAKDPLY4j4VAED+WBBfCzhYZXm5UWTQCg7Zxq xPDIzbDTJ88JnW7S6ZI2Y9E= =+r5T -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 25 22:38:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D94A16A4CE; Sat, 25 Dec 2004 22:38:06 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5072E43D3F; Sat, 25 Dec 2004 22:38:05 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iBPMc0ne077131; Sat, 25 Dec 2004 23:38:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 25 Dec 2004 21:40:17 GMT." Date: Sat, 25 Dec 2004 23:38:00 +0100 Message-ID: <77130.1104014280@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Chuck Robey cc: FreeBSD-current@freebsd.org Subject: Re: Reboot instead of debugger/dump from X11? (Re: an accidental way to pull the plug) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 22:38:06 -0000 In message , Robe rt Watson writes: > >On Sat, 25 Dec 2004, Chuck Robey wrote: > >> I got a little too fast just now, and did something that I shouldn't >> have done, but what's interesting is, FreeBSD decided to pull the plug >> and instantly reboot, which is usually something to be regarded as >> pathological, so I am letting you folks know. I haven't analyzed >> exactly what happened to cause it, actually. > >With the recent 802.11 panic I posted about a bit earlier, I saw something >rather odd: when the panic took place on the normal text console, the >system dropped to the debugger. However, when it took place with X11 >running, I got an "instant reboot" -- no dump, etc. So something odd is >happening during even normal failure modes when X11 is running for me. I >wonder if anyone else is seeing this? Well, it's worse: I often get two-level panics these days and I have no idea how to find out what the first panic was, panicstr isn't even set until after some SMP magic which appearantly is responsible for the second layer of panicing. I think we should start panic() with setting panicstr with an atomic instruction so that we always get the first panic recorded, no matter what. I suspect the preemption code is at fault. -- 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 Sat Dec 25 23:42:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6829316A4CE for ; Sat, 25 Dec 2004 23:42:57 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FEAD43D55 for ; Sat, 25 Dec 2004 23:42:57 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E1BFF512BF; Sat, 25 Dec 2004 15:42:36 -0800 (PST) Date: Sat, 25 Dec 2004 15:42:36 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20041225234236.GA65841@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: deadc0de panic in unmount() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 25 Dec 2004 23:42:57 -0000 -current from a few days ago. It was probably unmounting a nullfs, devfs or linprocfs. panic(c06f100c,63676b70,c06efede,e4,c06f4bb5) at panic+0xac _mtx_lock_spin(deadc0de,0,c06efede,e4,c06f9e60) at _mtx_lock_spin lockmgr(c59df420,10007,c077c480,ca6e1000,379) at lockmgr+0x132 dounmount(c59df400,8080000,ca6e1000,379,734ff58) at dounmount+0xa5 unmount(ca6e1000,f13a6d14,8,e,2) at unmount+0x1f4 syscall(2f,2f,2f,82ff704,8573911) at syscall+0x13b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (22, FreeBSD ELF32, unmount), eip = 0x82a21df, esp = 0xbfbfe0ac, ebp = 0xbfbfe168 --- db> x/x 0xc59df420 0xc59df420: deadc0de db> x/x 0xc59df400 0xc59df400: deadc0de Kris