From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 00:36: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 10AD016A4CE for ; Sun, 5 Sep 2004 00:36:03 +0000 (GMT) Received: from mmp.dnsalias.org (YahooBB218179180003.bbtec.net [218.179.180.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 1221E43D45 for ; Sun, 5 Sep 2004 00:36:02 +0000 (GMT) (envelope-from thasegawa@mta.biglobe.ne.jp) Received: (qmail 799 invoked from network); 5 Sep 2004 00:36:17 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 0 with SMTP; 5 Sep 2004 00:36:17 -0000 Date: Sun, 05 Sep 2004 09:35:53 +0900 (JST) Message-Id: <20040905.093553.74751692.thasegawa@mta.biglobe.ne.jp> To: imp@bsdimp.com From: HASEGAWA Tomoki In-Reply-To: <20040904.024213.102230434.imp@bsdimp.com> References: <20040903.210734.89664548.imp@bsdimp.com> <20040904.143636.41626215.thasegawa@mta.biglobe.ne.jp> <20040904.024213.102230434.imp@bsdimp.com> X-Mailer: Mew version 4.0.66 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 Subject: Re: pccard fixed disk not work on 5.3-BETA 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, 05 Sep 2004 00:36:03 -0000 I see. Using the kernel compiled with pccard, the cards works well. Thank you. imp> Is pccard a module or compiled into the kernel? If it is a module only, imp> then there will be no ata pccard attachment in the kernel, which could imp> be your problem. From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 01:46: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 23F6116A4CE for ; Sun, 5 Sep 2004 01:46:34 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97C7543D55 for ; Sun, 5 Sep 2004 01:46:33 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with SMTP id i851kWuX022492 for ; Sun, 5 Sep 2004 10:46:32 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 5 Sep 2004 10:46:32 +0900 (JST) Message-Id: <200409050146.i851kWuX022492@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Sun, 05 Sep 2004 10:46:32 +0900 (JST) Subject: 5.3-BETA2 panic on qemu 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, 05 Sep 2004 01:46:34 -0000 Sorry, I don't have *realy* Sound Blaster16. This is about *virtual*(=qemu) Sound Blaster16. So I don't know true or false alert. [ENVIRONMENT] FreeBSD 5.3-BETA2 on QEMU 0.6.0-2004-08-26_23. KERNEL is GENERIC [uname -a] # uname -a FreeBSD 5.3-BETA2 FreeBSD 5.3-BETA2 #1: Sat Aug 28 21:29:15 UTC 2004 root@mack.dcsl.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [I did] I play a wav file. As soon as panic: SEE ALSO: http://tmp.ninth-nine.com/qemu/qemu1.png (upper grabbed screenshot) http://tmp.ninth-nine.com/qemu/qemu2.png (bottom grabbed screenshot) [boot -sv] (snip) sbc0: at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 sbc0: setting card to irq 5, drq 1, 5 sbc0: [GIANT-LOCKED] pcm0: on sbc0 pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap ffe000, 1000; 0xcc761000 -> ffe000 pcm0: sndbuf_setmap ffd000, 1000; 0xcc762000 -> ffd000 (snip) [cat /dev/sndstat] # cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: # [/boot/loader.conf] hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" snd_sb16_load="YES" And, I think that there is a problem in /usr/src/sys/conf/NOTES. Are following lines collect? - - - - - - - - - - - - - - - hint.snd_sbc.0.at="isa" hint.snd_sbc.0.port="0x220" hint.snd_sbc.0.irq="5" hint.snd_sbc.0.drq="1" hint.snd_sbc.0.flags="0x15" - - - - - - - - - - - - - - - In this case, FreeBSD didn't probe SB16. From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 01:47: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 141B816A536 for ; Sun, 5 Sep 2004 01:46:59 +0000 (GMT) Received: from out007.verizon.net (out007pub.verizon.net [206.46.170.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83AD943D3F for ; Sun, 5 Sep 2004 01:46:58 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([141.153.207.21]) by out007.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040905014657.PUGN1210.out007.verizon.net@[10.0.3.231]> for ; Sat, 4 Sep 2004 20:46:57 -0500 From: "Alexandre \"Sunny\" Kovalenko" To: current@freebsd.org Content-Type: text/plain Message-Id: <1094348789.74537.18.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 04 Sep 2004 21:46:30 -0400 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out007.verizon.net from [141.153.207.21] at Sat, 4 Sep 2004 20:46:57 -0500 Subject: AMD64 MP, ULE and threaded applications 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, 05 Sep 2004 01:47:02 -0000 I am slightly confused whether I should post 5.3 BETA related stuff here or in stable@, so feel free to chastise me as appropriate. I have fairly simple program which is heavily CPU bound and could be easily parallelized. Recently I laid my hands on dual AMD64 no-brand machine and installed 5.3 BETA1 on it. With SCHED_ULE, no number of threads would deliver more then single CPU performance, and 'top' will report 50% CPU utilization. With SCHED_4BSD, two threads would deliver ~185% of single CPU performance and 'top' will report 100% spent in userland. Test application could be found here: http://members.verizon.net/~akovalenko/PDFPassword.tar.gz To build, just type 'make'. To run, type ./PDFPassword OValue <# of threads to start> I use this benchmark on variety of MP hardware (Sun, RS/6000, Intel) and throughput usually follows number of threads up to number of available CPU. I will bring this system up to RELENG_5 as of Saturday (9/4) morning EST some time on Monday and retest. I can also test patches or try oprions as needed. Unfortunately, I would not be able to provide remote access to this box. --- Alexandre "Sunny" Kovalenko. From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 03:32: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 617B716A4CE; Sun, 5 Sep 2004 03:32:57 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147C943D31; Sun, 5 Sep 2004 03:32: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 i853WuB4068675; Sat, 4 Sep 2004 23:32:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i853WuP4065293; Sat, 4 Sep 2004 23:32:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4DE867303F; Sat, 4 Sep 2004 23:32:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905033256.4DE867303F@freebsd-current.sentex.ca> Date: Sat, 4 Sep 2004 23:32:56 -0400 (EDT) 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: Sun, 05 Sep 2004 03:32:57 -0000 TB --- 2004-09-05 02:25:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 02:25:13 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-05 02:25:13 - checking out the source tree TB --- 2004-09-05 02:25:13 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-05 02:25:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 02:30:23 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 02:30:23 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-05 02:30:23 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c: In function `auth_ReadHeader': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:447: warning: unsigned int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:451: warning: unsigned int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c: In function `auth_ReadName': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:462: warning: unsigned int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:468: warning: unsigned int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:468: warning: unsigned int format, different type arg (arg 4) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-05 03:32:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 03:32:56 - ERROR: failed to build world TB --- 2004-09-05 03:32:56 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 05:30: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 2636A16A4CE; Sun, 5 Sep 2004 05:30:15 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91BAB43D5A; Sun, 5 Sep 2004 05:30:14 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id i855U6MH080495; Sun, 5 Sep 2004 14:30:06 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id i855U5Yc080494; Sun, 5 Sep 2004 14:30:05 +0900 (KST) (envelope-from ssw) Date: Sun, 5 Sep 2004 14:30:05 +0900 From: Sangwoo Shim To: Robert Watson Message-ID: <20040905053005.GA80420@neo.redjade.org> References: <20040904192218.GA5879@miranda.expro.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: w@expro.pl cc: mlaier@freebsd.org cc: current@freebsd.org Subject: Re: syscons problem in ddb, if_afdata initialization (was: Re: 5.3-BETA3 , panic, probably IPv6+SMP+mpsafenet related) 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, 05 Sep 2004 05:30:15 -0000 I've reported nd6_slowtimo related panic some while ago. Please check kern/70393. mlaier@ suggested a patch to address this, but that wasn't work for me. I'll try your patch and report. Thanks. Regards, Sangwoo On Sat, Sep 04, 2004 at 03:33:28PM -0400, Robert Watson wrote: > > On Sat, 4 Sep 2004, Jan Srzednicki wrote: > > > OK. I'm not sure if I'm doing that the right way, but here it is: > > Yes, this was exactly what I was looking for. Thanks! > > > > > Hope this helps. > > > > It's also worth noting that on the previous kernel (that is: FreeBSD > > 5.3-BETA2 (SIN) #9: Sun Aug 29 14:24:19 CEST 2004) nothing like that > > happened, so it appears to be somehow related to (or uncovered by) some > > very recent commit. > > Could you try this patch: > > Index: nd6.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v > retrieving revision 1.44 > diff -u -r1.44 nd6.c > --- nd6.c 23 Aug 2004 03:00:27 -0000 1.44 > +++ nd6.c 4 Sep 2004 19:34:39 -0000 > @@ -134,6 +134,7 @@ > nd6_init_done = 1; > > /* start timer */ > + callout_init(&nd6_slowtimo_ch, 0); > callout_reset(&nd6_slowtimo_ch, ND6_SLOWTIMER_INTERVAL * hz, > nd6_slowtimo, NULL); > } > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 05:38: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 850BE16A4CE for ; Sun, 5 Sep 2004 05:38:41 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A7443D1F for ; Sun, 5 Sep 2004 05:38:41 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6622172DD4; Sat, 4 Sep 2004 22:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6143772DCB; Sat, 4 Sep 2004 22:38:41 -0700 (PDT) Date: Sat, 4 Sep 2004 22:38:41 -0700 (PDT) From: Doug White To: Maxim Maximov In-Reply-To: <41337564.7090905@mcsi.pp.ru> Message-ID: <20040904222320.I39360@carver.gumbysoft.com> References: <412FA7E8.80BE87BC@freebsd.org> <20040829172000.F69068@carver.gumbysoft.com> <20040830105333.L85743@carver.gumbysoft.com> <41337564.7090905@mcsi.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: [PATCH] poll() hang with X apps 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, 05 Sep 2004 05:38:41 -0000 Attaching to an earlier message here... rwatson and I may have a solution to the poll() hangs you have been experiencing. Try downloading and applying this patch: http://www.watson.org/~robert/freebsd/netperf/20040905-sopoll.diff This seems to stop the hangs on my test system (2x600MHz P3 with XFree 4.3). I'll test it with its partner, a RELENG_5 box with either Xorg or XFree86 4.4. Please test it and get back to us if its working for you. For those of you tuning in late: Maxim has been having problems with WindowMaker dockapps not starting up all the way, with the app hanging in a poll() call in the X library while trying to draw itself. I am able to reproduce the problem by starting up a xscreensaver hack (rubik is my favorite right now) and running a -j3 buildworld in the background. Within a couple of minutes rubik would stop moving; focussing the window would wake it back up again. ps axl would show it in 'select' and gdb found it in a poll() call in a XPixmap primitive. This patch changes the socket locking to lock both send and receive buffers while poll() is scanning the file descriptor for available data. We think that the prior locking was allowing one process to write data into the socket buffers after it had been scanned and the decision made that there was no data on the socket. Thus the process would be put to sleep with available data. Another write to the socket (focussing the app in the test case) would cause it to be woken up. Again, please test and let me or rwatson know if you have feedback. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 05:46: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 6CC4216A4CE for ; Sun, 5 Sep 2004 05:46:57 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E9F743D2D for ; Sun, 5 Sep 2004 05:46:56 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.16.93] (ppp16-93.pppoe.mtu-net.ru [81.195.16.93]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i855kg1R095684; Sun, 5 Sep 2004 09:46:48 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <413AA83C.7060108@mcsi.pp.ru> Date: Sun, 05 Sep 2004 09:46:36 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Doug White References: <412FA7E8.80BE87BC@freebsd.org> <20040829172000.F69068@carver.gumbysoft.com> <4132A956.4070604@mcsi.pp.ru> <20040830105333.L85743@carver.gumbysoft.com> <41337564.7090905@mcsi.pp.ru> <20040904222320.I39360@carver.gumbysoft.com> In-Reply-To: <20040904222320.I39360@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: freebsd-current@freebsd.org Subject: Re: [PATCH] poll() hang with X apps 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, 05 Sep 2004 05:46:57 -0000 Doug White wrote: > Attaching to an earlier message here... > > rwatson and I may have a solution to the poll() hangs you have been > experiencing. Try downloading and applying this patch: > > http://www.watson.org/~robert/freebsd/netperf/20040905-sopoll.diff > > This seems to stop the hangs on my test system (2x600MHz P3 with XFree > 4.3). I'll test it with its partner, a RELENG_5 box with either Xorg or > XFree86 4.4. Please test it and get back to us if its working for you. Oh my! I'm recompiling my kernel already! I began to think that this problem was abandoned, but there were work going on! Thank you and Robert! -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 05:51: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 84ACD16A4CE for ; Sun, 5 Sep 2004 05:51:19 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2858543D3F for ; Sun, 5 Sep 2004 05:51:19 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i855mXB7001760; Sun, 5 Sep 2004 01:48:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i855mXLU001757; Sun, 5 Sep 2004 01:48:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 5 Sep 2004 01:48:33 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxim Maximov In-Reply-To: <413AA83C.7060108@mcsi.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: [PATCH] poll() hang with X apps 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, 05 Sep 2004 05:51:19 -0000 On Sun, 5 Sep 2004, Maxim Maximov wrote: > Doug White wrote: > > Attaching to an earlier message here... > > > > rwatson and I may have a solution to the poll() hangs you have been > > experiencing. Try downloading and applying this patch: > > > > http://www.watson.org/~robert/freebsd/netperf/20040905-sopoll.diff > > > > This seems to stop the hangs on my test system (2x600MHz P3 with XFree > > 4.3). I'll test it with its partner, a RELENG_5 box with either Xorg or > > XFree86 4.4. Please test it and get back to us if its working for you. > > Oh my! I'm recompiling my kernel already! > > I began to think that this problem was abandoned, but there were work > going on! Thank you and Robert! Yeah, I had a good idea about what the problem might be, but I couldn't reproduce it here. Happily, Doug could and was willing to spend a lot of time with the debugger to track stuff down. Turns out it may have been a potential race I tagged when I was originally reviewing that element of socket locking, but hadn't yet had a chance to revisit. If the patch fixes it, wonderful! If not, there are one or two other things in the polling/select code that could use review. Assuming this patch does fix the problem for you (it did for Doug), I'll get it merged into HEAD tomorrow, and RELENG_5 a few days later. Thanks for your bug report, and we'll see how it goes :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 05:55: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 B9D2916A4CE; Sun, 5 Sep 2004 05:55:24 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47C8443D46; Sun, 5 Sep 2004 05:55:24 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i855qWIO001823; Sun, 5 Sep 2004 01:52:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i855qWRf001820; Sun, 5 Sep 2004 01:52:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 5 Sep 2004 01:52:32 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Sangwoo Shim In-Reply-To: <20040905053005.GA80420@neo.redjade.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: w@expro.pl cc: mlaier@freebsd.org cc: current@freebsd.org Subject: Re: syscons problem in ddb, if_afdata initialization (was: Re: 5.3-BETA3 , panic, probably IPv6+SMP+mpsafenet related) 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, 05 Sep 2004 05:55:24 -0000 On Sun, 5 Sep 2004, Sangwoo Shim wrote: > I've reported nd6_slowtimo related panic some while ago. Please check > kern/70393. mlaier@ suggested a patch to address this, but that wasn't > work for me. I'll try your patch and report. Thanks. This patch may only fix the problem if running with debug.mpsafenet=0; I'm currently exploring the more general if_afdata issues, and will look at Max's patch (etc) in the report. I hope to have a patch that solves it in the non-mpsafenet case in a day or two. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > Regards, > Sangwoo > > On Sat, Sep 04, 2004 at 03:33:28PM -0400, Robert Watson wrote: > > > > On Sat, 4 Sep 2004, Jan Srzednicki wrote: > > > > > OK. I'm not sure if I'm doing that the right way, but here it is: > > > > Yes, this was exactly what I was looking for. Thanks! > > > > > > > > > Hope this helps. > > > > > > It's also worth noting that on the previous kernel (that is: FreeBSD > > > 5.3-BETA2 (SIN) #9: Sun Aug 29 14:24:19 CEST 2004) nothing like that > > > happened, so it appears to be somehow related to (or uncovered by) some > > > very recent commit. > > > > Could you try this patch: > > > > Index: nd6.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v > > retrieving revision 1.44 > > diff -u -r1.44 nd6.c > > --- nd6.c 23 Aug 2004 03:00:27 -0000 1.44 > > +++ nd6.c 4 Sep 2004 19:34:39 -0000 > > @@ -134,6 +134,7 @@ > > nd6_init_done = 1; > > > > /* start timer */ > > + callout_init(&nd6_slowtimo_ch, 0); > > callout_reset(&nd6_slowtimo_ch, ND6_SLOWTIMER_INTERVAL * hz, > > nd6_slowtimo, NULL); > > } > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 06:46: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 4E06116A4CE for ; Sun, 5 Sep 2004 06:46:50 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D26643D2D for ; Sun, 5 Sep 2004 06:46:50 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (211.26.208.98) by smtp01.syd.iprimus.net.au (7.0.028) id 412F6C14002D78A1; Sun, 5 Sep 2004 16:46:44 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 627BE420D; Sun, 5 Sep 2004 16:46:49 +1000 (EST) Date: Sun, 5 Sep 2004 16:46:49 +1000 From: Tim Robbins To: Bjoern Koenig Message-ID: <20040905064649.GA94688@cat.robbins.dropbear.id.au> References: <20040903102820.F0D536233@hoppel.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903102820.F0D536233@hoppel.local> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: mount_smbfs fails once 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, 05 Sep 2004 06:46:50 -0000 On Fri, Sep 03, 2004 at 12:29:07PM +0200, Bjoern Koenig wrote: > Since 5.3-BETA1 and BETA2 there is a misbehaviour with mounting a samba > share. A first try fails: > > # mount_smbfs //hostname/share directory/ > mount_smbfs: kldload(smbfs): No such file or directory > > smbfs.ko was automatically loaded as expected and now a second try is > successful. I committed a fix for this a few minutes ago. Could you please update src/contrib/smbfs/mount_smbfs/mount_smbfs.c to revision 1.5, rebuild mount_smbfs or world, and confirm that it solves the problem? Tim From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:06: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 DEFF716A4CE; Sun, 5 Sep 2004 08:06:23 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF7BE43D2D; Sun, 5 Sep 2004 08:06:22 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.2.133] (ppp2-133.pppoe.mtu-net.ru [81.195.2.133]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i8586ETP051520; Sun, 5 Sep 2004 12:06:15 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <413AC8F1.9020601@mcsi.pp.ru> Date: Sun, 05 Sep 2004 12:06:09 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: freebsd-current@freebsd.org Subject: Re: [PATCH] poll() hang with X apps 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, 05 Sep 2004 08:06:24 -0000 Robert Watson wrote: > On Sun, 5 Sep 2004, Maxim Maximov wrote: > > >>Doug White wrote: >> >>>Attaching to an earlier message here... >>> >>>rwatson and I may have a solution to the poll() hangs you have been >>>experiencing. Try downloading and applying this patch: >>> >>>http://www.watson.org/~robert/freebsd/netperf/20040905-sopoll.diff >>> >>>This seems to stop the hangs on my test system (2x600MHz P3 with XFree >>>4.3). I'll test it with its partner, a RELENG_5 box with either Xorg or >>>XFree86 4.4. Please test it and get back to us if its working for you. >> >>Oh my! I'm recompiling my kernel already! >> >>I began to think that this problem was abandoned, but there were work >>going on! Thank you and Robert! > > > Yeah, I had a good idea about what the problem might be, but I couldn't > reproduce it here. Happily, Doug could and was willing to spend a lot of > time with the debugger to track stuff down. Turns out it may have been a > potential race I tagged when I was originally reviewing that element of > socket locking, but hadn't yet had a chance to revisit. If the patch > fixes it, wonderful! If not, there are one or two other things in the > polling/select code that could use review. Assuming this patch does fix > the problem for you (it did for Doug), I'll get it merged into HEAD > tomorrow, and RELENG_5 a few days later. > > Thanks for your bug report, and we'll see how it goes :-). It goes very well. Easily reproducible xscreensaver hacks hangs described by Doug are gone for me too. I believe the patch also solves my dockapp problems. I haven't seen any wmdockapps hangs yet, but they are harder to reproduce, so only time will tell. I guess this patch should be merged anyway. At least for xscreensaver related hangs :) -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:47: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 1B9A516A4CE; Sun, 5 Sep 2004 08:47:54 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1EB743D3F; Sun, 5 Sep 2004 08:47: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 i858lrJq095191; Sun, 5 Sep 2004 04:47:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i858lrFO066072; Sun, 5 Sep 2004 04:47:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E5A357303F; Sun, 5 Sep 2004 04:47:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905084752.E5A357303F@freebsd-current.sentex.ca> Date: Sun, 5 Sep 2004 04:47:52 -0400 (EDT) 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: Sun, 05 Sep 2004 08:47:54 -0000 TB --- 2004-09-05 07:16:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 07:16:34 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-09-05 07:16:34 - checking out the source tree TB --- 2004-09-05 07:16:34 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-09-05 07:16:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 07:23:47 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 07:23:47 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-05 07:23:47 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/main.c cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/perform.c cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -o pkg_version main.o perform.o /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib/libinstall.a -lfetch -lmd -lssl -lcrypto gzip -cn /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/pkg_version.1 > pkg_version.1.gz ===> usr.sbin/ppp cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp/acf.c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp/acf.c: In function `acf_LayerPull': /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp/acf.c:76: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-09-05 08:47:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 08:47:52 - ERROR: failed to build world TB --- 2004-09-05 08:47:52 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:03: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 4E5CE16A4CE for ; Sun, 5 Sep 2004 09:03:26 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8545A43D41 for ; Sun, 5 Sep 2004 09:03:25 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.2.167] (ppp2-167.pppoe.mtu-net.ru [81.195.2.167]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i8593IYr054043 for ; Sun, 5 Sep 2004 13:03:19 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <413AD651.2030504@mcsi.pp.ru> Date: Sun, 05 Sep 2004 13:03:13 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru Subject: KQUEUE/TTY related 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: Sun, 05 Sep 2004 09:03:26 -0000 Hello. Just got a panic when dropped into DDB by Ctrl-Alt-Esc, issued 'show witness', pressed ScrLk, pressed PgUp ten times, then PgDn. Then released cursor by pressing ScrLk again. db> panic: blockable sleep lock (sleep mutex) tty @ /usr/src/sys/kern/kern_event.c:1450 cpuid = 0 boot() called on cpu#0 Uptime: 2m22s Machine freezes completely here. Keys didn't work. Reset helped. Tried exactly the same actions after reboot - exactly same effect. Machine is SMP, HTT, WITNESS enabled, today's HEAD. Dmesg is at http://mcsi.pp.ru/dmesg.boot -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09:55: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 540BC16A4CF; Sun, 5 Sep 2004 09:55:45 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E998C43D31; Sun, 5 Sep 2004 09:55:44 +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 i859tirp010982; Sun, 5 Sep 2004 05:55:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i859tikZ062413; Sun, 5 Sep 2004 05:55:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EA9A87303F; Sun, 5 Sep 2004 05:55:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905095543.EA9A87303F@freebsd-current.sentex.ca> Date: Sun, 5 Sep 2004 05:55:43 -0400 (EDT) Subject: [current tinderbox] failure on powerpc/powerpc 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: Sun, 05 Sep 2004 09:55:45 -0000 TB --- 2004-09-05 08:47:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 08:47:53 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2004-09-05 08:47:53 - checking out the source tree TB --- 2004-09-05 08:47:53 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2004-09-05 08:47:53 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 08:52:50 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 08:52:50 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2004-09-05 08:52:50 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/vjcomp.c cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/nat_cmd.c cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/atm.c cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/id.c cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/chap_ms.c cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/mppe.c /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/mppe.c: In function `MPPEInitOptsOutput': /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp/mppe.c:522: warning: null argument where non-null required (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2004-09-05 09:55:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 09:55:43 - ERROR: failed to build world TB --- 2004-09-05 09:55:43 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 11:01: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 D5F6116A4CE; Sun, 5 Sep 2004 11:01:43 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 858A043D41; Sun, 5 Sep 2004 11:01:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i85B1gli007268; Sun, 5 Sep 2004 07:01:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i85B1fTH082051; Sun, 5 Sep 2004 07:01:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2A4F27303F; Sun, 5 Sep 2004 07:01:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905110142.2A4F27303F@freebsd-current.sentex.ca> Date: Sun, 5 Sep 2004 07:01:42 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 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: Sun, 05 Sep 2004 11:01:44 -0000 TB --- 2004-09-05 09:55:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 09:55:44 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-09-05 09:55:44 - checking out the source tree TB --- 2004-09-05 09:55:44 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-09-05 09:55:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 10:00:45 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 10:00:45 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-05 10:00:45 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/main.c cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/perform.c cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -o pkg_version main.o perform.o /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib/libinstall.a -lfetch -lmd -lssl -lcrypto gzip -cn /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/pkg_version.1 > pkg_version.1.gz ===> usr.sbin/ppp cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp/acf.c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp/acf.c: In function `acf_LayerPull': /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp/acf.c:76: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-09-05 11:01:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 11:01:41 - ERROR: failed to build world TB --- 2004-09-05 11:01:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 17:53: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 CE57716A4CE; Sat, 4 Sep 2004 17:53:00 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-161-125.dclient.hispeed.ch [80.219.161.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951DF43D2F; Sat, 4 Sep 2004 17:52:59 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a17d:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i84Hqr401025 verified NO); Sat, 4 Sep 2004 19:52:58 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i84HqqL01024; Sat, 4 Sep 2004 19:52:53 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sat, 4 Sep 2004 19:52:53 +0200 (CEST) Message-Id: <200409041752.i84HqqL01024@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: current@FreeBSD.org References: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> <20040829143403.GE23120@ip.net.ua> X-Mailman-Approved-At: Sun, 05 Sep 2004 11:57:49 +0000 cc: Ruslan Ermilov Subject: Re: M*K**BJD*RPR*F*X and make.conf 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, 04 Sep 2004 17:53:01 -0000 [sorry for the delay in getting this message out. Source in question is from early 30.Aug.] Hello neighbour. Can you say, Flogging a Deceased Equine? Sure, I knew you could... > > I fully understand that you hate me now. > I will hate you if, after reading these, you still disagree. ;) You are no fun, I must try harder... Un(?)fortunately, I can't easily demonstrate the failure that I wanted to prevent. It probably happens later after other failures in my build. However, here are some interesting observations: My FreeBSD-4 `make -d v buildworld' in 6-CURRENT source fails, period. "Makefile", line 92: MAKEOBJDIRPREFIX can only be set in environment, not as a g lobal (in /etc/make.conf) or command-line variable. Drop the `-d v' and it doesn't bomb there. This is probably not unexpected. ;-) It is better with a later `make' which sends the debug output to stderr, not to stdout. The above test also does not fail when MAKEOBJDIRPREFIX is given as command-line variable, using FreeBSD-4 `make'. (I mean, I don't get the above warning, giving command-line variable, and it continues with the build.) Anyway, what I try to demonstrate is setting MAKEOBJDIRPREFIX in __MAKE_CONF. This avoids the check in the -current Makefile and in releng_5 Makefile.inc (which was the reason for my previous patch-like thing). [00:22:41]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1063}$ grep MAKEOBJ /etc/make.conf # MAKEOBJDIRPREFIX?= /usr/obj/${RELNAME} ## Let's break the build elsewhere... MAKEOBJDIRPREFIX?= /usr/obj/${RELNAME} [00:22:59]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1064}$ grep -v ^# /dist/build/build-freebsd-current MOUNT=`/sbin/mount -t union` UNION=`echo $MOUNT | /usr/bin/egrep ":.*/src/FreeBSD6-src/source-hacks on .*/src/FreeBSD6-src/src \(union,"` if [ $? -ne 0 ] ; then echo echo "Must union-mount source-hacks before building..." echo exit 68 fi ( cd `dirname $0`/../src/FreeBSD6-src/src && time env TARGET_ARCH=i386 __MAKE_CONF=`dirname $0`/../conf/current/make.conf make -DNOCLEAN buildworld ) [00:23:04]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1065}$ time nice -20 sh !$ -------------------------------------------------------------- >>> Building an up-to-date make(1) -------------------------------------------------------------- mkdir: /usr/obj/dist: Read-only file system *** Error code 1 Stop in /dist/src/FreeBSD6-src/src/usr.bin/make. [ ... ] [00:34:48]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1071}$ grep MAKEO /dist/conf/current/make.conf # MAKEOBJDIRPREFIX?= /usr/obj/${RELNAME} MAKEOBJDIRPREFIX= /dist/obj/${RELNAME} Ah, well. If I specify a MAKEOBJDIRPREFIX on the command-line, it also passes by the test. YES I KNOW I'M NOT SUPPOSED TO DO THIS. Just like I'm not supposed to do the above. I'm deliberately avoiding setting the environment, for the sake of science. My point is that I don't have MAKEOBJDIRPREFIX in /etc/make.conf but instead in __MAKE_CONF, yet the build goes ahead... Anyway, now I have two MAKEOBJDIRPREFIXen, and the up-to-date make gets put in the command-line location, while the next step (temporary build tree) gets put in the __MAKE_CONF location. I've specified two different locations to be even more wrong and to see which gets used where ... >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /dist/obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/include while later, in the legacy release compatibility shims, both locations appear: >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /dist/src/FreeBSD6-src/src; MAKEOBJDIRPREFIX=/dist/obj/4.10-STABLE/dist/src/F __MAKE_CONF location ^^^^^^^^^^^^ reeBSD6-src/src/i386 INSTALL="sh /dist/src/FreeBSD6-src/src/tools/install.sh" PATH=/dist/obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/sbin:/dist/ obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/bin:/dist/obj/4.10-STA BLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bi n WORLDTMP=/dist/obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386 MAKEFLAGS="-m /dist/src/FreeBSD6-src/src/tools/build/mk -D NOCLEAN -m /dist/src/FreeBSD6-src/ src/share/mk" /dist/obj/crash/dist/src/FreeBSD6-src/src/make.i386/make -f Makefi commandline location ^^^^ le.inc1 DESTDIR= BOOTSTRAPPING=450000 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNO PIC -DNOPROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS legacy ===> tools/build cd /dist/src/FreeBSD6-src/src/tools/build; /dist/obj/crash/dist/src/FreeBSD6-src /src/make.i386/make buildincludes; /dist/obj/crash/dist/src/FreeBSD6-src/src/mak e.i386/make installincludes sh /dist/src/FreeBSD6-src/src/tools/install.sh -C -o root -g wheel -m 444 langi nfo.h /dist/src/FreeBSD6-src/src/tools/build/../../include/getopt.h regex.h /dis t/obj/4.10-STABLE/legacy/usr/include ^^^^^^^^^^^^^^^^^^^^^^ this directory doesn't even exist... This is an example of what I should *NOT* be allowed to do. However, the Makefile/.inc1 check you added recently was not able to stop me from doing so... I'm guessing the FBSD-4 `make' doesn't work properly with your test when using the improper command-line form, but a later `make' would. The following test appears to bear this out: [02:55:26]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{845}$ env -i /dist/ob j/crash/dist/src/FreeBSD6-src/src/make.i386/make MAKEOBJDIRPREFIX=/dist/obj -f /dev/null -V MAKEOBJDIRPREFIX -d v dummy 2>&1 | grep -e '\(t/obj\|EOBJD\)' Global:.MAKEFLAGS = MAKEOBJDIRPREFIX=/dist/obj -V MAKEOBJDIRPREFIX -d Global:.MAKEFLAGS = MAKEOBJDIRPREFIX=/dist/obj -V MAKEOBJDIRPREFIX -d v Global:MFLAGS = -V MAKEOBJDIRPREFIX -d Global:MFLAGS = -V MAKEOBJDIRPREFIX -d v Applying :M to " MAKEOBJDIRPREFIX=/dist/obj -V MAKEOBJDIRPREFIX -d v" /dist/obj whilst with FBSD-4 `make': [02:55:47]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{846}$ env -i make MAK EOBJDIRPREFIX=/dist/obj -f /dev/null -V MAKEOBJDIRPREFIX -d v dummy | grep -e '\(t/obj\|EOBJD\)' Global:.MAKEFLAGS = -V MAKEOBJDIRPREFIX -d Global:.MAKEFLAGS = -V MAKEOBJDIRPREFIX -d v Applying :M to " -V MAKEOBJDIRPREFIX -d v" Global:MFLAGS = -V MAKEOBJDIRPREFIX -d v /dist/obj Indeed, if I invoke make as in the first instance above, I fall over your test (tested with releng-5). My /usr/share/mk has no mention of __MAKE_CONF while it's present in later RELENG_4; I suspect this is why building an up-to-date `make' failed to find the improperly-specified MAKEOBJDIRPREFIX in the __MAKE_CONF I gave. Or something. Is the fact that upgrade_checks calls ``make make'' without `-m .../mk' the reason for this? Is it dangerous to specify the newest src/share/mk at this point? I suspect it is. If so, I suspect that the -current Makefile test would also fail with my old /usr/share/mk when handed __MAKE_CONF, while that in releng_5 Makefile.inc1 would successfully stop my build, which is what I want to happen. This is the case, as _MAKE with `-m' is used with .inc1) Sorry if this isn't clear. Even I have a hard time explaining it myself. I want your test to stop me from being able to do the things I can do above, if it's possible, but I suspect that my /usr/share/mk is too old to help with -current, as is my `make'... Anyway, I don't have a solution to prevent someone from using an older `make' and passing `MAKEOBJDIRPREFIX=/foo' as a command-line variable; however, for -current, I've changed the following in Makefile which helps when I've given __MAKE_CONF: _MAKEOBJDIRPREFIX!= env -i PATH=${PATH} __MAKE_CONF=${__MAKE_CONF} \ MAKEFLAGS="${.MAKEFLAGS}" ${MAKE} \ -m ${.CURDIR}/share/mk -f /dev/null -V MAKEOBJDIRPREFIX dummy With this, I can no longer build: [03:54:13]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:/dist/src/FreeBSD6-src/ src{1212}$ time nice env TARGET_ARCH=i386 __MAKE_CONF=/dist/conf/current/make. conf make -DNOCLEAN buildworld "Makefile", line 93: MAKEOBJDIRPREFIX /dist/obj/4.10-STABLE can only be set in environment, not as a global (in /etc/make.conf) or command-line variable. This is what you want. Believe me. Still, I'm not sure if it is safe to use `-m' here, although it does work with my 4.x. (Hm, is it safe to use ${MAKE} here, seeing that later in the makefile one `make make's to build an up-to-date, probably for the case where `make' doesn't set `${MAKE}'... Ignore me.) thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 21:40: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 2CADE16A4CE; Sat, 4 Sep 2004 21:40:18 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E6E843D31; Sat, 4 Sep 2004 21:40:17 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <413A363D.5080306@geminix.org> Date: Sat, 04 Sep 2004 23:40:13 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040808 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca><41365746.2030605@samsco.org> <20040901224632.O72978@ganymede.hub.org> <41394D0B.1050004@elischer.org> <20040904131131.A812@ganymede.hub.org> <200409041857.i84Ive1n046689@apollo.backplane.com> In-Reply-To: <200409041857.i84Ive1n046689@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1C3iGd-0005x2-00; Sat, 04 Sep 2004 23:40:16 +0200 X-Mailman-Approved-At: Sun, 05 Sep 2004 11:57:49 +0000 cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? 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, 04 Sep 2004 21:40:18 -0000 Matthew Dillon wrote: > [cached union FS vnodes keeping vnodes of underlying FS referenced] > An easy way to fix this, presuming that there are no bugs in unionfs > keeping the underlying vnode from being dereferenced, is to have a > system call which explicitly flushes all the vnodes with no references > associated with a mount point. You could then flush the unionfs mounts > in order to synchronize the destruction of removed files & directories > in underlying filesystems. You could do this once an hour or so to > greatly reduce the instances of 0-length directories. It's an incredible hack, but try this: cd /path/to/fs && umount /path/to/fs >/dev/null 2>&1 Fails of course, but reliably blows away all cached unreferenced vnodes associated with the respective mount point, due to the way unmount(2) is implemented in the kernel. Or at least in RELENG_4, that is. Can't tell for CURRENT. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 08:14: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 8A04416A4CE for ; Sun, 5 Sep 2004 08:14:00 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A86943D1F for ; Sun, 5 Sep 2004 08:14:00 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from hoppel.local (port-212-202-38-171.dynamic.qsc.de [212.202.38.171]) by mail.efacilitas.de (Postfix) with ESMTP id 11CBF123796 for ; Sun, 5 Sep 2004 10:13:01 +0200 (CEST) Received: from alpha (unknown [192.168.1.2]) by hoppel.local (Postfix) with ESMTP id 362C961AF for ; Sun, 5 Sep 2004 10:14:00 +0200 (CEST) From: "Bjoern Koenig" To: Date: Sun, 5 Sep 2004 10:14:54 +0200 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSTIGy0gaiZoNE5R0a9F2KJFU+MAw== Message-Id: <20040905081400.362C961AF@hoppel.local> X-Mailman-Approved-At: Sun, 05 Sep 2004 11:57:49 +0000 Subject: Re: mount_smbfs fails once 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, 05 Sep 2004 08:14:00 -0000 The changes in src/contrib/smbfs/mount_smbfs/mount_smbfs.c revision 1.5 solved the problem. Regards Bj=F6rn From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 09: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 394B316A4CE for ; Sun, 5 Sep 2004 09:57:03 +0000 (GMT) Received: from kiuru.kpnet.fi (kiuru.kpnet.fi [193.184.122.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F1443D1D for ; Sun, 5 Sep 2004 09:57:02 +0000 (GMT) (envelope-from midian@ihme.org) Received: from [192.168.1.57] (adsl-36-92.regionline.fi [194.211.36.92]) by kiuru.kpnet.fi (8.12.8/8.12.8) with ESMTP id i859v25t018994 for ; Sun, 5 Sep 2004 12:57:03 +0300 Date: Sun, 5 Sep 2004 12:56:59 +0300 (EEST) From: =?iso-8859-1?Q?Markus_H=E4stbacka?= X-X-Sender: midian@midi.ihme.net To: freebsd-current@freebsd.org Message-ID: <20040905124526.F15143@midi.ihme.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 05 Sep 2004 11:57:49 +0000 Subject: Sound performance problems in FreeBSD 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, 05 Sep 2004 09:57:03 -0000 Hello list, I've experienced sound performance issues from the very first day I tested 5.x. The problem was that sound skipped whatever I did. Now I've reduced the problem a bit with changing my kernel config (No, any debug option isn't on or haven't ever been on when I've tested sound performance). After I recompiled the new kernel the sound didn't skip anymore, but now after 10 hour uptime and 5 hours of mp3 playing the skipping is back. The skipping is like every second there's a weird noise if I listen to something, like the track would go slower for 2/10 seconds of every second, you can imagine how annoying this can be. IMO it feels like some buffer is full or something and then it starts the skipping. My system: FreeBSD miduxBSD 5.3-BETA3 FreeBSD 5.3-BETA3 #0: Sun Sep 5 02:07:42 EEST 2004 midian@miduxBSD:/usr/src/sys/i386/compile/MIDUX i386 01:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) 01:06.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07) Ask if you need more information. Markus From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 12:11: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 0B02B16A4DA; Sun, 5 Sep 2004 12:11:15 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 365CD43D1D; Sun, 5 Sep 2004 12:11:14 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i85CBCwg078341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Sep 2004 16:11:12 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i85CBCUe078340; Sun, 5 Sep 2004 16:11:12 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 5 Sep 2004 16:11:11 +0400 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20040905121111.GA78276@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: [TEST/REVIEW] Netflow implementation 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, 05 Sep 2004 12:11:15 -0000 Collegues, here is netgraph module which implements Netflow traffic accounting, which I'm going to add to CURRENT in recent future: http://cell.sick.ru/~glebius/ng_netflow/ng_netflow-0.3-snap-20040905.tar.gz It is quite different to ng_netflow in ports/net, because its expiry thread is running outside of netgraph context, adding more parrallelizm on flow processing. I've been testing it for last week on loaded 100Mbit Ethernet which serves 9 ASes, 12 prefixes :) And it works stable. P.S. Please reply only to net@ list. I've added current@ just because more people are reading it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 12:22: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 4553216A4CE; Sun, 5 Sep 2004 12:22:07 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D779B43D1D; Sun, 5 Sep 2004 12:22:06 +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 i85CM6WZ022651; Sun, 5 Sep 2004 08:22:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i85CM6pJ005352; Sun, 5 Sep 2004 08:22:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 684327303F; Sun, 5 Sep 2004 08:22:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905122206.684327303F@freebsd-current.sentex.ca> Date: Sun, 5 Sep 2004 08:22:06 -0400 (EDT) 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: Sun, 05 Sep 2004 12:22:07 -0000 TB --- 2004-09-05 11:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 11:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-09-05 11:15:00 - checking out the source tree TB --- 2004-09-05 11:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-09-05 11:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 11:20:22 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 11:20:22 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-05 11:20:22 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/pnpinfo cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pnpinfo/../../sys -c /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pnpinfo/../../contrib/pnpinfo/pnpinfo.c cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pnpinfo/../../sys -o pnpinfo pnpinfo.o -lio gzip -cn /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/pnpinfo/../../contrib/pnpinfo/pnpinfo.8 > pnpinfo.8.gz ===> usr.sbin/ppp cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/ppp/acf.c /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/ppp/acf.c: In function `acf_LayerPull': /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/ppp/acf.c:76: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-09-05 12:22:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 12:22:06 - ERROR: failed to build world TB --- 2004-09-05 12:22:06 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 12:59: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 56CC916A4CE for ; Sun, 5 Sep 2004 12:59:51 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B66D43D1D for ; Sun, 5 Sep 2004 12:59:50 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C3wcS-000CF6-Ph; Sun, 05 Sep 2004 14:59:44 +0200 Date: Sun, 5 Sep 2004 14:59:44 +0200 From: Oliver Brandmueller To: Jeremy Chadwick Message-ID: <20040905125944.GD38513@e-Gitt.NET> References: <20040903013424.GA57576@e-Gitt.NET> <20040903014625.GB57576@e-Gitt.NET> <20040903023846.GA95115@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903023846.GA95115@parodius.com> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller cc: current@freebsd.org Subject: Re: mysql on recent RELENG_5 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, 05 Sep 2004 12:59:51 -0000 Hi. On Thu, Sep 02, 2004 at 07:38:46PM -0700, Jeremy Chadwick wrote: > What's yet to be discussed by anyone is _why_ -march is required for > this to work. Is this a gcc-related problem? It's incredibly easy to > reproduce. I agree with you. With 5.3-RELEASE people will expect MySQL to work out of the box (read: from the package or from ports without tweaking make.conf) on FreeBSD. There's an open bug report ports/70889 on this topic, though it's not very general, but I think it won't help opening a second one. - 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 Sun Sep 5 13:16: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 AFE2016A4CF for ; Sun, 5 Sep 2004 13:16:08 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CC7F43D41 for ; Sun, 5 Sep 2004 13:16:08 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.11/8.12.11) with ESMTP id i85DG8tN093996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Sep 2004 06:16:08 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.11/8.12.11/Submit) id i85DG8Qq093995 for current@freebsd.org; Sun, 5 Sep 2004 06:16:08 -0700 (PDT) (envelope-from jdc) Date: Sun, 5 Sep 2004 06:16:08 -0700 From: Jeremy Chadwick To: current@freebsd.org Message-ID: <20040905131608.GA93905@parodius.com> Mail-Followup-To: current@freebsd.org References: <20040903013424.GA57576@e-Gitt.NET> <20040903014625.GB57576@e-Gitt.NET> <20040903023846.GA95115@parodius.com> <20040905125944.GD38513@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040905125944.GD38513@e-Gitt.NET> User-Agent: Mutt/1.5.6i Subject: Re: mysql on recent RELENG_5 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, 05 Sep 2004 13:16:08 -0000 I agree, opening another bug report on this probably wouldn't do much. However, the only places I've seen it mentioned are here on -current. ports/70889 is also for the alpha architecture, which may (possibly?) be seeing a different error message depending upon what sort-of code is being generated. I don't "mind" having to use CPUTYPE as a workaround (I'm glad there's one at all!); I'm mainly worried that the MySQL folks will begin claiming that "FreeBSD isn't suited for MySQL" because of this problem, or something along those lines. There's enough public misnomers as-is about MySQL on FreeBSD (even a few on the official MySQL site). I'm more than happy to test patches or give someone access to our 5.x SQL box if they want to try and track this down. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sun, Sep 05, 2004 at 02:59:44PM +0200, Oliver Brandmueller wrote: > Hi. > > On Thu, Sep 02, 2004 at 07:38:46PM -0700, Jeremy Chadwick wrote: > > What's yet to be discussed by anyone is _why_ -march is required for > > this to work. Is this a gcc-related problem? It's incredibly easy to > > reproduce. > > I agree with you. With 5.3-RELEASE people will expect MySQL to work out > of the box (read: from the package or from ports without tweaking > make.conf) on FreeBSD. > > There's an open bug report ports/70889 on this topic, though it's not > very general, but I think it won't help opening a second one. > > - 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 Sun Sep 5 13:26: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 802BF16A4CE for ; Sun, 5 Sep 2004 13:26:51 +0000 (GMT) Received: from hotmail.com (bay11-dav50.bay11.hotmail.com [64.4.39.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B41E43D48 for ; Sun, 5 Sep 2004 13:26:51 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Sep 2004 06:26:51 -0700 Received: from 222.64.53.190 by bay11-dav50.bay11.hotmail.com with DAV; Sun, 05 Sep 2004 13:26:51 +0000 X-Originating-IP: [222.64.53.190] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com Date: Sun, 05 Sep 2004 21:26:30 +0800 From: Deng XueFeng To: Ian Dowse In-Reply-To: <200409041653.aa45226@salmon.maths.tcd.ie> References: <20040904230250.60A0.DSNOFE@msn.com> <200409041653.aa45226@salmon.maths.tcd.ie> Message-Id: <20040905211722.30F1.DSNOFE@msn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [CN] X-OriginalArrivalTime: 05 Sep 2004 13:26:51.0350 (UTC) FILETIME=[00CDC760:01C4934C] cc: current@freebsd.org Subject: Re: 6-current's BTX loader auto reboot after make world. 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, 05 Sep 2004 13:26:51 -0000 I tried. but even I use: # env TZ=GMT cvs update -D'2004/06/28 14:00:00 (old than my lat build world) the loader continue autoreboot. any idea? PS: how to debug loader? > In message <20040904230250.60A0.DSNOFE@msn.com>, Deng XueFeng writes: > >i use: > > > >0:ad(0,a)/boot/loader.old > > > >to enter system, then: > ># mv loader.old loader. > > > >reboot, all is ok. > >My last build world is 2004-08-02. > >Is there any change to loader during there days? > > The amd64 module support and a few other changes went in during > that timeframe. If possible, could you try to track down which > changes are to blame? This will involve using cvs or cvsup to update > the boot code to a few different versions and test if you get a > working loader. > > First make sure you have a working copy of the loader (e.g. copy > to /boot/loader.good and test that it works). > > To test each case, you'll first need to update your boot code sources > to a particular date. With CVS, you'd use > > cd /usr/src/sys/boot > env TZ=GMT cvs update -D'2004/08/28 14:00:00' (for example) > > With cvsup you can add a 'date=2004.08.28.14.00.00' for example to > your supfile and `cvsup ... -i src/sys/boot supfile'. To build and > install the loader you'll need to do something like: > > cd /usr/src/sys/boot > make clean > make > make install > > Some dates that are worth checking are: > 2004/08/28 14:00:00 GMT (before amd64 loader work started) > 2004/08/28 17:00:00 GMT (after addition of helper functions) > 2004/08/29 00:00:00 GMT (after relocation changes) > 2004/08/29 02:00:00 GMT (all amd64 loader changes complete) > > It would be great if you could narrow down when the problem was > introduced this way, as it may be hard to find otherwise. > > Ian > _______________________________________________ > 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" Sincerely, Deng XueFeng MSN: dsnofe@msn.com http://www.dengh.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 13:32: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 B75FF16A4CE; Sun, 5 Sep 2004 13:32:05 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5371443D1D; Sun, 5 Sep 2004 13:32:05 +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 i85DW448029101; Sun, 5 Sep 2004 09:32:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i85DW4U3015284; Sun, 5 Sep 2004 09:32:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B59EE7303F; Sun, 5 Sep 2004 09:32:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905133204.B59EE7303F@freebsd-current.sentex.ca> Date: Sun, 5 Sep 2004 09:32:04 -0400 (EDT) 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: Sun, 05 Sep 2004 13:32:05 -0000 TB --- 2004-09-05 12:22:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 12:22:06 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-05 12:22:06 - checking out the source tree TB --- 2004-09-05 12:22:06 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-05 12:22:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 12:28:18 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 12:28:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-05 12:28:18 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c: In function `auth_ReadHeader': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:447: warning: unsigned int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:451: warning: unsigned int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c: In function `auth_ReadName': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:462: warning: unsigned int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:468: warning: unsigned int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:468: warning: unsigned int format, different type arg (arg 4) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-05 13:32:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 13:32:04 - ERROR: failed to build world TB --- 2004-09-05 13:32:04 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 13:37: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 1FB5516A4CE for ; Sun, 5 Sep 2004 13:37:50 +0000 (GMT) Received: from happy.kiev.ua (happy.kiev.ua [193.109.241.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4459C43D1F for ; Sun, 5 Sep 2004 13:37:49 +0000 (GMT) (envelope-from gul@happy.kiev.ua) Received: from gul by happy.kiev.ua with local (Exim 4.41) id 1C3xDF-0005xv-BT for current@freebsd.org; Sun, 05 Sep 2004 16:37:45 +0300 Date: Sun, 5 Sep 2004 16:37:45 +0300 From: Pavel Gulchouck To: current@freebsd.org Message-ID: <20040905133744.GZ3280@happy.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux X-FTN-Address: 2:463/68 X-Flames-To: /dev/null X-GC: GCC d- s+: a33 C+++ UL++++ UB++++ P+ L++ E--- W++ N++ o-- K- w--- O++ X-GC: M? V- PS PE+ Y+ PGP+ t? 5? X? R? !tv b+ DI? D? G e h--- r+++ y+++ User-Agent: Mutt/1.5.6i Subject: fstat segfault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gul@gul.kiev.ua List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 13:37:50 -0000 Hello. I've found messages like kernel: pid 92857 (fstat), uid 1016: exited on signal 11 on my syslog. On this machine fstat runs every 5 minutes by mrtg. Simple test gives this result: root@new-puma:~>while fstat >/dev/null; do echo -n '#'; done ############################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################Segmentation fault It gets segfault on SMP systems, 5.3-BETA2 and 5.2.1-RELEASE-p9 and works correctly on single-cpu systems, but I'm not sure it's a common rule. Here's gdb output: Program received signal SIGSEGV, Segmentation fault. 0x281453fd in bcopy () from /lib/libc.so.5 (gdb) bt #0 0x281453fd in bcopy () from /lib/libc.so.5 #1 0x08049488 in dofiles (kp=0x8051ca8) at /usr/src/usr.bin/fstat/fstat.c:372 #2 0x08049228 in fstat_kvm (what=0, arg=0) at /usr/src/usr.bin/fstat/fstat.c:278 #3 0x08049264 in fstat_sysctl (what=0, arg=0) at /usr/src/usr.bin/fstat/fstat.c:289 #4 0x08048f83 in main (argc=1, argv=0xbfbfeb1c) at /usr/src/usr.bin/fstat/fstat.c:229 Any ideas? -- Lucky carrier, Pavel. From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 14:03: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 B35E116A4CE for ; Sun, 5 Sep 2004 14:03:47 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6636643D3F for ; Sun, 5 Sep 2004 14:03:47 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i85E3kjf000727; Sun, 5 Sep 2004 10:03:46 -0400 (EDT) Date: Sun, 5 Sep 2004 10:03:46 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jeremy Chadwick In-Reply-To: <20040905131608.GA93905@parodius.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: current@freebsd.org Subject: Re: mysql on recent RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 14:03:47 -0000 On Sun, 5 Sep 2004, Jeremy Chadwick wrote: > I agree, opening another bug report on this probably wouldn't do much. > However, the only places I've seen it mentioned are here on -current. > > ports/70889 is also for the alpha architecture, which may (possibly?) be > seeing a different error message depending upon what sort-of code is > being generated. > > I don't "mind" having to use CPUTYPE as a workaround (I'm glad there's > one at all!); I'm mainly worried that the MySQL folks will begin claiming > that "FreeBSD isn't suited for MySQL" because of this problem, or > something along those lines. There's enough public misnomers as-is > about MySQL on FreeBSD (even a few on the official MySQL site). > > I'm more than happy to test patches or give someone access to our 5.x > SQL box if they want to try and track this down. I seem to recall someone mentioning that this was a compiler bug that was fixed (worked around) in mysql (CVS?) sources. It might have been posted over on threads@, but I can't recall. -- Dan From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 14:37: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 5BA6616A4CE for ; Sun, 5 Sep 2004 14:37:11 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F23AA43D49 for ; Sun, 5 Sep 2004 14:37:10 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i85EYNxk005750; Sun, 5 Sep 2004 10:34:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i85EYNTi005747; Sun, 5 Sep 2004 10:34:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 5 Sep 2004 10:34:22 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxim Maximov In-Reply-To: <413AC8F1.9020601@mcsi.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: [PATCH] poll() hang with X apps 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, 05 Sep 2004 14:37:11 -0000 On Sun, 5 Sep 2004, Maxim Maximov wrote: > > Yeah, I had a good idea about what the problem might be, but I couldn't > > reproduce it here. Happily, Doug could and was willing to spend a lot of > > time with the debugger to track stuff down. Turns out it may have been a > > potential race I tagged when I was originally reviewing that element of > > socket locking, but hadn't yet had a chance to revisit. If the patch > > fixes it, wonderful! If not, there are one or two other things in the > > polling/select code that could use review. Assuming this patch does fix > > the problem for you (it did for Doug), I'll get it merged into HEAD > > tomorrow, and RELENG_5 a few days later. > > > > Thanks for your bug report, and we'll see how it goes :-). > > It goes very well. Easily reproducible xscreensaver hacks hangs > described by Doug are gone for me too. I believe the patch also solves > my dockapp problems. I haven't seen any wmdockapps hangs yet, but they > are harder to reproduce, so only time will tell. > > I guess this patch should be merged anyway. At least for xscreensaver > related hangs :) Wonderful. I've merged this to HEAD and put it on the RELENG_5 MFC path to merge in a couple of days. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 14:55: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 E611316A4CE for ; Sun, 5 Sep 2004 14:55:01 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C6F143D1D for ; Sun, 5 Sep 2004 14:55:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.200] ([192.168.0.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i85Esmpt094826; Sun, 5 Sep 2004 08:54:49 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <413B2807.1060808@samsco.org> Date: Sun, 05 Sep 2004 08:51:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oliver Brandmueller References: <20040903013424.GA57576@e-Gitt.NET> In-Reply-To: <20040903013424.GA57576@e-Gitt.NET> 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: mysql on recent RELENG_5 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, 05 Sep 2004 14:55:02 -0000 Oliver Brandmueller wrote: > Hi, > > I see a little problem with either mysql-server 3.23 or 4.1.3 on a > RELENG_5 as of about 12 hours ago: > > mysql runs fine so far, but as soon as I do not connect by socket, but > by network on localhost (127.0.0.1) the mysqld dies by sig11 (and is the > restarted automatically by the wrapper). > > I tried ULE and 4BSD, I tried a mysql 3.23 from package. I tried > compiling 3.23 and 4.1.3 (did not try 4.1.4 which just arrived at the > ports a few hours ago) "just plain", with BUILD_OPTIMIZED, with > WITH_LINUXTHREADS defined and saw now difference. I also changed > libpthread to libc_r by libmap.conf and had no difference. > I've built MySQL 4.0 server & client from /usr/ports several dozen times over the past month with many different options and I've never had a problem and have never had to set CPUFLAGS in make.conf. This is on a Pentium-4 system. Mabye I'm missing something here? Scott From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 14:56: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 1649116A4CE; Sun, 5 Sep 2004 14:56:39 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE1D843D2D; Sun, 5 Sep 2004 14:56:38 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i85Erqlh005961; Sun, 5 Sep 2004 10:53:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i85Erprd005958; Sun, 5 Sep 2004 10:53:51 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 5 Sep 2004 10:53:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Maxim Maximov In-Reply-To: <413AD651.2030504@mcsi.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: dwhite@freebsd.org cc: current@freebsd.org Subject: Re: KQUEUE/TTY related 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: Sun, 05 Sep 2004 14:56:39 -0000 On Sun, 5 Sep 2004, Maxim Maximov wrote: > Just got a panic when dropped into DDB by Ctrl-Alt-Esc, issued > 'show witness', pressed ScrLk, pressed PgUp ten times, then PgDn. Then > released cursor by pressing ScrLk again. This is pretty much identical to the panic Jan Srzednicki reported, wherein the syscons code under DDB calls into the TTY code (and really shouldn't). The low level polled console I/O routines are not supposed to mess with schedulers, etc, etc. CC'ing Doug White since he expressed some interest in all this :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > db> panic: blockable sleep lock (sleep mutex) tty @ > /usr/src/sys/kern/kern_event.c:1450 > cpuid = 0 > boot() called on cpu#0 > Uptime: 2m22s > > Machine freezes completely here. Keys didn't work. Reset helped. > Tried exactly the same actions after reboot - exactly same effect. > Machine is SMP, HTT, WITNESS enabled, today's HEAD. > Dmesg is at http://mcsi.pp.ru/dmesg.boot > > -- > Maxim Maximov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 15:18: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 A02C816A4CE for ; Sun, 5 Sep 2004 15:18:18 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id E37C243D48 for ; Sun, 5 Sep 2004 15:18:17 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C3ymU-000E33-C8; Sun, 05 Sep 2004 17:18:14 +0200 Date: Sun, 5 Sep 2004 17:18:14 +0200 From: Oliver Brandmueller To: Scott Long Message-ID: <20040905151813.GE38513@e-Gitt.NET> References: <20040903013424.GA57576@e-Gitt.NET> <413B2807.1060808@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413B2807.1060808@samsco.org> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller cc: current@freebsd.org Subject: Re: mysql on recent RELENG_5 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, 05 Sep 2004 15:18:18 -0000 Hi Scott. On Sun, Sep 05, 2004 at 08:51:51AM -0600, Scott Long wrote: > I've built MySQL 4.0 server & client from /usr/ports several dozen times > over the past month with many different options and I've never had a > problem and have never had to set CPUFLAGS in make.conf. This is on a > Pentium-4 system. Mabye I'm missing something here? Building and running the mysqld works just fine, you can connect with no problems through the socket. But did you also try to connect through the network, something like: mysql -h 127.0.0.1 -u root -p ? This crashes mysqld (which is then restarted by the wrapper). You get an error logging in and in the log of MySQL you find something about sig11. - 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 Sun Sep 5 16:39: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 277AF16A4CE; Sun, 5 Sep 2004 16:39:57 +0000 (GMT) Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58FAD43D2D; Sun, 5 Sep 2004 16:39:55 +0000 (GMT) (envelope-from cbuisson@nerim.net) Received: from nerim.net (cbuisson.net1.nerim.net [213.41.135.238]) by kraid.nerim.net (Postfix) with ESMTP id 10FBC4192F; Sun, 5 Sep 2004 18:39:50 +0200 (CEST) Message-ID: <413B4156.6010603@nerim.net> Date: Sun, 05 Sep 2004 18:39:50 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040517 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41374767.4090809@nerim.net> In-Reply-To: <41374767.4090809@nerim.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: sos@freebsd.org Subject: Follow-up: 5.3-BETA2 do not boot (ata related) 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, 05 Sep 2004 16:39:57 -0000 Claude Buisson wrote: > I have problems running recent 5.X on a Compaq Armada 3500 (no ACPI). > > I used to get (same with 4.X): > > ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > > for the cdrom, and the boot succeeded - see dmesg.20040723v > > After a RELENG_5 cvsup on Aug 28, the message became: > > ata1-slave: FAILURE - ATAPI_IDENTIFY status=1 > error=1 LBA=0 > > and the boot stopped here. > > I tried updating sys/dev/ata to -current, i.e. with: > > ata-all.c 1.224 > ata-all.h 1.82 > ata-chipset.c 1.84 > ata-disk.c 1.177 > ata-dma.c 1.130 > ata-lowlevel.c 1.46 > ata-pci.c 1.88 > ata-queue.c 1.34 > atapi-cd.c 1.171 > > without any progress - see dmesg.curata (hand copied) > > I reverted to the (approximatively) Aug 12 state, i.e. with: > > ata-all.c 1.221 > ata-all.h 1.80 > ata-chipset.c 1.79 > ata-disk.c 1.175 > ata-dma.c 1.128 > ata-lowlevel.c 1.43 > ata-pci.c 1.87 > ata-queue.c 1.31 > > to get a runnable system - see dmesg.20040831v > > Note that the: > ATAPI_RESET time = 2910us > is only 210us with a non verbose boot. > > The cdrom seems to be of the evil kind which is both master and slave, > with no visible/accessible switch/jumper. > > Any hope ? > > Claude Buisson > > > ------------------------------------------------------------------------ > > 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.2-CURRENT-20040710 #0: Fri Jul 16 22:23:07 CEST 2004 > root@armada.home.tbf:/home/obj/home/src/sys/ARMADA5X > Preloaded elf kernel "/boot/kernel/kernel" at 0xc070b000. > Preloaded elf module "/boot/kernel/if_xe.ko" at 0xc070b1a4. > Preloaded elf module "/boot/kernel/snd_ess.ko" at 0xc070b250. > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc070b2fc. > Preloaded elf module "/boot/kernel/snd_sbc.ko" at 0xc070b3a8. > Preloaded elf module "/boot/kernel/ums.ko" at 0xc070b454. > Preloaded elf module "/boot/kernel/apm.ko" at 0xc070b4fc. > Preloaded elf module "/boot/kernel/intpm.ko" at 0xc070b5a4. > Preloaded elf module "/boot/kernel/smbus.ko" at 0xc070b650. > Calibrating clock(s) ... i8254 clock: 1193213 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 300012655 Hz > CPU: Pentium II/Pentium II Xeon/Celeron (300.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x652 Stepping = 2 > Features=0x183f9ff > real memory = 201293824 (191 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000826000 - 0x000000000bc67fff, 189014016 bytes (46146 pages) > avail memory = 191614976 (182 MB) > bios32: Found BIOS32 Service Directory header at 0xc00fa000 > bios32: Entry = 0xf0000 (c00f0000) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0x484 > pnpbios: Found PnP BIOS data at 0xc00fe2d0 > pnpbios: Entry = f0000:4d37 Rev = 1.0 > pnpbios: Event flag at fe2f6 > pnpbios: OEM ID 5eb0110e > Other BIOS signatures found: > null: > random: > mem: > Pentium Pro MTRR support enabled > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71928086) > pcibios: BIOS version 2.10 > apm0: on motherboard > apm0: found APM BIOS v1.2, connected at v1.2 > pcib0: at pcibus 0 on motherboard > pci0: on pcib0 > pci0: physical bus=0 > map[10]: type 3, range 32, base 50000000, size 28, enabled > found-> vendor=0x8086, dev=0x7192, revid=0x02 > bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x7110, revid=0x02 > bus=0, slot=7, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type 4, range 32, base 00001020, size 4, enabled > found-> vendor=0x8086, dev=0x7111, revid=0x01 > bus=0, slot=7, func=1 > class=01-01-80, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type 4, range 32, base 00001000, size 5, enabled > found-> vendor=0x8086, dev=0x7112, revid=0x01 > bus=0, slot=7, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=11 > map[90]: type 4, range 32, base 00000d00, size 4, enabled > found-> vendor=0x8086, dev=0x7113, revid=0x02 > bus=0, slot=7, func=3 > class=06-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 1, range 32, base 40000000, size 24, enabled > found-> vendor=0x102c, dev=0x00c0, revid=0x64 > bus=0, slot=8, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0083, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > map[10]: type 1, range 32, base 7fffe000, size 12, enabled > found-> vendor=0x104c, dev=0xac17, revid=0x02 > bus=0, slot=17, func=0 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) > lattimer=0x42 (1980 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) > intpin=a, irq=11 > powerspec 1 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base 7ffff000, size 12, enabled > found-> vendor=0x104c, dev=0xac17, revid=0x02 > bus=0, slot=17, func=1 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) > lattimer=0x42 (1980 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) > intpin=a, irq=11 > powerspec 1 supports D0 D1 D2 D3 current D0 > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port 0x1020-0x102f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1020 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ata0: at 0x1f0 irq 14 on atapci0 > ata0: [MPSAFE] > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=03 ostat0=51 ostat1=01 > ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0xc > ata1: at 0x170 irq 15 on atapci0 > ata1: [MPSAFE] > uhci0: port 0x1000-0x101f irq 11 at device 7.2 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1000 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > intpm0: port 0xd00-0xd0f irq 9 at device 7.3 on pci0 > intpm0: Reserved 0x10 bytes for rid 0x90 type 4 at 0xd00 > intpm0: I/O mapped d00 > intpm0: intr IRQ 9 enabled revision 0 > intpm0: [GIANT-LOCKED] > intsmb0: on intpm0 > smbus0: on intsmb0 > intpm0: PM I/O mapped f00 > pci0: at device 8.0 (no driver attached) > cbb0: mem 0x7fffe000-0x7fffefff irq 11 at device 17.0 on pci0 > cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x7fffe000 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [MPSAFE] > cbb0: PCI Configuration space: > 0x00: 0xac17104c 0x02100007 0x06070002 0x00824208 > 0x10: 0x7fffe000 0x020000a0 0x20010100 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b > 0x40: 0xb0470e11 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x28049060 0x00000000 0x00000000 0x01001c72 > 0x90: 0x61648280 0x00000000 0x00000000 0x00000000 > 0xa0: 0x7e210001 0x00800000 0x00000000 0x00000007 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > cbb1: mem 0x7ffff000-0x7fffffff irq 11 at device 17.1 on pci0 > cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x7ffff000 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [MPSAFE] > cbb1: PCI Configuration space: > 0x00: 0xac17104c 0x02100007 0x06070002 0x00824208 > 0x10: 0x7ffff000 0x020000a0 0x20020200 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b > 0x40: 0xb0470e11 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x28049060 0x00000000 0x00000000 0x01001c72 > 0x90: 0x61648280 0x00000000 0x00000000 0x00000000 > 0xa0: 0x7e210001 0x00800000 0x00000000 0x00000007 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > cpu0 on motherboard > ata: ata0 already exists; skipping it > ata: ata1 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 > pnpbios: 18 devices, largest 250 bytes > PNP0401: adding irq mask 0x80 > PNP0401: adding dma mask 0x1 > PNP0401: adding io range 0x378-0x37f, size=0x8, align=0 > PNP0401: adding io range 0x778-0x77a, size=0x3, align=0 > pnpbios: handle 1 device ID PNP0401 (0104d041) > PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 > PNP0501: adding irq mask 0x10 > pnpbios: handle 2 device ID PNP0501 (0105d041) > pnpbios: handle 3 device ID PNP0511 (1105d041) > PNP0700: adding irq mask 0x40 > PNP0700: adding dma mask 0x4 > PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0 > pnpbios: handle 4 device ID PNP0700 (0007d041) > ESS0006: adding io range 0x250-0x257, size=0x8, align=0 > pnpbios: handle 5 device ID ESS0006 (06007316) > CPQb0ac: adding io range 0x220-0x22f, size=0x10, align=0 > CPQb0ac: adding io range 0x388-0x38b, size=0x4, align=0 > CPQb0ac: adding io range 0x330-0x331, size=0x2, align=0 > CPQb0ac: adding irq mask 0x20 > CPQb0ac: adding dma mask 0x2 > CPQb0ac: adding dma mask 0x20 > pnpbios: handle 6 device ID CPQb0ac (acb0110e) > PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 > PNP0c01: adding fixed memory32 range 0xf0000-0xfffff, size=0x10000 > PNP0c01: adding fixed memory32 range 0x100000-0xbffffff, size=0xbf00000 > pnpbios: handle 7 device ID PNP0c01 (010cd041) > PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 > PNP0c04: adding irq mask 0x2000 > pnpbios: handle 8 device ID PNP0c04 (040cd041) > PNP0100: adding io range 0x40-0x43, size=0x4, align=0 > PNP0100: adding irq mask 0x1 > pnpbios: handle 10 device ID PNP0100 (0001d041) > PNP0200: adding io range 0-0xf, size=0x10, align=0 > PNP0200: adding io range 0x80-0x8f, size=0x10, align=0 > PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 > PNP0200: adding dma mask 0x10 > pnpbios: handle 11 device ID PNP0200 (0002d041) > PNP0800: adding io range 0x61-0x61, size=0x1, align=0 > pnpbios: handle 12 device ID PNP0800 (0008d041) > PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 > PNP0b00: adding io range 0x72-0x73, size=0x2, align=0 > PNP0b00: adding irq mask 0x100 > pnpbios: handle 13 device ID PNP0b00 (000bd041) > PNP0303: adding io range 0x60-0x60, size=0x1, align=0 > PNP0303: adding io range 0x64-0x64, size=0x1, align=0 > PNP0303: adding irq mask 0x2 > pnpbios: handle 14 device ID PNP0303 (0303d041) > PNP0f13: adding irq mask 0x1000 > pnpbios: handle 15 device ID PNP0f13 (130fd041) > PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 > pnpbios: handle 16 device ID PNP0a03 (030ad041) > PNP0c02: adding fixed memory32 range 0xfffc0000-0xffffffff, size=0x40000 > PNP0c02: adding fixed memory32 range 0xcb000-0xcbfff, size=0x1000 > PNP0c02: adding io range 0x22-0x3f, size=0x1e, align=0 > PNP0c02: adding io range 0x44-0x5f, size=0x1c, align=0 > PNP0c02: adding io range 0x62-0x63, size=0x2, align=0 > PNP0c02: adding io range 0x65-0x6f, size=0xb, align=0 > PNP0c02: adding io range 0x74-0x74, size=0x1, align=0 > PNP0c02: adding io range 0x75-0x75, size=0x1, align=0 > PNP0c02: adding io range 0x76-0x76, size=0x1, align=0 > PNP0c02: adding io range 0x77-0x77, size=0x1, align=0 > PNP0c02: adding io range 0x90-0x91, size=0x2, align=0 > PNP0c02: adding io range 0x92-0x92, size=0x1, align=0 > PNP0c02: adding io range 0x93-0x9f, size=0xd, align=0 > PNP0c02: adding io range 0xa2-0xbf, size=0x1e, align=0 > PNP0c02: adding io range 0xe0-0xe1, size=0x2, align=0 > PNP0c02: adding io range 0xe2-0xe3, size=0x2, align=0 > PNP0c02: adding io range 0x100-0x107, size=0x8, align=0 > PNP0c02: adding io range 0x260-0x263, size=0x4, align=0 > PNP0c02: adding io range 0x4d0-0x4d1, size=0x2, align=0 > PNP0c02: adding io range 0xf00-0xf3f, size=0x40, align=0 > PNP0c02: adding io range 0xd00-0xd0f, size=0x10, align=0 > pnpbios: handle 18 device ID PNP0c02 (020cd041) > PNP0e03: adding io range 0x3e0-0x3e1, size=0x2, align=0 > pnpbios: handle 19 device ID PNP0e03 (030ed041) > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xc0000-0xcafff on isa0 > pmtimer0 on isa0 > atkbdc0: at port 0x64,0x60 on isa0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > atkbd0: [GIANT-LOCKED] > psm0: current command byte:0065 > psm0: flags 0xc000 irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons > psm0: config:0000c000, flags:00000000, packet size:4 > psm0: syncmask:08, syncbits:08 > fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: parallel port found at 0x378 > ppc0: using extended I/O port range > ppc0: EPP SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > fb: new array size 4 > sc0: at flags 0x100 on isa0 > sc0: VGA <12 virtual consoles, flags=0x300> > sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) > sio0: irq maps: 0x1 0x11 0x1 0x1 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > fb0: vga0, vga, type:VGA (5), flags:0x7007f > fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 > fb0: init mode:24, bios mode:3, current mode:24 > fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k > VGA parameters upon power-up > 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > VGA parameters in BIOS for mode 24 > 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > EGA/VGA parameters to be used for mode 24 > 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > isa_probe_children: probing PnP devices > unknown: can't assign resources (port) > unknown: at port 0x378-0x37f on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f8-0x3ff on isa0 > unknown: failed to probe on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f0-0x3f5 on isa0 > sbc0: at port 0x330-0x331,0x388-0x38b,0x220-0x22f irq 5 drq 5,1 on isa0 > sbc0: [GIANT-LOCKED] > pcm0: on sbc0 > pcm0: ESS1869 detected, newspeed > pcm0: [GIANT-LOCKED] > pcm0: sndbuf_setmap 1de000, 1000; 0xc987d000 -> 1de000 > pcm0: sndbuf_setmap 1e5000, 1000; 0xc987e000 -> 1e5000 > unknown: failed to probe at port 0x61 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x60 on isa0 > unknown: can't assign resources (irq) > unknown: at irq 12 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x4d0-0x4d1,0x260-0x263,0x100-0x107,0xe2-0xe3,0xe0-0xe1,0xa2-0xbf,0x93-0x9f,0x92,0x90-0x91,0x77,0x76,0x75,0x74,0x65-0x6f,0x62-0x63,0x44-0x5f,0x22-0x3f iomem 0xcb000-0xcbfff,0xfffc0000-0xffffffff on isa0 > unknown: failed to probe at port 0x3e0-0x3e1 on isa0 > Device configuration finished. > TSC timecounter disabled: APM enabled. > Timecounter "TSC" frequency 300012655 Hz quality -1000 > Timecounters tick every 10.000 msec > lo0: bpf attached > ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin > ata0-master: setting PIO4 on Intel PIIX4 chip > ata0-master: setting UDMA33 on Intel PIIX4 chip > ad0: ATA-4 disk at ata0-master > ad0: 6194MB (12685680 sectors), 13424 C, 15 H, 63 S, 512 B > ad0: 16 secs/int, 1 depth queue, UDMA33 > GEOM: new disk ad0 > [0] f:80 typ:11 s(CHS):1/0/1 e(CHS):278/239/63 s:15120 l:4203360 > [1] f:00 typ:18 s(CHS):0/1/1 e(CHS):0/239/63 s:63 l:15057 > [2] f:00 typ:165 s(CHS):279/0/1 e(CHS):838/239/63 s:4218480 l:8467200 > [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 > GEOM: Configure ad0s1, start 7741440 length 2152120320 end 2159861759 > GEOM: Configure ad0s2, start 32256 length 7709184 end 7741439 > GEOM: Configure ad0s3, start 2159861760 length 4335206400 end 6495068159 > GEOM: Configure ad0s3a, start 0 length 134217728 end 134217727 > GEOM: Configure ad0s3b, start 134217728 length 536870912 end 671088639 > GEOM: Configure ad0s3c, start 0 length 4335206400 end 4335206399 > GEOM: Configure ad0s3d, start 671088640 length 872415232 end 1543503871 > GEOM: Configure ad0s3e, start 1543503872 length 134217728 end 1677721599 > GEOM: Configure ad0s3f, start 1677721600 length 2657484800 end 4335206399 > ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin > ata1-master: setting PIO4 on Intel PIIX4 chip > acd0: CDROM drive at ata1 as master > acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 > acd0: Reads: CDR, CDRW, CDDA > acd0: Writes: > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > Mounting root from ufs:/dev/ad0s3a > start_init: trying /sbin/init > > > ------------------------------------------------------------------------ > > Hand copied dmesg of latest kernel boot (with updated sys/dev/ata/) > > atapci0: port 0x1020-0x102f,0x376,0x170-0x177, > 0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > atapci0: Reseved 0x10 bytes for rid 0x20 type 4 at 0x1020 > ata0: channel #0 on atapci0 > atapci0: Reseved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reseved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask 03 ostat0=50 ostat1=00 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ata0: [MPSAFE] > ata1: channel #1 on atapci0 > atapci0: Reseved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reseved 0x1 bytes for rid 0x1c type 4 at 0x3f6 > ata1: reset tp1 mask 03 ostat0=51 ostat1=01 > ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0xc > ata1: [MPSAFE] > > ... > > ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin > ata0-master: setting PIO4 on Intel PIIX4 chip > ata0-master: setting UDMA33 on Intel PIIX4 chip > ad0: ATA-4 disk at ata0-master > ad0: 6194MB (12685680 sectors), 13424 C, 15 H, 63 S, 512 B > ad0: 16 secs/int, 1 depth queue, UDMA33 > GEOM: new disk ad0 > > ... > > ata1: reiniting channel .. > ata1: reset tp1 mask 03 ostat0=00 ostat1=01 > ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0xc > ata1: resetting done .. > ata1-slave: FAILURE - ATAPI_IDENTIFY status=1 error=1 > LBA=0 > > > ------------------------------------------------------------------------ > > 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-BETA2 #0: Tue Aug 31 14:58:45 CEST 2004 > toor@adele.home.tbf:/home/obj/home/src/sys/ARMADA5X > Preloaded elf kernel "/boot/kernel/kernel" at 0xc072a000. > Preloaded elf module "/boot/kernel/vesa.ko" at 0xc072a1a4. > Preloaded elf module "/boot/kernel/if_xe.ko" at 0xc072a250. > Preloaded elf module "/boot/kernel/snd_ess.ko" at 0xc072a2fc. > Preloaded elf module "/boot/kernel/sound.ko" at 0xc072a3a8. > Preloaded elf module "/boot/kernel/snd_sbc.ko" at 0xc072a454. > Preloaded elf module "/boot/kernel/ums.ko" at 0xc072a500. > Preloaded elf module "/boot/kernel/apm.ko" at 0xc072a5a8. > Preloaded elf module "/boot/kernel/intpm.ko" at 0xc072a650. > Preloaded elf module "/boot/kernel/smbus.ko" at 0xc072a6fc. > Calibrating clock(s) ... i8254 clock: 1193239 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 300011828 Hz > CPU: Pentium II/Pentium II Xeon/Celeron (300.01-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x652 Stepping = 2 > Features=0x183f9ff > real memory = 201326592 (192 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000826000 - 0x000000000bc6ffff, 189046784 bytes (46154 pages) > avail memory = 191655936 (182 MB) > bios32: Found BIOS32 Service Directory header at 0xc00fa000 > bios32: Entry = 0xf0000 (c00f0000) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0x484 > pnpbios: Found PnP BIOS data at 0xc00fe2d0 > pnpbios: Entry = f0000:4d37 Rev = 1.0 > pnpbios: Event flag at fe2f6 > pnpbios: OEM ID 5eb0110e > Other BIOS signatures found: > mem: > Pentium Pro MTRR support enabled > null: > random: > io: > VESA: information block > 56 45 53 41 00 02 00 01 00 01 01 00 00 00 40 00 > 00 01 20 00 00 01 16 01 00 01 31 01 00 01 4a 01 > 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > VESA: 16 mode(s) found > VESA: v2.0, 2048k memory, flags:0x1, mode table:0xc06e18c0 (1000040) > VESA: CHIPS 69000 Super VGA > VESA: Chips & Technologies, Inc. 69000 Display Controller 2 > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71928086) > pcibios: BIOS version 2.10 > apm0: on motherboard > apm0: found APM BIOS v1.2, connected at v1.2 > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > pci0: physical bus=0 > map[10]: type 3, range 32, base 50000000, size 28, enabled > found-> vendor=0x8086, dev=0x7192, revid=0x02 > bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x7110, revid=0x02 > bus=0, slot=7, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type 4, range 32, base 00001020, size 4, enabled > found-> vendor=0x8086, dev=0x7111, revid=0x01 > bus=0, slot=7, func=1 > class=01-01-80, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type 4, range 32, base 00001000, size 5, enabled > found-> vendor=0x8086, dev=0x7112, revid=0x01 > bus=0, slot=7, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=11 > map[90]: type 4, range 32, base 00000d00, size 4, enabled > found-> vendor=0x8086, dev=0x7113, revid=0x02 > bus=0, slot=7, func=3 > class=06-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 1, range 32, base 40000000, size 24, enabled > found-> vendor=0x102c, dev=0x00c0, revid=0x64 > bus=0, slot=8, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0083, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > map[10]: type 1, range 32, base 7fffe000, size 12, enabled > found-> vendor=0x104c, dev=0xac17, revid=0x02 > bus=0, slot=17, func=0 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) > lattimer=0x42 (1980 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) > intpin=a, irq=11 > powerspec 1 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base 7ffff000, size 12, enabled > found-> vendor=0x104c, dev=0xac17, revid=0x02 > bus=0, slot=17, func=1 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) > lattimer=0x42 (1980 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) > intpin=a, irq=11 > powerspec 1 supports D0 D1 D2 D3 current D0 > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port 0x1020-0x102f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1020 > ata0: channel #0 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ata0: [MPSAFE] > ata1: channel #1 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=03 ostat0=51 ostat1=01 > ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0xc > ata1: [MPSAFE] > uhci0: port 0x1000-0x101f irq 11 at device 7.2 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1000 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 > ums0: 3 buttons and Z dir. > intpm0: port 0xd00-0xd0f irq 9 at device 7.3 on pci0 > intpm0: Reserved 0x10 bytes for rid 0x90 type 4 at 0xd00 > intpm0: I/O mapped d00 > intpm0: intr IRQ 9 enabled revision 0 > intpm0: [GIANT-LOCKED] > intsmb0: on intpm0 > smbus0: on intsmb0 > intpm0: PM I/O mapped f00 > pci0: at device 8.0 (no driver attached) > cbb0: mem 0x7fffe000-0x7fffefff irq 11 at device 17.0 on pci0 > cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x7fffe000 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [MPSAFE] > cbb0: PCI Configuration space: > 0x00: 0xac17104c 0x02100007 0x06070002 0x00824208 > 0x10: 0x7fffe000 0x020000a0 0x20010100 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b > 0x40: 0xb0470e11 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x28049060 0x00000000 0x00000000 0x01001c72 > 0x90: 0x61648280 0x00000000 0x00000000 0x00000000 > 0xa0: 0x7e210001 0x00800000 0x00000801 0x00000007 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > cbb1: mem 0x7ffff000-0x7fffffff irq 11 at device 17.1 on pci0 > cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x7ffff000 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [MPSAFE] > cbb1: PCI Configuration space: > 0x00: 0xac17104c 0x02100007 0x06070002 0x00824208 > 0x10: 0x7ffff000 0x020000a0 0x20020200 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b > 0x40: 0xb0470e11 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x2804b060 0x00000000 0x00000000 0x01001c72 > 0x90: 0x61648280 0x00000000 0x00000000 0x00000000 > 0xa0: 0x7e210001 0x00800000 0x00000801 0x00000007 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > cpu0 on motherboard > ata: ata0 already exists; skipping it > ata: ata1 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 > pnpbios: 18 devices, largest 250 bytes > PNP0401: adding irq mask 0x80 > PNP0401: adding dma mask 0x8 > PNP0401: adding io range 0x378-0x37f, size=0x8, align=0 > PNP0401: adding io range 0x778-0x77a, size=0x3, align=0 > pnpbios: handle 1 device ID PNP0401 (0104d041) > PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 > PNP0501: adding irq mask 0x10 > pnpbios: handle 2 device ID PNP0501 (0105d041) > pnpbios: handle 3 device ID PNP0511 (1105d041) > PNP0700: adding irq mask 0x40 > PNP0700: adding dma mask 0x4 > PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0 > pnpbios: handle 4 device ID PNP0700 (0007d041) > ESS0006: adding io range 0x250-0x257, size=0x8, align=0 > pnpbios: handle 5 device ID ESS0006 (06007316) > CPQb0ac: adding io range 0x220-0x22f, size=0x10, align=0 > CPQb0ac: adding io range 0x388-0x38b, size=0x4, align=0 > CPQb0ac: adding io range 0x330-0x331, size=0x2, align=0 > CPQb0ac: adding irq mask 0x20 > CPQb0ac: adding dma mask 0x2 > CPQb0ac: adding dma mask 0x20 > pnpbios: handle 6 device ID CPQb0ac (acb0110e) > PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 > PNP0c01: adding fixed memory32 range 0xf0000-0xfffff, size=0x10000 > PNP0c01: adding fixed memory32 range 0x100000-0xbffffff, size=0xbf00000 > pnpbios: handle 7 device ID PNP0c01 (010cd041) > PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 > PNP0c04: adding irq mask 0x2000 > pnpbios: handle 8 device ID PNP0c04 (040cd041) > PNP0100: adding io range 0x40-0x43, size=0x4, align=0 > PNP0100: adding irq mask 0x1 > pnpbios: handle 10 device ID PNP0100 (0001d041) > PNP0200: adding io range 0-0xf, size=0x10, align=0 > PNP0200: adding io range 0x80-0x8f, size=0x10, align=0 > PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 > PNP0200: adding dma mask 0x10 > pnpbios: handle 11 device ID PNP0200 (0002d041) > PNP0800: adding io range 0x61-0x61, size=0x1, align=0 > pnpbios: handle 12 device ID PNP0800 (0008d041) > PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 > PNP0b00: adding io range 0x72-0x73, size=0x2, align=0 > PNP0b00: adding irq mask 0x100 > pnpbios: handle 13 device ID PNP0b00 (000bd041) > PNP0303: adding io range 0x60-0x60, size=0x1, align=0 > PNP0303: adding io range 0x64-0x64, size=0x1, align=0 > PNP0303: adding irq mask 0x2 > pnpbios: handle 14 device ID PNP0303 (0303d041) > PNP0f13: adding irq mask 0x1000 > pnpbios: handle 15 device ID PNP0f13 (130fd041) > PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 > pnpbios: handle 16 device ID PNP0a03 (030ad041) > PNP0c02: adding fixed memory32 range 0xfffc0000-0xffffffff, size=0x40000 > PNP0c02: adding fixed memory32 range 0xcb000-0xcbfff, size=0x1000 > PNP0c02: adding io range 0x22-0x3f, size=0x1e, align=0 > PNP0c02: adding io range 0x44-0x5f, size=0x1c, align=0 > PNP0c02: adding io range 0x62-0x63, size=0x2, align=0 > PNP0c02: adding io range 0x65-0x6f, size=0xb, align=0 > PNP0c02: adding io range 0x74-0x74, size=0x1, align=0 > PNP0c02: adding io range 0x75-0x75, size=0x1, align=0 > PNP0c02: adding io range 0x76-0x76, size=0x1, align=0 > PNP0c02: adding io range 0x77-0x77, size=0x1, align=0 > PNP0c02: adding io range 0x90-0x91, size=0x2, align=0 > PNP0c02: adding io range 0x92-0x92, size=0x1, align=0 > PNP0c02: adding io range 0x93-0x9f, size=0xd, align=0 > PNP0c02: adding io range 0xa2-0xbf, size=0x1e, align=0 > PNP0c02: adding io range 0xe0-0xe1, size=0x2, align=0 > PNP0c02: adding io range 0xe2-0xe3, size=0x2, align=0 > PNP0c02: adding io range 0x100-0x107, size=0x8, align=0 > PNP0c02: adding io range 0x260-0x263, size=0x4, align=0 > PNP0c02: adding io range 0x4d0-0x4d1, size=0x2, align=0 > PNP0c02: adding io range 0xf00-0xf3f, size=0x40, align=0 > PNP0c02: adding io range 0xd00-0xd0f, size=0x10, align=0 > pnpbios: handle 18 device ID PNP0c02 (020cd041) > PNP0e03: adding io range 0x3e0-0x3e1, size=0x2, align=0 > pnpbios: handle 19 device ID PNP0e03 (030ed041) > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xc0000-0xcafff on isa0 > pmtimer0 on isa0 > atkbdc0: at port 0x64,0x60 on isa0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > atkbd0: [GIANT-LOCKED] > psm0: current command byte:0065 > psm0: flags 0xc000 irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons > psm0: config:0000c000, flags:00000008, packet size:3 > psm0: syncmask:c0, syncbits:00 > fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: parallel port found at 0x378 > ppc0: using extended I/O port range > ppc0: EPP SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > fb: new array size 4 > sc0: at flags 0x100 on isa0 > sc0: VGA <12 virtual consoles, flags=0x300> > sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) > sio0: irq maps: 0x1 0x11 0x1 0x1 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > fb0: vga0, vga, type:VGA (5), flags:0x700ff > fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 > fb0: init mode:24, bios mode:3, current mode:24 > fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k > VGA parameters upon power-up > 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > VGA parameters in BIOS for mode 24 > 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > EGA/VGA parameters to be used for mode 24 > 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > isa_probe_children: probing PnP devices > unknown: can't assign resources (port) > unknown: at port 0x378-0x37f on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f8-0x3ff on isa0 > unknown: failed to probe on isa0 > unknown: can't assign resources (port) > unknown: at port 0x3f0-0x3f5 on isa0 > sbc0: at port 0x330-0x331,0x388-0x38b,0x220-0x22f irq 5 drq 5,1 on isa0 > sbc0: [GIANT-LOCKED] > pcm0: on sbc0 > pcm0: ESS1869 detected, newspeed > pcm0: [GIANT-LOCKED] > pcm0: sndbuf_setmap ffe000, 1000; 0xc991c000 -> ffe000 > pcm0: sndbuf_setmap ffd000, 1000; 0xc991d000 -> ffd000 > unknown: failed to probe at port 0x61 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x60 on isa0 > unknown: can't assign resources (irq) > unknown: at irq 12 on isa0 > unknown: can't assign resources (port) > unknown: at port 0x4d0-0x4d1,0x260-0x263,0x100-0x107,0xe2-0xe3,0xe0-0xe1,0xa2-0xbf,0x93-0x9f,0x92,0x90-0x91,0x77,0x76,0x75,0x74,0x65-0x6f,0x62-0x63,0x44-0x5f,0x22-0x3f iomem 0xcb000-0xcbfff,0xfffc0000-0xffffffff on isa0 > unknown: failed to probe at port 0x3e0-0x3e1 on isa0 > Device configuration finished. > TSC timecounter disabled: APM enabled. > Timecounter "TSC" frequency 300011828 Hz quality -1000 > Timecounters tick every 10.000 msec > lo0: bpf attached > ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin > ata0-master: setting PIO4 on Intel PIIX4 chip > ata0-master: setting UDMA33 on Intel PIIX4 chip > ad0: ATA-4 disk at ata0-master > ad0: 6194MB (12685680 sectors), 13424 C, 15 H, 63 S, 512 B > ad0: 16 secs/int, 1 depth queue, UDMA33 > GEOM: new disk ad0 > [0] f:80 typ:11 s(CHS):1/0/1 e(CHS):278/239/63 s:15120 l:4203360 > [1] f:00 typ:18 s(CHS):0/1/1 e(CHS):0/239/63 s:63 l:15057 > [2] f:00 typ:165 s(CHS):279/0/1 e(CHS):838/239/63 s:4218480 l:8467200 > [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 > GEOM: Configure ad0s1, start 7741440 length 2152120320 end 2159861759 > GEOM: Configure ad0s2, start 32256 length 7709184 end 7741439 > GEOM: Configure ad0s3, start 2159861760 length 4335206400 end 6495068159 > GEOM: Configure ad0s3a, start 0 length 134217728 end 134217727 > GEOM: Configure ad0s3b, start 134217728 length 536870912 end 671088639 > GEOM: Configure ad0s3c, start 0 length 4335206400 end 4335206399 > GEOM: Configure ad0s3d, start 671088640 length 872415232 end 1543503871 > GEOM: Configure ad0s3e, start 1543503872 length 134217728 end 1677721599 > GEOM: Configure ad0s3f, start 1677721600 length 2657484800 end 4335206399 > pccard1: CIS version PC Card Standard 5.0 > pccard1: CIS info: Xircom, CreditCard 10/100, CE3-10/100, 1.00 > pccard1: Manufacturer code 0x105, product 0x10a > pccard1: function 0: network adapter, ccr addr 800 mask 3 > pccard1: function 0, config table entry 1: I/O card; irq mask 8ebc; iomask 4, iospace 0-f; memspace 0-fff; mwait_required rdybsy_active io8 io16 irqpulse irqlevel powerdown > xe0: at port 0x100-0x10f irq 11 function 0 config 1 on pccard1 > xe0: [GIANT-LOCKED] > xe0: Xircom CreditCard 10/100, version 0x45/0x04, 100Mbps capable > xe0: bpf attached > xe0: Ethernet address: 00:80:c7:7a:d2:73 > ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin > ATAPI_RESET time = 2910us > ata1-master: setting PIO4 on Intel PIIX4 chip > acd0: CDROM drive at ata1 as master > acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 > acd0: Reads: CDR, CDRW, CDDA > acd0: Writes: > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > Mounting root from ufs:/dev/ad0s3a > start_init: trying /sbin/init > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" After another round of tests, I am positive that this boot problem is related to: ------------------------------------------------------------------------ sos 2004-08-16 09:32:35 UTC FreeBSD src repository Modified files: sys/dev/ata ata-all.c ata-lowlevel.c ata-queue.c Log: Improve (hopefully) on the workaround code for devices that doesn't interrupt when command is done, ie some ATAPI CD drives with no media loaded. Revision Changes Path 1.222 +1 -1 src/sys/dev/ata/ata-all.c 1.44 +4 -9 src/sys/dev/ata/ata-lowlevel.c 1.32 +13 -13 src/sys/dev/ata/ata-queue.c ------------------------------------------------------------------------ I am now running 5.3-BETA3 with these 3 files reverted to the previous version. And, NO, updating sys/dev/ata/ from -current does not solve it. Claude Buisson From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 16:55: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 1556016A4CE; Sun, 5 Sep 2004 16:55:56 +0000 (GMT) Received: from web.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73DA143D41; Sun, 5 Sep 2004 16:55:52 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i85GskmE046365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Sep 2004 18:55:41 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <413B44B9.7020704@portaone.com> Date: Sun, 05 Sep 2004 19:54:17 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <6.1.0.6.1.20040816074348.03f99338@popserver.sfu.ca> <4120F823.2040802@portaone.com> In-Reply-To: <4120F823.2040802@portaone.com> Content-Type: multipart/mixed; boundary="------------080500030706020202000104" cc: freebsd-current@FreeBSD.ORG cc: freebsd-mobile@FreeBSD.ORG Subject: Re: Enhanced SpeedStep driver available 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, 05 Sep 2004 16:55:56 -0000 This is a multi-part message in MIME format. --------------080500030706020202000104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please see attached a patch which adds support to TCC speed control available in every intel p4 processor. This patch requires up-to-date current system to work properly, since I've recently addes ESS-like sysctl that can be used to obtain list of speed steps supported by TCC circuit. It would be nice to have it integrated into the estctrl. Thanks! -Maxim Maxim Sobolev wrote: > Colin Percival wrote: > >> Thanks to everyone who has been sending me data about their >> processors (and in particular, the 90nm versions), I now have >> a first draft of a Enhanced SpeedStep driver available. For >> people with the appropriate processors (Pentium M only), this >> makes it possible to adjust the cpu frequency via a new sysctl >> (hw.est_curfreq), and have the cpu voltage adjusted at the >> same time. >> I've also put together a very simple control daemon which >> reads kern.cp_time every second and adjusts the cpu frequency >> based on the fraction of cpu time which is idle. This increases >> my laptop's battery life by around 40%. > > > It would be nice if you can extend it to use whatever speed control > method is available (e.g. ACPI, TCC, ESS etc), so that it can be used on > older machines as well. > > -Maxim > > >> All the code is online at >> http://www.daemonology.net/freebsd-est/ >> Assuming I don't hear any major bug reports in the next few >> days, I'll package these into ports and hopefully get them into >> the ports tree in time for 5.3-RELEASE. >> >> Colin Percival >> >> _______________________________________________ >> 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" > > > --------------080500030706020202000104 Content-Type: text/plain; name="estctrl.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="estctrl.c.diff" --- estctrl.c 2004/08/21 15:43:59 1.1 +++ estctrl.c 2004/08/23 19:04:51 @@ -38,9 +38,21 @@ #include static int readtimes(long * idle, long * total); -static int readfreqs(int * numfreqs, int ** freqs); -static int readcurfreq(int * curfreq); -static int setcurfreq(int freq); +static int readfreqs(int cmethod, int * numfreqs, int ** freqs); +static int readcurfreq(int cmethod, int * curfreq); +static int setcurfreq(int cmethod, int freq); + +#define CMETHOD_ESS (0) +#define CMETHOD_TCC (1) + +const struct { + const char *slevels; + const char *clevel; + const char *measure; +} sctl_names[2] = { + {"hw.est_freqs", "hw.est_curfreq", "MHz"}, + {"hw.p4tcc.cpuperf_levels", "hw.p4tcc.cpuperf", "%"} +}; static int readtimes(long * idle, long * total) { @@ -67,17 +79,18 @@ return 0; } -static int readfreqs(int * numfreqs, int ** freqs) +static int readfreqs(int cmethod, int * numfreqs, int ** freqs) { char *freqstr, *p, *q; int i; size_t len = 0; - if (sysctlbyname("hw.est_freqs", NULL, &len, NULL, 0)) + if (sysctlbyname(sctl_names[cmethod].slevels, NULL, &len, NULL, 0)) return -1; if ((freqstr = malloc(len)) == NULL) return -1; - if (sysctlbyname("hw.est_freqs", (void *)freqstr, &len, NULL, 0)) + if (sysctlbyname(sctl_names[cmethod].slevels, (void *)freqstr, &len, + NULL, 0)) return -1; *numfreqs = 1; @@ -105,21 +118,23 @@ return 0; } -static int readcurfreq(int * curfreq) +static int readcurfreq(int cmethod, int * curfreq) { size_t len = sizeof(*curfreq); - if (sysctlbyname("hw.est_curfreq", curfreq, &len, NULL, 0)) + if (sysctlbyname(sctl_names[cmethod].clevel, curfreq, &len, NULL, 0)) return -1; return 0; } -static int setcurfreq(int freq) +static int setcurfreq(int cmethod, int freq) { - printf("Setting frequency to %d\n", freq); - if (sysctlbyname("hw.est_curfreq", NULL, NULL, &freq, sizeof(freq))) + printf("Setting frequency to %d%s\n", freq, + sctl_names[cmethod].measure); + if (sysctlbyname(sctl_names[cmethod].clevel, NULL, NULL, &freq, + sizeof(freq))) return -1; return 0; @@ -130,16 +145,31 @@ long idle, total; int * freqs, numfreqs; int curfreq, i; + int cmethod; if (readtimes(NULL, NULL)) err(1, "readtimes"); - if (readfreqs(&numfreqs, &freqs)) + + if (readfreqs(CMETHOD_ESS, &numfreqs, &freqs) == 0) { + cmethod = CMETHOD_ESS; + } else if (readfreqs(CMETHOD_TCC, &numfreqs, &freqs) == 0) { + cmethod = CMETHOD_TCC; + /* + * On some machines, TCC lies right after boot, + * so that set it explicitly to the current level. + */ + if (readcurfreq(cmethod, &curfreq)) + err(1, "Error reading current CPU frequency"); + if (setcurfreq(cmethod, curfreq)) + err(1, "Error setting CPU frequency"); + } else { err(1, "Error reading supported CPU frequencies"); + } do { sleep(1); - if (readcurfreq(&curfreq)) + if (readcurfreq(cmethod, &curfreq)) err(1, "Error reading current CPU frequency"); if (readtimes(&idle, &total)) err(1, "readtimes"); @@ -149,9 +179,10 @@ if (curfreq < freqs[i]) break; printf("Idle time < 50%%, increasing clock" - " speed from %dMHz to %dMHz\n", curfreq, - freqs[i]); - if (setcurfreq(freqs[i])) + " speed from %d%s to %d%s\n", curfreq, + sctl_names[cmethod].measure, freqs[i], + sctl_names[cmethod].measure); + if (setcurfreq(cmethod, freqs[i])) err(1, "Error setting CPU frequency"); } if ((idle > (total * 3) / 4) && (curfreq > freqs[0])) { @@ -159,9 +190,10 @@ if (curfreq > freqs[i]) break; printf("Idle time > 75%%, decreasing clock" - " speed from %dMHz to %dMHz\n", curfreq, - freqs[i]); - if (setcurfreq(freqs[i])) + " speed from %d%s to %d%s\n", curfreq, + sctl_names[cmethod].measure, freqs[i], + sctl_names[cmethod].measure); + if (setcurfreq(cmethod, freqs[i])) err(1, "Error setting CPU frequency"); } } while(1); --------------080500030706020202000104-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 17:01: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 1715916A4CE for ; Sun, 5 Sep 2004 17:01:42 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2051843D48 for ; Sun, 5 Sep 2004 17:01:37 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id D2F82304F for ; Sun, 5 Sep 2004 12:01:35 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25578-02 for ; Sun, 5 Sep 2004 12:01:27 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 3492E3049 for ; Sun, 5 Sep 2004 12:01:27 -0500 (CDT) Message-ID: <413B4660.6090203@veldy.net> Date: Sun, 05 Sep 2004 12:01:20 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7CD12AC2016543399BD66D7D" X-Virus-Scanned: by amavisd-new at veldy.net Subject: ATTN Soren: BETA3 still hangs on ATAPI DVD Detection during boot 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, 05 Sep 2004 17:01:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7CD12AC2016543399BD66D7D Content-Type: multipart/mixed; boundary="------------090104090608050106050708" This is a multi-part message in MIME format. --------------090104090608050106050708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I just downloaded and tried to install FreeBSD 5.3-BETA3 and it still hangs in the same location as it has for more than one month. However, now it boots alright when I chose the verbose logging option 5. I did the install and have attached the output of the subsequent dmesg. Tom Veldhouse --------------090104090608050106050708 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.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. FreeBSD 5.3-BETA3 #0: Sat Sep 4 12:07:48 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a2b000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a2b21c. Calibrating clock(s) ... i8254 clock: 1193181 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3049502520 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3049.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 536276992 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x000000001f640fff, 513900544 bytes (125464 pages) avail memory = 515112960 (491 MB) Table 'FACP' at 0xfd588 Table 'SSDT' at 0xfffe5e96 Table 'APIC' at 0xfd5fc MADT: Found table at 0xfd5fc MP Configuration Table version 1.4 found at 0xc00f0000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: disabled MADT: Found CPU APIC ID 3 ACPI ID 4: disabled ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbe8e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25308086) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fba30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 14 15 embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 2 12 A 0x62 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 A 0x60 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 B 0x61 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 C 0x62 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 D 0x63 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 A 0x61 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 B 0x62 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 C 0x63 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 D 0x60 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 A 0x62 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 B 0x63 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 C 0x60 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 D 0x61 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 A 0x63 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 B 0x60 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 C 0x61 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 D 0x62 3 4 5 6 7 9 10 11 14 15 embedded 2 1 A 0x63 3 4 5 6 7 9 10 11 14 15 embedded 2 1 B 0x62 3 4 5 6 7 9 10 11 14 15 embedded 2 1 C 0x60 3 4 5 6 7 9 10 11 14 15 embedded 2 2 A 0x62 3 4 5 6 7 9 10 11 14 15 embedded 2 2 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 2 2 C 0x63 3 4 5 6 7 9 10 11 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 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=0x8086, dev=0x2530, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2532, revid=0x04 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244e, revid=0x04 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2440, revid=0x04 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x244b, revid=0x04 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ccf0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2443, revid=0x04 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xff800000-0xff9fffff pcib1: prefetched decode 0xe8000000-0xf7ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base f0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xf0000000-0xf7ffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base ff8f0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xff8f0000-0xff8fffff pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0x4e44, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0183, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base e8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe8000000-0xefffffff map[14]: type 1, range 32, base ff8e0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xff8e0000-0xff8effff found-> vendor=0x1002, dev=0x4e64, revid=0x00 bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xff600000-0xff7fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: pci2: on pcib2 pci2: physical bus=2 map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdce0-0xdcff pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 19 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=1, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=19 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dcc0, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdcc0-0xdcdf pcib2: matched entry for 2.1.INTB pcib2: slot 1 INTB hardwired to IRQ 18 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=1, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=18 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6ffc00, size 8, enabled pcib2: device (null) requested decoded memory range 0xff6ffc00-0xff6ffcff pcib2: matched entry for 2.1.INTC pcib2: slot 1 INTC hardwired to IRQ 16 found-> vendor=0x1106, dev=0x3104, revid=0x51 bus=2, slot=1, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=16 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dca0, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdca0-0xdcbf pcib2: matched entry for 2.2.INTA pcib2: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=2, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dc80, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdc80-0xdc9f pcib2: matched entry for 2.2.INTB pcib2: slot 2 INTB hardwired to IRQ 17 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=2, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6ff800, size 8, enabled pcib2: device (null) requested decoded memory range 0xff6ff800-0xff6ff8ff pcib2: matched entry for 2.2.INTC pcib2: slot 2 INTC hardwired to IRQ 19 found-> vendor=0x1106, dev=0x3104, revid=0x51 bus=2, slot=2, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=19 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6fe000, size 12, enabled pcib2: device (null) requested decoded memory range 0xff6fe000-0xff6fefff map[14]: type 4, range 32, base 0000dc70, size 4, enabled pcib2: device (null) requested decoded I/O range 0xdc70-0xdc7f pcib2: matched entry for 2.8.INTA pcib2: slot 8 INTA hardwired to IRQ 17 found-> vendor=0x14e4, dev=0x4212, revid=0x02 bus=2, slot=8, func=0 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc40, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdc40-0xdc5f pcib2: matched entry for 2.9.INTA pcib2: slot 9 INTA hardwired to IRQ 18 found-> vendor=0x1102, dev=0x0002, revid=0x0a bus=2, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=18 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc68, size 3, enabled pcib2: device (null) requested decoded I/O range 0xdc68-0xdc6f found-> vendor=0x1102, dev=0x7002, revid=0x0a bus=2, slot=9, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ff6fd000, size 12, enabled pcib2: device (null) requested decoded memory range 0xff6fd000-0xff6fdfff map[14]: type 4, range 32, base 0000dc00, size 6, enabled pcib2: device (null) requested decoded I/O range 0xdc00-0xdc3f map[18]: type 1, range 32, base ff6c0000, size 17, enabled pcib2: device (null) requested decoded memory range 0xff6c0000-0xff6dffff pcib2: matched entry for 2.12.INTA pcib2: slot 12 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1229, revid=0x10 bus=2, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 uhci0: port 0xdce0-0xdcff irq 19 at device 1.0 on pci2 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 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 uscanner0: Visioneer USB Scanner, rev 1.10/1.00, addr 2 uhci1: port 0xdcc0-0xdcdf irq 18 at device 1.1 on pci2 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdcc0 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 pci2: at device 1.2 (no driver attached) uhci2: port 0xdca0-0xdcbf irq 18 at device 2.0 on pci2 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdca0 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 ugen0: Logitech Logitech Extreme 3D Pro, rev 1.10/35.00, addr 2 uhci3: port 0xdc80-0xdc9f irq 17 at device 2.1 on pci2 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdc80 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 pci2: at device 2.2 (no driver attached) pci2: at device 8.0 (no driver attached) pci2: at device 9.0 (no driver attached) pci2: random: mem: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80003074 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D80] is there (id=3D03951279) pcibios: BIOS version 2.10 =46ound $PIR table, 9 entries at 0xc00fdf30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 2 A 0x59 3 4 5 7 10 11 embedded 0 4 A 0x08 3 4 5 7 9 10 14 15 embedded 0 12 A 0x01 3 4 5 7 9 10 14 15 embedded 0 16 A 0x02 3 4 5 7 9 10 14 15 embedded 0 18 A 0x05 3 4 5 7 9 10 14 15 embedded 0 18 B 0x06 3 4 5 7 9 10 14 15 embedded 0 19 A 0x03 3 4 5 7 9 10 14 15 embedded 0 20 A 0x04 3 4 5 7 9 10 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 6 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 6 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 18 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 12 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_ec0: port 0x66,0x62 on acpi0 ACPI timer looks BAD min =3D 2, max =3D 815, width =3D 813 ACPI timer looks BAD min =3D 2, max =3D 7, width =3D 5 ACPI timer looks BAD min =3D 2, max =3D 5, width =3D 3 ACPI timer looks BAD min =3D 2, max =3D 7, width =3D 5 ACPI timer looks GOOD min =3D 2, max =3D 4, width =3D 2 ACPI timer looks GOOD min =3D 2, max =3D 4, width =3D 2 ACPI timer looks GOOD min =3D 2, max =3D 4, width =3D 2 ACPI timer looks GOOD min =3D 2, max =3D 4, width =3D 2 ACPI timer looks BAD min =3D 2, max =3D 5, width =3D 3 ACPI timer looks GOOD min =3D 2, max =3D 4, width =3D 2 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xff08-0xff0b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 acpi link get: empty IRQ resource acpi link get: empty IRQ resource ACPI PCI link initial configuration: \\_SB_.PCI0.EIO_.LNKU irq 0: [ 3 4 5 7 9 10 11] 11+ low,level,sharable= =20 0.2.0 \\_SB_.PCI0.EIO_.LNKH irq 0: [ 3 4 5 7 9 10 11] 9+ low,level,sharable= =20 0.4.0 \\_SB_.PCI0.EIO_.LNKA irq 0: [ 3 4 5 7 9 10 11] 9+ low,level,sharable= =20 0.12.0 \\_SB_.PCI0.EIO_.LNKC irq 0: [ 3 4 5 7 9 10 11] 9+ low,level,sharable= =20 0.19.0 \\_SB_.PCI0.EIO_.LNKD irq 0: [ 3 4 5 7 9 10 11] 9+ low,level,sharable= =20 0.20.0 \\_SB_.PCI0.EIO_.LNKB irq 0: [ 3 4 5 7 9 10 11] 9+ low,level,sharable= =20 0.16.0 \\_SB_.PCI0.EIO_.LNKE irq 0: [ 3 4 5 7 9 10 11] 0+ low,level,sharable= =20 0.18.0 \\_SB_.PCI0.EIO_.LNKF irq 0: [ 3 4 5 7 9 10 11] 0+ low,level,sharable= =20 0.18.1 pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 1, range 32, base fc100000, size 20, enabled found-> vendor=3D0x1279, dev=3D0x0395, revid=3D0x02 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x2200, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x1279, dev=3D0x0396, revid=3D0x00 bus=3D0, slot=3D0, func=3D1 class=3D05-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x1279, dev=3D0x0397, revid=3D0x00 bus=3D0, slot=3D0, func=3D2 class=3D05-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[10]: type 1, range 32, base fc004000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.EIO_.LNKU) pcib0: possible interrupts: 3 4 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.EIO_.LNKU (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKH (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKA (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKC (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKD (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKB (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKE (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 \\_SB_.PCI0.EIO_.LNKF (references 1, priority 2241): interrupts: 11 10 5 9 7 4 3 penalty: 80 80 130 160 5080 5080 5080 pcib0: slot 2 INTA routed to irq 11 via \\_SB_.PCI0.EIO_.LNKU found-> vendor=3D0x10b9, dev=3D0x5237, revid=3D0x03 bus=3D0, slot=3D2, func=3D0 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0017, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x50 (20000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00001000, size 8, enabled map[14]: type 1, range 32, base fc005000, size 12, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.PCI0.EIO_.LNKH) pcib0: possible interrupts: 3 4 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.EIO_.LNKH (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 \\_SB_.PCI0.EIO_.LNKA (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 \\_SB_.PCI0.EIO_.LNKC (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 \\_SB_.PCI0.EIO_.LNKD (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 \\_SB_.PCI0.EIO_.LNKB (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 \\_SB_.PCI0.EIO_.LNKE (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 \\_SB_.PCI0.EIO_.LNKF (references 1, priority 2334): interrupts: 10 11 5 9 7 4 3 penalty: 160 170 210 320 5160 5160 5160 pcib0: slot 4 INTA routed to irq 9 via \\_SB_.PCI0.EIO_.LNKH found-> vendor=3D0x10b9, dev=3D0x5451, revid=3D0x01 bus=3D0, slot=3D4, func=3D0 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0003, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x18 (6000 ns) intpin=3Da, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=3D0x10b9, dev=3D0x7101, revid=3D0x00 bus=3D0, slot=3D6, func=3D0 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0000, statreg=3D0x0200, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x10b9, dev=3D0x1533, revid=3D0x00 bus=3D0, slot=3D7, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x000f, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) powerspec 1 supports D0 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled pcib0: matched entry for 0.12.INTA (src \\_SB_.PCI0.EIO_.LNKA) pcib0: possible interrupts: 3 4 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.EIO_.LNKA (references 1, priority 2427): interrupts: 10 11 5 9 7 4 3 penalty: 240 250 290 490 5240 5240 5240 \\_SB_.PCI0.EIO_.LNKC (references 1, priority 2427): interrupts: 10 11 5 9 7 4 3 penalty: 240 250 290 490 5240 5240 5240 \\_SB_.PCI0.EIO_.LNKD (references 1, priority 2427): interrupts: 10 11 5 9 7 4 3 penalty: 240 250 290 490 5240 5240 5240 \\_SB_.PCI0.EIO_.LNKB (references 1, priority 2427): interrupts: 10 11 5 9 7 4 3 penalty: 240 250 290 490 5240 5240 5240 \\_SB_.PCI0.EIO_.LNKE (references 1, priority 2427): interrupts: 10 11 5 9 7 4 3 penalty: 240 250 290 490 5240 5240 5240 \\_SB_.PCI0.EIO_.LNKF (references 1, priority 2427): interrupts: 10 11 5 9 7 4 3 penalty: 240 250 290 490 5240 5240 5240 pcib0: slot 12 INTA routed to irq 9 via \\_SB_.PCI0.EIO_.LNKA found-> vendor=3D0x104c, dev=3D0xac50, revid=3D0x01 bus=3D0, slot=3D12, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Da, irq=3D9 powerspec 1 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00001800, size 4, enabled found-> vendor=3D0x10b9, dev=3D0x5229, revid=3D0xc3 bus=3D0, slot=3D15, func=3D0 class=3D01-01-fa, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 (1000 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00008000, size 8, enabled map[14]: type 1, range 32, base fc007800, size 8, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.EIO_.LNKB) pcib0: possible interrupts: 3 4 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.EIO_.LNKC (references 1, priority 2520): interrupts: 10 11 5 9 7 4 3 penalty: 320 330 370 660 5320 5320 5320 \\_SB_.PCI0.EIO_.LNKD (references 1, priority 2520): interrupts: 10 11 5 9 7 4 3 penalty: 320 330 370 660 5320 5320 5320 \\_SB_.PCI0.EIO_.LNKB (references 1, priority 2520): interrupts: 10 11 5 9 7 4 3 penalty: 320 330 370 660 5320 5320 5320 \\_SB_.PCI0.EIO_.LNKE (references 1, priority 2520): interrupts: 10 11 5 9 7 4 3 penalty: 320 330 370 660 5320 5320 5320 \\_SB_.PCI0.EIO_.LNKF (references 1, priority 2520): interrupts: 10 11 5 9 7 4 3 penalty: 320 330 370 660 5320 5320 5320 pcib0: slot 16 INTA routed to irq 9 via \\_SB_.PCI0.EIO_.LNKB found-> vendor=3D0x10ec, dev=3D0x8139, revid=3D0x10 bus=3D0, slot=3D16, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0003, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x20 (8000 ns), maxlat=3D0x40 (16000 n= s) intpin=3Da, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fc007000, size 11, enabled map[14]: type 1, range 32, base fc000000, size 14, enabled pcib0: matched entry for 0.19.INTA (src \\_SB_.PCI0.EIO_.LNKC) pcib0: possible interrupts: 3 4 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.EIO_.LNKC (references 1, priority 2612): interrupts: 10 11 5 9 7 4 3 penalty: 400 410 450 830 5400 5400 5400 \\_SB_.PCI0.EIO_.LNKD (references 1, priority 2612): interrupts: 10 11 5 9 7 4 3 penalty: 400 410 450 830 5400 5400 5400 \\_SB_.PCI0.EIO_.LNKE (references 1, priority 2612): interrupts: 10 11 5 9 7 4 3 penalty: 400 410 450 830 5400 5400 5400 \\_SB_.PCI0.EIO_.LNKF (references 1, priority 2612): interrupts: 10 11 5 9 7 4 3 penalty: 400 410 450 830 5400 5400 5400 pcib0: slot 19 INTA routed to irq 9 via \\_SB_.PCI0.EIO_.LNKC found-> vendor=3D0x104c, dev=3D0x8026, revid=3D0x00 bus=3D0, slot=3D19, func=3D0 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0012, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 (1000 ns) intpin=3Da, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fd000000, size 24, enabled map[14]: type 4, range 32, base 00001400, size 8, enabled map[18]: type 1, range 32, base fc006000, size 12, enabled pcib0: matched entry for 0.20.INTA (src \\_SB_.PCI0.EIO_.LNKD) pcib0: possible interrupts: 3 4 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.EIO_.LNKD (references 1, priority 2705): interrupts: 10 11 5 9 7 4 3 penalty: 480 490 530 1000 5480 5480 5480 \\_SB_.PCI0.EIO_.LNKE (references 1, priority 2705): interrupts: 10 11 5 9 7 4 3 penalty: 480 490 530 1000 5480 5480 5480 \\_SB_.PCI0.EIO_.LNKF (references 1, priority 2705): interrupts: 10 11 5 9 7 4 3 penalty: 480 490 530 1000 5480 5480 5480 pcib0: slot 20 INTA routed to irq 9 via \\_SB_.PCI0.EIO_.LNKD found-> vendor=3D0x1002, dev=3D0x4c52, revid=3D0x64 bus=3D0, slot=3D20, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0087, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D9 powerspec 1 supports D0 D1 D2 D3 current D0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) ohci0: mem 0xfc004000-0xfc004ff= f=20 irq 11 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfc004000 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcm0: port 0x1000-0x10ff mem 0xfc005000-0xfc005fff irq 9 = at=20 device 4.0 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1000 pcm0: pcm0: Codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel = 3D=20 Enhancement pcm0: Primary codec extended features variable rate PCM, reserved 1, AMAP pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap 1c8000, 1000; 0xc1174000 -> 1c8000 pcm0: sndbuf_setmap 1e6000, 1000; 0xc1172000 -> 1e6000 pcm0: sndbuf_setmap e984000, 1000; 0xc1170000 -> e984000 pcm0: sndbuf_setmap e9a2000, 1000; 0xc116e000 -> e9a2000 pcm0: sndbuf_setmap 218000, 1000; 0xc1184000 -> 218000 pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 12.0 (no driver attached) atapci0: port=20 0x1800-0x180f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1800 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=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0-master: stat=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0-master: stat=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0-master: stat=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0-master: stat=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 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] rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x8000 rl0: port 0x8000-0x80ff mem 0xfc007800-0xfc0078= ff=20 irq 9 at device 16.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:e0:00:ae:45:08 rl0: [MPSAFE] fwohci0: mem=20 0xfc000000-0xfc003fff,0xfc007000-0xfc0077ff irq 9 at device 19.0 on pci0 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfc007000 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0e:10:00:b0:29:d0 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 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) acpi_video0: port 0x1400-0x14ff mem=20 0xfc006000-0xfc006fff,0xfd000000-0xfdffffff irq 9 at device 20.0 on pci0 found CRT monitor(100), detectable by BIOS, head #0 found LCD panel(110), detectable by BIOS, head #0 found TV(200), detectable by BIOS, head #0 acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 psmcpnp0 irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: flags 0x3000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00003000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi_fuji0: on acpi0 unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 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 0xd0000-0xd0fff,0xc0000-0xcffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=3D0x200> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this=20 adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 e7 7e 4f 4f 82 55 03=20 b4 1f 00 4f 0d 0e 00 00 07 80 92 88 8f 28 1f 8f=20 b5 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 e7 7e 4f 4f 82 55 03=20 b4 1f 00 4f 0d 0e 00 00 07 80 92 88 8f 28 1f 8f=20 b5 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 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 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0 failed to probe at port 0x3f8 irq 4 flags 0x10 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 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. procfs registered Timecounter "TSC" frequency 859335780 Hz quality 800 Timecounters tick every 0.976 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 system power profile changed to 'economy' acpi_acad0: Off 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 ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: setting PIO4 on AcerLabs Aladdin chip ata0-master: setting UDMA66 on AcerLabs Aladdin chip ad0: ATA-5 disk at ata0-master ad0: 19077MB (39070080 sectors), 38760 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA66 GEOM: new disk ad0 ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x42 cable=3D80pin ATAPI_RESET time =3D 80us ata1-master: setting PIO4 on AcerLabs Aladdin chip acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 2755KB/s (2755KB/s), 2048KB buffer, PI= O4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc [0] f:00 typ:7 s(CHS):0/1/1 e(CHS):1023/2/63 s:63 l:10490382 [1] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/9/63 s:10490445 l:20964825 [2] f:00 typ:12 s(CHS):1023/255/63 e(CHS):1023/0/63 s:31455270 l:7598745 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 5371075584 end 5371107839 GEOM: Configure ad0s2, start 5371107840 length 10733990400 end 16105098239 GEOM: Configure ad0s3, start 16105098240 length 3890557440 end 19995655679 GEOM: Configure ad0s2a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s2b, start 268435456 length 481656832 end 750092287 GEOM: Configure ad0s2c, start 0 length 10733990400 end 10733990399 GEOM: Configure ad0s2d, start 750092288 length 268435456 end 1018527743 GEOM: Configure ad0s2e, start 1018527744 length 268435456 end 1286963199 GEOM: Configure ad0s2f, start 1286963200 length 9447027200 end 10733990399 Mounting root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted start_init: trying /sbin/init WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 4 files 0 linprocfs registered umass0: Sony Sony DSC, rev 2.00/5.00, addr 2 umass0: RBC over CBI; quirks =3D 0x0000 umass0:0:0:-1: Attached to scbus0 =2D-=20 Anish Mistry --Boundary-02=_oN5OBooXw3BNWiT Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBO5NoxqA5ziudZT0RAmIAAKDGJIZEmp479QWmZz80UOucFZ6ZGQCfb5Fg V3nQbVSNNnu6lsuyHssTthM= =X6ai -----END PGP SIGNATURE----- --Boundary-02=_oN5OBooXw3BNWiT-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 22:59: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 F3E8E16A4CE for ; Sun, 5 Sep 2004 22:59:03 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23CE243D48 for ; Sun, 5 Sep 2004 22:59:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26797 invoked from network); 5 Sep 2004 22:56:01 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2004 22:56:01 -0000 Message-ID: <413B9A36.2D0B9696@freebsd.org> Date: Mon, 06 Sep 2004 00:59:02 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Boris B.Samorodov" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: FreeBSD-gnats-submit@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12 in kernel module uipc_mbuf2.c 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, 05 Sep 2004 22:59:04 -0000 "Boris B.Samorodov" wrote: > > >Submitter-Id: current-users > >Originator: Boris B. Samorodov > >Organization: InPharmTech Co. > >Confidential: no > >Synopsis: Fatal Trap 12 in kernel module uipc_mbuf2.c > >Severity: serious > >Priority: medium > >Category: kern > >Class: sw-bug > >Release: FreeBSD 5.3-BETA2 i386 > >Environment: > System: FreeBSD gw.ipt.ru 5.3-BETA2 FreeBSD 5.3-BETA2 #6: Sat Sep 4 17:47:55 MSD 2004 bsam@gw.ipt.ru:/usr/obj/usr/src/sys/GW i386 > > >Description: > Fatal Trap 12, pointer: 0xc053a1f0. > > # addr2line -e /root/kernel/kernel.debug 0xc053a1f0 > ----- > ../../../kern/uipc_mbuf2.c:389 > ----- > # gdb6 -k /root/kernel/kernel.debug vmcore.1 > ----- > GNU gdb 20040803 [GDB v6.x for FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-portbld-freebsd5.3"...can not access 0xc070b588, invalid address (c070b588) > can not access 0xc070b588, invalid address (c070b588) > > panic messages: > --- > dmesg: kvm_read: invalid address (c075cc54) > can not access 0xc070b6c0, invalid address (c070b6c0) > can not access 0xc070b6c0, invalid address (c070b6c0) > --- > #0 0x00000000 in ?? () > 0x00000000 in ?? () > (kgdb) list *m_tag_locate+0x40 > 0xc053a1f0 is in m_tag_locate (../../../kern/uipc_mbuf2.c:389). > 384 if (t == NULL) > 385 p = SLIST_FIRST(&m->m_pkthdr.tags); > 386 else > 387 p = SLIST_NEXT(t, m_tag_link); > 388 while (p != NULL) { > 389 if (p->m_tag_cookie == cookie && p->m_tag_id == type) > 390 return p; > 391 p = SLIST_NEXT(p, m_tag_link); > 392 } > 393 return NULL; > (kgdb) q > ----- > >How-To-Repeat: > The host have to upstream interfaces to ISP, three internal > networks with two interfaces (two internal networks are > aliased in one inteface). The default route is to the first > provider. We use policy routing to route our third network > to second provider. $inet1 and $inet2 are aliases on one > interface. > > After adding ipfw rule: > # ipfw add fwd $provider2 ip from $inet3 to { not $inet1 or not $inet2 } > gateway paniced. > > I know, that in fact the rule has to be "not $inet1,$inet2". > But logically the first rule has the value "all". OS must not > trap. Does it panic 'reliablily' in the same place or is it more of a random occurence? I'm not long in the office tomorrow (my test machine is there) but I'll try to reproduce it within the next few days. -- Andre From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 23:04: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 8C93C16A4CE for ; Sun, 5 Sep 2004 23:04:20 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2352C43D39 for ; Sun, 5 Sep 2004 23:04:20 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 2F37D1675C2 for ; Mon, 6 Sep 2004 01:04:19 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i85N4HVm055527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 6 Sep 2004 01:04:18 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Mon, 6 Sep 2004 01:04:13 +0200 User-Agent: KMail/1.7 References: <200409040351.06438.michaelnottebrock@gmx.net> <20040904040928.GA11829@odin.ac.hmc.edu> <200409040641.58361.michaelnottebrock@gmx.net> In-Reply-To: <200409040641.58361.michaelnottebrock@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1719178.sDnkKnIfAT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409060104.17383.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new Subject: Re: Where did debug.acpi.disabled go? 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, 05 Sep 2004 23:04:20 -0000 --nextPart1719178.sDnkKnIfAT Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 September 2004 06:41, Michael Nottebrock wrote: > Anyway, it turns out that debug.acpi.disabled=3D"sysresource" DOES work, = it > just doesn't make my floppy to probe and attach correctly anymore. > > I've attached devinfo -r output for acpi disabled, acpi with sysresource > disabled and full acpi, hopefully somebody can tell what's going wrong. T= he > error I get from the fdc device probe (it is actually probed twice with > acpi enabled, with the same error both times) is: > > fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 > drq 2 on acpi0 > fdc0: cmd 3 failed at out byte 1 of 3 > device_attach: fdc0 attach returned 6 Just updated to 5.3-BETA3, no change. :-( =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1719178.sDnkKnIfAT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBO5txXhc68WspdLARAkj0AKCZLdYXtQWPafeKmx6OEIYgzj6gZACfZ1+t 4mKVFL4spsw3j5mD0/KUjeU= =UNqw -----END PGP SIGNATURE----- --nextPart1719178.sDnkKnIfAT-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 23:14: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 DDEC416A4CE; Sun, 5 Sep 2004 23:14:29 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CD2D43D49; Sun, 5 Sep 2004 23:14:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i85NESEB078769; Sun, 5 Sep 2004 19:14:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i85NESK8020528; Sun, 5 Sep 2004 19:14:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9ECFF7303F; Sun, 5 Sep 2004 19:14:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040905231428.9ECFF7303F@freebsd-current.sentex.ca> Date: Sun, 5 Sep 2004 19:14:28 -0400 (EDT) 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: Sun, 05 Sep 2004 23:14:30 -0000 TB --- 2004-09-05 22:06:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-05 22:06:55 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-05 22:06:55 - checking out the source tree TB --- 2004-09-05 22:06:55 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-05 22:06:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-05 22:12:08 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-05 22:12:08 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-05 22:12:08 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c: In function `auth_ReadHeader': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:447: warning: unsigned int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:451: warning: unsigned int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c: In function `auth_ReadName': /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:462: warning: unsigned int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:468: warning: unsigned int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp/auth.c:468: warning: unsigned int format, different type arg (arg 4) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-05 23:14:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-05 23:14:28 - ERROR: failed to build world TB --- 2004-09-05 23:14:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 23:15: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 A2D7B16A4CE for ; Sun, 5 Sep 2004 23:15:38 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67C5243D1F for ; Sun, 5 Sep 2004 23:15:38 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1C46ET-0007hW-SW for freebsd-current@freebsd.org; Sun, 05 Sep 2004 16:15:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16699.40473.479503.177820@ran.psg.com> Date: Sun, 5 Sep 2004 16:15:37 -0700 To: FreeBSD Current Subject: java still not brewing 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, 05 Sep 2004 23:15:38 -0000 the long-ongoing problem with java seems to persist ===> Configuring for jdk-1.3.1p9_4 ===> Building for jdk-1.3.1p9_4 # Start of jdk build (cd /usr/ports/java/jdk13/work/j2sdk1.3.1/make; /usr/bin/env ALT_BOOTDIR="/usr/local/jdk1.3.1" ALT_MOTIF_DIR="/usr/X11R6" OPENWINHOME="/usr/X11R6" SYS_CFLAGS="-O -pipe -march=pentiumpro" CLASSPATH="" LD_LIBRARY_PATH="" JAVA_COMPILER="" LIBG_HDRS="/usr/local/include/glib12" GTK_HDRS="/usr/X11R6/include/gtk12" LIBIDL_HDRS= INTL_DIR="/usr/local" SHELL=/bin/sh PORTOBJFORMAT=elf PREFIX=/usr/local LOCALBASE=/usr/local X11BASE=/usr/X11R6 MOTIFLIB="-L/usr/X11R6/lib -lXm" LIBDIR="/usr/lib" CFLAGS="-O -pipe -march=pentiumpro" CXXFLAGS="-O -pipe -march=pentiumpro" MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -o root -g wheel -m 555" BSD_INSTALL_SCRIPT="install -o root -g wheel -m 555" BSD_INSTALL_DATA="install -o root -g wheel -m 444" BSD_INSTALL_MAN="install -o root -g wheel -m 444" gmake -f Makefile all plugin images) i386 Build started: 1.3.1-p9-root-040906-10:55 WARNING: Your MAKEFLAGS environment variable is set. You should be very careful about the values set here. MAKEFLAGS is set to =>SYSTEMVERSION= PORTOBJFORMAT=elf OSVERSION=600002 OSREL=6.0 OPSYS=FreeBSD ARCH=i386<= ERROR: Your BOOTDIR environment variable does not point to a valid Java 2 SDK for bootstrapping this build. A Java 2 SDK 1.3.1 build must be bootstrapped against any 1.3 build. Please update your ALT_BOOTDIR setting, or just unset it, and start your build again. Exiting because of the above error(s). gmake: *** [sanity] Error 1 *** Error code 2 [ and i no longer can seem to usefully search archives with http://www.freebsd.org/cgi/search.cgi to be sure i did not miss something ] randy From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 23:28: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 90B4316A4CE; Sun, 5 Sep 2004 23:28:31 +0000 (GMT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A41243D3F; Sun, 5 Sep 2004 23:28:31 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [192.168.2.126] (adsl-64-142-31-109.sonic.net [64.142.31.109]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i85NSUZF031972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 5 Sep 2004 16:28:31 -0700 From: "Bruce A. Mah" To: freebsd-doc@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nhL/WcP0jxyRvbtB5oFS" Message-Id: <1094426835.767.50.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 05 Sep 2004 16:27:15 -0700 cc: "Bruce A. Mah" Subject: RFC: 5.3 Migration Guide 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, 05 Sep 2004 23:28:31 -0000 --=-nhL/WcP0jxyRvbtB5oFS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Howdy-- I've volunteered to rework the 5.X Early Adopters Guide into a Migration Guide. The focus of this document is less about discouraging unwary users and more about what kinds of changes users might encounter when they move from 4.X to 5.X. I'd like to solicit a pre-commit review on the document at: http://people.freebsd.org/~bmah/pub/article.html A PDF rendering, as well as SGML source, also live in the same directory. The area I'm the most shaky on is the source upgrade procedure, which is basically an annotated version of the procedure in src/UPDATING. I haven't done this procedure in a *long* time, and I'm kind of short on scratch systems (=3D> none) at the moment for testing the procedure. In retrospect, I didn't actually plan on including this section, and I might have been less eager to take on this task if I'd know it was coming. :-) trhodes and scottl provided some helpful feedback on an earlier draft of this document. Thanks for any comments... Bruce. PS. This document will basically replace the EAG for 5.3. On HEAD, we should probably disable or kill the EAG. It's served its purpose (I think) and when it comes back in time for 6.0, it probably won't bear much resemblance to its current incarnation. --=-nhL/WcP0jxyRvbtB5oFS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBO6DT2MoxcVugUsMRAvItAJ9Pvp9D0TqBsJlgvA3qkSnd7FS9SQCggqqQ IOYn6j27ZsLku9aobnQbzdo= =jHfL -----END PGP SIGNATURE----- --=-nhL/WcP0jxyRvbtB5oFS-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 23:46: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 D1F7216A4CE for ; Sun, 5 Sep 2004 23:46:41 +0000 (GMT) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EC5A43D1D for ; Sun, 5 Sep 2004 23:46:40 +0000 (GMT) (envelope-from lists-freebsd-current@biaix.org) Received: (qmail 5406 invoked by uid 1000); 5 Sep 2004 23:44:45 -0000 Date: Mon, 6 Sep 2004 01:44:45 +0200 From: Joan Picanyol To: FreeBSD Current Message-ID: <20040905234445.GA5050@grummit.biaix.org> Mail-Followup-To: FreeBSD Current References: <16699.40473.479503.177820@ran.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16699.40473.479503.177820@ran.psg.com> User-Agent: Mutt/1.4.1i Subject: Re: java still not brewing 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, 05 Sep 2004 23:46:41 -0000 * Randy Bush [20040906 01:14]: > the long-ongoing problem with java seems to persist > > ===> Configuring for jdk-1.3.1p9_4 > ===> Building for jdk-1.3.1p9_4 I just built jdk14. It failed until I manually installed linux-sun-jdk14 HTH -- pica From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 00:06: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 C754116A4CE; Mon, 6 Sep 2004 00:06:26 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58DC343D1D; Mon, 6 Sep 2004 00:06:26 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 6DDD9167510; Mon, 6 Sep 2004 02:06:25 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i8606LVm026931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Sep 2004 02:06:23 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Mon, 6 Sep 2004 02:06:13 +0200 User-Agent: KMail/1.7 References: <1094426835.767.50.camel@localhost> In-Reply-To: <1094426835.767.50.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1198545.tutqnPKgsl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409060206.21145.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: "Bruce A. Mah" cc: freebsd-doc@freebsd.org Subject: Re: RFC: 5.3 Migration Guide 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, 06 Sep 2004 00:06:26 -0000 --nextPart1198545.tutqnPKgsl Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 06 September 2004 01:27, Bruce A. Mah wrote: > Howdy-- > > I've volunteered to rework the 5.X Early Adopters Guide into a Migration > Guide. The focus of this document is less about discouraging unwary > users and more about what kinds of changes users might encounter when > they move from 4.X to 5.X. > > I'd like to solicit a pre-commit review on the document at: > > http://people.freebsd.org/~bmah/pub/article.html Nice document! One thing I'm missing: The pthread libraries change probably requires people to recompile things=20 linked to it if they're migrating from 4.x - users updating from 5.x-Releas= es=20 can get away with setting up libmap.conf (maybe this is true for updating=20 from 4.x as well, can some threads expert comment on it?). =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1198545.tutqnPKgsl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBO6n9Xhc68WspdLARApQcAJ9MRs1U9pRuoWZqgWJ03Vf19Flo/gCbBd3K i6pvZ7bCs0vQjH0nUb1ZESM= =Srb4 -----END PGP SIGNATURE----- --nextPart1198545.tutqnPKgsl-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 00:24: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 CD04F16A4CE; Mon, 6 Sep 2004 00:24:19 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 204C643D5A; Mon, 6 Sep 2004 00:24:19 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i860LZA0060735; Sun, 5 Sep 2004 20:21:35 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Michael Nottebrock In-Reply-To: <200409060206.21145.michaelnottebrock@gmx.net> References: <1094426835.767.50.camel@localhost> <200409060206.21145.michaelnottebrock@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Bt+T2m5IVKDP4xcekUuz" Organization: MarcusCom, Inc. Message-Id: <1094430249.25711.8.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 05 Sep 2004 20:24:09 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com cc: "Bruce A. Mah" cc: freebsd-doc@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: RFC: 5.3 Migration Guide 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, 06 Sep 2004 00:24:19 -0000 --=-Bt+T2m5IVKDP4xcekUuz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-09-05 at 20:06, Michael Nottebrock wrote: > On Monday 06 September 2004 01:27, Bruce A. Mah wrote: > > Howdy-- > > > > I've volunteered to rework the 5.X Early Adopters Guide into a Migratio= n > > Guide. The focus of this document is less about discouraging unwary > > users and more about what kinds of changes users might encounter when > > they move from 4.X to 5.X. > > > > I'd like to solicit a pre-commit review on the document at: > > > > http://people.freebsd.org/~bmah/pub/article.html >=20 > Nice document! >=20 > One thing I'm missing: >=20 > The pthread libraries change probably requires people to recompile things= =20 > linked to it if they're migrating from 4.x - users updating from 5.x-Rele= ases=20 > can get away with setting up libmap.conf (maybe this is true for updating= =20 > from 4.x as well, can some threads expert comment on it?). Users should really rebuild ALL ports when upgrading from 4.X to 5.3-RELEASE. Only simple applications that only rely on libraries in compat4x will work correctly. Others, for example GTK+ apps, may link to both libc_r.so.4 and libpthread.so.1. That could spell disaster. I would also mention /usr/ports/UPDATING in this document. There are a lot of useful hints in there when it comes to upgrading things such as Perl and X (as well as the recently recent KDE 3.3). Plus, it would give this file much needed publicity. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-Bt+T2m5IVKDP4xcekUuz 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) iD8DBQBBO64pb2iPiv4Uz4cRAttYAJ9fgoC+f4xhvptDynTkiaRSk04iXgCfbyxD AGKh6EPJ19IezIQGZRYeRaw= =9N1n -----END PGP SIGNATURE----- --=-Bt+T2m5IVKDP4xcekUuz-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 00:58: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 AF51B16A4CE for ; Mon, 6 Sep 2004 00:58:52 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BCD2C43D1F for ; Mon, 6 Sep 2004 00:58:51 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail 23803 invoked by uid 65534); 6 Sep 2004 00:58:49 -0000 Received: from unknown (EHLO [212.204.44.203]) (212.204.44.203) by mail.gmx.net (mp009) with SMTP; 06 Sep 2004 02:58:49 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-x0re1S4CBawD1pXCUl7k" Message-Id: <1094432328.878.7.camel@klamath.ankon.de.eu.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 06 Sep 2004 02:58:49 +0200 Subject: Panic (Page fault) related to ipv6? [softclock, nd6_timer, in6_purgeaddr, in6_unlink_ifa] 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, 06 Sep 2004 00:58:52 -0000 --=-x0re1S4CBawD1pXCUl7k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, just got this panic, perhaps someone is interested. Happened when reading a probably damaged CD, don't know if that is related (didn't look so in the backtrace). System is FreeBSD klamath.ankon.de.eu.org 6.0-CURRENT FreeBSD 6.0-CURRENT #16: Sun Sep 5 12:18:47 CEST 2004 =20 root@klamath.ankon.de.eu.org:/usr/obj/usr/src/sys/KLAMATH i386, sources from around ~0900. Kernel config contains IPV6, IPSEC (so no mpsafenet), ULE, and the default setting for PREEMPTION (i didn't set any), no WITNESS or INVARIANTS, but makeoptions DEBUG=3D-g. Here it is: ----- Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x1 fault code =3D supervisor write, page not present instruction pointer =3D 0x8:0xc05e5f12 stack pointer =3D 0x10:0xcbf1dc0c frame pointer =3D 0x10:0xcbf1dc28 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 27 (swi5: clock sio) trap number =3D 12 panic: page fault (kgdb) bt full #0 doadump () at pcpu.h:159 No locals. #1 0xc051b576 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:385 first_buf_printf =3D 1 #2 0xc051bcf7 in panic (fmt=3D0xc0708284 "%s") at /usr/src/sys/kern/kern_shutdown.c:541 bootopt =3D 260 newpanic =3D 0 buf =3D "page fault", '\0' #3 0xc06de456 in trap_fatal (frame=3D0xcbf1dbcc, eva=3D1) at /usr/src/sys/i386/i386/trap.c:809 code =3D 16 type =3D 12 ss =3D 16 esp =3D 0 softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27= ,=20 ssd_dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 4, ssd_xx1 =3D 1, ssd_def32 =3D 1, ssd_gran =3D 1} #4 0xc06de6fb in trap_pfault (frame=3D0xcbf1dbcc, usermode=3D0, eva=3D1) at /usr/src/sys/i386/i386/trap.c:727 va =3D 0 vm =3D (struct vmspace *) 0x0 map =3D 0xc076cb20 rv =3D 1 ---Type to continue, or q to quit--- ftype =3D 1 '\001' p =3D (struct proc *) 0x0 #5 0xc06deaf5 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1042350080, tf= _esi =3D -1, tf_ebp =3D -873341912, tf_isp =3D -873341960, tf_ebx =3D -104235008= 0, tf_edx =3D -1043508736, tf_ecx =3D -1042350080, tf_eax =3D 1, tf_trapno =3D= 12, tf_err =3D 2, tf_eip =3D -1067557102, tf_cs =3D 8, tf_eflags =3D 66182, tf_= esp =3D 4, tf_ss =3D 582}) at /usr/src/sys/i386/i386/trap.c:417 p =3D (struct proc *) 0xc1901540 sticks =3D 3421625312 i =3D 0 ucode =3D 0 type =3D 12 code =3D 2 eva =3D 1 #6 0xc06d019a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 No locals. #7 0x00000018 in ?? () No symbol table info available. #8 0x00000010 in ?? () No symbol table info available. #9 0x00000010 in ?? () No symbol table info available. ---Type to continue, or q to quit--- #10 0xc1df0000 in ?? () No symbol table info available. #11 0xffffffff in ?? () No symbol table info available. #12 0xcbf1dc28 in ?? () No symbol table info available. #13 0xcbf1dbf8 in ?? () No symbol table info available. #14 0xc1df0000 in ?? () No symbol table info available. #15 0xc1cd5200 in ?? () No symbol table info available. #16 0xc1df0000 in ?? () No symbol table info available. #17 0x00000001 in ?? () No symbol table info available. #18 0x0000000c in ?? () No symbol table info available. #19 0x00000002 in ?? () No symbol table info available. #20 0xc05e5f12 in in6_unlink_ifa (ia=3D0x0, ifp=3D0xc1df0000) at /usr/src/sys/netinet6/in6.c:1157 oia =3D (struct in6_ifaddr *) 0xc1df0000 ---Type to continue, or q to quit--- #21 0xc05e615d in in6_purgeaddr (ifa=3D0xc1df0000) at /usr/src/sys/netinet6/in6.c:1146 ifp =3D (struct ifnet *) 0xc0751060 #22 0xc06019bf in nd6_timer (ignored_arg=3D0x0) at /usr/src/sys/netinet6/nd6.c:562 regen =3D 0 ln =3D (struct llinfo_nd6 *) 0xc1d7e440 dr =3D (struct nd_defrouter *) 0x0 pr =3D (struct nd_prefix *) 0x0 ia6 =3D (struct in6_ifaddr *) 0xc1df0000 nia6 =3D (struct in6_ifaddr *) 0xc1d7e440 #23 0xc052ab55 in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout.c:259 c_func =3D (void (*)(void *)) 0xc0601880 c_arg =3D (void *) 0x0 c_flags =3D 6 c =3D (struct callout *) 0x0 bucket =3D (struct callout_tailq *) 0xc688c460 steps =3D 6 depth =3D 4 mpcalls =3D 1 gcalls =3D 3 wakeup_cookie =3D 6 #24 0xc0502229 in ithread_loop (arg=3D0xc18f8580) ---Type to continue, or q to quit--- at /usr/src/sys/kern/kern_intr.c:547 ih =3D (struct intrhand *) 0xc18f3380 p =3D (struct proc *) 0xc1901540 count =3D 0 warming =3D 5000 warned =3D 0 #25 0xc0500f82 in fork_exit (callout=3D0xc0502170 , arg=3D0x0= , frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:807 p =3D (struct proc *) 0xc1901540 #26 0xc06d01fc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 No locals. ---- Please don't hesitate to ask for any additional information you might need. Thank you! Regards, Andreas Kohn --=-x0re1S4CBawD1pXCUl7k Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBO7ZIYucd7Ow1ygwRAhncAJwKwYcHco2Evi8oM8Z7e6LeywV1WgCfW/LU UYmx+HXeaj2T1iCduj3q86o= =SyKY -----END PGP SIGNATURE----- --=-x0re1S4CBawD1pXCUl7k-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 01:22: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 D27C316A4CE for ; Mon, 6 Sep 2004 01:22:32 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E8A843D31 for ; Mon, 6 Sep 2004 01:22:32 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id A315A304B; Sun, 5 Sep 2004 20:22:31 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29077-08; Sun, 5 Sep 2004 20:22:26 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 588343049; Sun, 5 Sep 2004 20:22:26 -0500 (CDT) Message-ID: <413BBBC7.2000904@veldy.net> Date: Sun, 05 Sep 2004 20:22:15 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <413B4660.6090203@veldy.net> <413B5361.9070201@DeepCore.dk> In-Reply-To: <413B5361.9070201@DeepCore.dk> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5F1C39516CE453F4FA1C487A" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at veldy.net cc: freebsd-current@freebsd.org Subject: Re: ATTN Soren: BETA3 still hangs on ATAPI DVD Detection during boot 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, 06 Sep 2004 01:22:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5F1C39516CE453F4FA1C487A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Søren Schmidt wrote: > You need to run -current to get the latest fixes, they have not made > it in before BETA3 was cut. I have not had time to do it and nobody > else seem to have felt it was important enough to even offer to help... > You mentioned earlier to just copy the CURRENT files /usr/src/sys/dev/ata/* over into the 5.3-BETA and rebuild the kernel (GENERIC, no optimizations). I just did that today with the 19:30CDT CURRENT kernel sources and I am still seeing this hang. Should I be looking elsewhere for this fix (i.e. ACPI)? Thanks, Tom Veldhouse --------------enig5F1C39516CE453F4FA1C487A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBO7vLARgTFXYf0wARArKJAJ9Nsy2PDP4PVp/m/X901RqYVFuRPQCgwiP0 bTe/Hsc/1qykXuyM0+ZRuzE= =xiB5 -----END PGP SIGNATURE----- --------------enig5F1C39516CE453F4FA1C487A-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 01:26: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 B14F616A4CE for ; Mon, 6 Sep 2004 01:26:35 +0000 (GMT) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id A62CE43D3F for ; Mon, 6 Sep 2004 01:26:34 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 11669 invoked from network); 6 Sep 2004 01:26:33 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-4.9/8.0):. Processed in 0.727911 secs); 06 Sep 2004 01:26:33 -0000 X-Spam-Status: No, hits=-4.9 required=8.0 Received: from 213-240-202-139.1697748.ddns.cablebg.net (HELO tormentor.totalterror.net) (213.240.202.139) by mail.interbgc.com with SMTP; 6 Sep 2004 01:26:32 -0000 Received: (qmail 34068 invoked from network); 6 Sep 2004 01:29:57 -0000 Received: from unknown (HELO phobos.totalterror.net) (10.10.0.2) by tormentor.totalterror.net with SMTP; 6 Sep 2004 01:29:57 -0000 Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Niki Denev To: current@freebsd.org Date: Mon, 06 Sep 2004 04:26:36 +0300 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-phobos.totalterror.net-688-1094433996-0001"; micalg=pgp-sha1; protocol="application/pgp-signature" Subject: disklabel: Geom not found 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, 06 Sep 2004 01:26:35 -0000 This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-phobos.totalterror.net-688-1094433996-0001 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit so... everyting started when i bought that damn USB Floppy, and tried to make a bootable diskette in the middle of the night, and of course i've mistyped fdisk/disklabel 'da0' with 'ad0', wiping out the disklabel. This happened on my laptop running -current. Hopefully i had a machine with 5.2-release next to me, so i removed the laptop HDD and attached it to it. Thanks to scan_ffs i was able to restore the disklabel, but i've made a typo entering the size of the 'c'(raw) partition. Disklabel complained that the c part. doesn't cover the whole device, but in the hurry i forgot about this, and attached the disk again to the laptop. It booted normaly and everyting was ok, and then i decided to fix the c partition size. I dumped the disklabel in text file, edited the c part to the proper size and when i tried to write it back, disklabel printed out this message : "disklabel: Geom not found" and didn't update the label. This happened on the laptop running -current, so i suppose this has something to do with the geom-ification in current :) but i don't have idea how to fix it? any suggestions? Thanks in advance, Niki --=_mimegpg-phobos.totalterror.net-688-1094433996-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBO7zNHNAJ/fLbfrkRAgXgAKCJs4SrsfR0XK4NlX0Km02RgfzwewCgoo9z HhRo5411tzOVnbHACUoVrrI= =tlQ4 -----END PGP SIGNATURE----- --=_mimegpg-phobos.totalterror.net-688-1094433996-0001-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 01:33: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 2DDB716A4CF for ; Mon, 6 Sep 2004 01:33:45 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E74D43D2D for ; Mon, 6 Sep 2004 01:33:44 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i861Xafc035069; Sun, 5 Sep 2004 18:33:41 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409060133.i861Xafc035069@gw.catspoiler.org> Date: Sun, 5 Sep 2004 18:33:36 -0700 (PDT) From: Don Lewis To: Giorgos Keramidas In-Reply-To: <200409041920.i84JKTKw032364@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? 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, 06 Sep 2004 01:33:46 -0000 On 4 Sep, To: scrappy@hub.org wrote: > On 4 Sep, Don Lewis wrote: >> On 4 Sep, Marc G. Fournier wrote: >>> On Fri, 3 Sep 2004, Don Lewis wrote: >> >>>> Would the file system in question happen to be full of UNREF files that >>>> fsck is deleting? >>> >>> mostly 'ZERO LENGTH DIRECTORY' ... >> >> I'm pretty sure that I understand the problem now. During pass 4, fsck >> looks at each inode. It checks each inode in the FSTATE and DFOUND >> states to see if their link counts need to be adjusted. If the link >> count does not need to be adjusted, fsck checks to see if the inode is >> on the list of inodes whose initial link counts were zero, and if it >> finds the inode on this list, it clears the inode. >> >> The problem is that the zero length directories get added to this list >> if their initial link count is zero, and they also don't get removed >> from the list because they are in the DCLEAR state, so the list doesn't >> shrink. This bloats the list, which greatly slows down processing of >> normal files and directories. >> >> Deleting unreferenced files is not the biggest bottleneck, so reversing >> the order of the list isn't going to help much. Probably the biggest >> speedup could be gained by keeping the zero length directories off the >> list. > > An even better solution would be to dispense with the zln list entirely > and just set a bit for these inodes in their struct inostat. This > change is a bit more intrusive because of the need for some sort of > packing strategy because of the need to keep this structure small. My > initial inclination would be to add two new states, FZERO and DZERO, > that pass1() would use to mark inodes with a zero link count. Here's a patch that eliminates the zln list and adds two new inode states to tag zero files and directories that have a zero link count. It seems to work in the light testing that I have done, but it needs further and review before it gets committed. Index: sbin/fsck_ffs/dir.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/dir.c,v retrieving revision 1.29 diff -u -r1.29 dir.c --- sbin/fsck_ffs/dir.c 1 Sep 2004 05:48:06 -0000 1.29 +++ sbin/fsck_ffs/dir.c 5 Sep 2004 21:20:56 -0000 @@ -90,7 +90,8 @@ if (inp->i_parent == 0) continue; if (inoinfo(inp->i_parent)->ino_state == DFOUND && - inoinfo(inp->i_number)->ino_state == DSTATE) { + (inoinfo(inp->i_number)->ino_state == DSTATE || + inoinfo(inp->i_number)->ino_state == DZLINK)) { inoinfo(inp->i_number)->ino_state = DFOUND; change++; } @@ -640,7 +641,8 @@ return(ino); } if (inoinfo(parent)->ino_state != DSTATE && - inoinfo(parent)->ino_state != DFOUND) { + inoinfo(parent)->ino_state != DFOUND && + inoinfo(parent)->ino_state != DZLINK) { freeino(ino); return (0); } Index: sbin/fsck_ffs/fsck.h =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v retrieving revision 1.32 diff -u -r1.32 fsck.h --- sbin/fsck_ffs/fsck.h 1 Sep 2004 05:48:06 -0000 1.32 +++ sbin/fsck_ffs/fsck.h 6 Sep 2004 00:41:31 -0000 @@ -84,6 +84,8 @@ #define DFOUND 04 /* directory found during descent */ #define DCLEAR 05 /* directory is to be cleared */ #define FCLEAR 06 /* file is to be cleared */ +#define FZLINK 07 /* inode is file with a link count of zero */ +#define DZLINK 10 /* inode is directory with a zero link count */ /* * Inode state information is contained on per cylinder group lists * which are described by the following structure. @@ -205,15 +207,6 @@ struct dups *muldup; /* end of unique duplicate dup block numbers */ /* - * Linked list of inodes with zero link counts. - */ -struct zlncnt { - struct zlncnt *next; - ino_t zlncnt; -}; -struct zlncnt *zlnhead; /* head of zero link count list */ - -/* * Inode cache data structures. */ struct inoinfo { Index: sbin/fsck_ffs/fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.24 diff -u -r1.24 fsutil.c --- sbin/fsck_ffs/fsutil.c 18 May 2004 19:51:41 -0000 1.24 +++ sbin/fsck_ffs/fsutil.c 5 Sep 2004 21:24:41 -0000 @@ -525,7 +525,8 @@ } if (busy || (inoinfo(curdir)->ino_state != DSTATE && - inoinfo(curdir)->ino_state != DFOUND)) { + inoinfo(curdir)->ino_state != DFOUND && + inoinfo(curdir)->ino_state != DZLINK)) { (void)strcpy(namebuf, "?"); return; } Index: sbin/fsck_ffs/inode.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/inode.c,v retrieving revision 1.36 diff -u -r1.36 inode.c --- sbin/fsck_ffs/inode.c 1 Sep 2004 05:48:06 -0000 1.36 +++ sbin/fsck_ffs/inode.c 5 Sep 2004 21:25:36 -0000 @@ -576,10 +576,12 @@ switch (inoinfo(ino)->ino_state) { case FSTATE: + case FZLINK: inoinfo(ino)->ino_state = FCLEAR; return; case DSTATE: + case DZLINK: inoinfo(ino)->ino_state = DCLEAR; return; Index: sbin/fsck_ffs/main.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/main.c,v retrieving revision 1.41 diff -u -r1.41 main.c --- sbin/fsck_ffs/main.c 9 Apr 2004 19:58:28 -0000 1.41 +++ sbin/fsck_ffs/main.c 6 Sep 2004 00:41:47 -0000 @@ -194,7 +194,6 @@ struct ufs_args args; struct dups *dp; struct statfs *mntp; - struct zlncnt *zlnp; struct stat snapdir; struct group *grp; ufs2_daddr_t blks; @@ -424,14 +423,7 @@ printf(" %lld,", (long long)dp->dup); printf("\n"); } - if (zlnhead != NULL) { - printf("The following zero link count inodes remain:"); - for (zlnp = zlnhead; zlnp; zlnp = zlnp->next) - printf(" %u,", zlnp->zlncnt); - printf("\n"); - } } - zlnhead = (struct zlncnt *)0; duplist = (struct dups *)0; muldup = (struct dups *)0; inocleanup(); Index: sbin/fsck_ffs/pass1.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v retrieving revision 1.42 diff -u -r1.42 pass1.c --- sbin/fsck_ffs/pass1.c 1 Sep 2004 05:48:06 -0000 1.42 +++ sbin/fsck_ffs/pass1.c 6 Sep 2004 00:42:11 -0000 @@ -189,7 +189,6 @@ checkinode(ino_t inumber, struct inodesc *idesc) { union dinode *dp; - struct zlncnt *zlnp; off_t kernmaxfilesize; ufs2_daddr_t ndb; mode_t mode; @@ -302,28 +301,18 @@ goto unknown; n_files++; inoinfo(inumber)->ino_linkcnt = DIP(dp, di_nlink); - if (DIP(dp, di_nlink) <= 0) { - zlnp = (struct zlncnt *)malloc(sizeof *zlnp); - if (zlnp == NULL) { - pfatal("LINK COUNT TABLE OVERFLOW"); - if (reply("CONTINUE") == 0) { - ckfini(0); - exit(EEXIT); - } - } else { - zlnp->zlncnt = inumber; - zlnp->next = zlnhead; - zlnhead = zlnp; - } - } if (mode == IFDIR) { if (DIP(dp, di_size) == 0) inoinfo(inumber)->ino_state = DCLEAR; + else if (DIP(dp, di_nlink) <= 0) + inoinfo(inumber)->ino_state = DZLINK; else inoinfo(inumber)->ino_state = DSTATE; cacheino(dp, inumber); countdirs++; - } else + } else if (DIP(dp, di_nlink) <= 0) + inoinfo(inumber)->ino_state = FZLINK; + else inoinfo(inumber)->ino_state = FSTATE; inoinfo(inumber)->ino_type = IFTODT(mode); badblk = dupblk = 0; Index: sbin/fsck_ffs/pass2.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass2.c,v retrieving revision 1.25 diff -u -r1.25 pass2.c --- sbin/fsck_ffs/pass2.c 1 Sep 2004 05:48:06 -0000 1.25 +++ sbin/fsck_ffs/pass2.c 5 Sep 2004 21:36:06 -0000 @@ -91,6 +91,7 @@ case FSTATE: case FCLEAR: + case FZLINK: pfatal("ROOT INODE NOT DIRECTORY"); if (reply("REALLOCATE")) { freeino(ROOTINO); @@ -109,6 +110,7 @@ break; case DSTATE: + case DZLINK: break; default: @@ -196,7 +198,8 @@ if (inp->i_parent == 0 || inp->i_isize == 0) continue; if (inoinfo(inp->i_parent)->ino_state == DFOUND && - inoinfo(inp->i_number)->ino_state == DSTATE) + (inoinfo(inp->i_number)->ino_state == DSTATE || + inoinfo(inp->i_number)->ino_state == DZLINK)) inoinfo(inp->i_number)->ino_state = DFOUND; if (inp->i_dotdot == inp->i_parent || inp->i_dotdot == (ino_t)-1) @@ -405,6 +408,7 @@ goto again; case DSTATE: + case DZLINK: if (inoinfo(idesc->id_number)->ino_state == DFOUND) inoinfo(dirp->d_ino)->ino_state = DFOUND; /* FALLTHROUGH */ @@ -435,6 +439,7 @@ /* FALLTHROUGH */ case FSTATE: + case FZLINK: if (dirp->d_type != inoinfo(dirp->d_ino)->ino_type) { fileerror(idesc->id_number, dirp->d_ino, "BAD TYPE VALUE"); Index: sbin/fsck_ffs/pass3.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass3.c,v retrieving revision 1.14 diff -u -r1.14 pass3.c --- sbin/fsck_ffs/pass3.c 9 Apr 2004 19:58:28 -0000 1.14 +++ sbin/fsck_ffs/pass3.c 6 Sep 2004 00:25:50 -0000 @@ -69,7 +69,7 @@ inp = inpsort[inpindex]; state = inoinfo(inp->i_number)->ino_state; if (inp->i_number == ROOTINO || - (inp->i_parent != 0 && state != DSTATE)) + (inp->i_parent != 0 && state != DSTATE && state != DZLINK)) continue; if (state == DCLEAR) continue; @@ -80,7 +80,8 @@ * in pass 4. */ if ((preen || bkgrdflag) && - resolved && usedsoftdep && state == DSTATE) { + resolved && usedsoftdep && (state == DSTATE || + state == DZLINK)) { if (inp->i_dotdot >= ROOTINO) inoinfo(inp->i_dotdot)->ino_linkcnt++; continue; @@ -88,7 +89,8 @@ for (loopcnt = 0; ; loopcnt++) { orphan = inp->i_number; if (inp->i_parent == 0 || - inoinfo(inp->i_parent)->ino_state != DSTATE || + (inoinfo(inp->i_parent)->ino_state != DSTATE && + inoinfo(inp->i_parent)->ino_state != DZLINK) || loopcnt > countdirs) break; inp = getinoinfo(inp->i_parent); Index: sbin/fsck_ffs/pass4.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass4.c,v retrieving revision 1.14 diff -u -r1.14 pass4.c --- sbin/fsck_ffs/pass4.c 9 Apr 2004 19:58:28 -0000 1.14 +++ sbin/fsck_ffs/pass4.c 6 Sep 2004 00:41:55 -0000 @@ -49,7 +49,6 @@ pass4(void) { ino_t inumber; - struct zlncnt *zlnp; union dinode *dp; struct inodesc idesc; int i, n, cg; @@ -76,6 +75,14 @@ idesc.id_number = inumber; switch (inoinfo(inumber)->ino_state) { + case FZLINK: + case DZLINK: + if (inoinfo(inumber)->ino_linkcnt == 0) { + clri(&idesc, "UNREF", 1); + break; + } + /* fall through */ + case FSTATE: case DFOUND: n = inoinfo(inumber)->ino_linkcnt; @@ -83,16 +90,6 @@ adjust(&idesc, (short)n); break; } - for (zlnp = zlnhead; zlnp; zlnp = zlnp->next) { - if (zlnp->zlncnt == inumber) { - zlnp->zlncnt = zlnhead->zlncnt; - zlnp = zlnhead; - zlnhead = zlnhead->next; - free((char *)zlnp); - clri(&idesc, "UNREF", 1); - break; - } - } break; case DSTATE: Index: sbin/fsck_ffs/pass5.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/pass5.c,v retrieving revision 1.39 diff -u -r1.39 pass5.c --- sbin/fsck_ffs/pass5.c 9 Apr 2004 19:58:28 -0000 1.39 +++ sbin/fsck_ffs/pass5.c 6 Sep 2004 00:34:10 -0000 @@ -216,11 +216,13 @@ case DSTATE: case DCLEAR: case DFOUND: + case DZLINK: newcg->cg_cs.cs_ndir++; /* FALLTHROUGH */ case FSTATE: case FCLEAR: + case FZLINK: newcg->cg_cs.cs_nifree--; setbit(cg_inosused(newcg), i); break; From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 02:00: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 A81FD16A4D0; Mon, 6 Sep 2004 02:00:04 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC1943D46; Mon, 6 Sep 2004 02:00:03 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i861xi4Y011681; Mon, 6 Sep 2004 11:29:48 +0930 (CST) Received: from inchoate.gsoft.com.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i861xdn7092996; Mon, 6 Sep 2004 11:29:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Duncan Barclay Date: Mon, 6 Sep 2004 11:29:30 +0930 User-Agent: KMail/1.7 References: <200408301121.22260.doconnor@gsoft.com.au> <200408311253.50651.doconnor@gsoft.com.au> <413B6A09.2020803@dmlb.org> In-Reply-To: <413B6A09.2020803@dmlb.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3155121.Pfq12Bp9n9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409061129.37036.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org cc: dmlb@freebsd.org Subject: Re: bfe crash with profile.sh 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, 06 Sep 2004 02:00:04 -0000 --nextPart3155121.Pfq12Bp9n9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 6 Sep 2004 05:03, Duncan Barclay wrote: > I can't find this at the address above. Sorry, I removed it after Doug fetched it as it had sensitive info. > Can you also send me the output of dmesg -a, and also the typescript > from successfully using profile.sh to change the profile of the machine > without rebooting under a script(1) session? The profile.sh tools does > some odd hackery and the bug may not be in the bfe driver. The stack trace turned out to be worthless so I've upgraded to 6-current in= =20 the meantime and will try it again. I'll let you know how it goes. =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 --nextPart3155121.Pfq12Bp9n9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBO8SI5ZPcIHs/zowRAhB2AJ0Z4ZuwcdgyNSHjGbIfit6YVfuUQQCfUapi V6JOcJrWByOU9TZ/LznWf2Q= =RCpi -----END PGP SIGNATURE----- --nextPart3155121.Pfq12Bp9n9-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 02:43: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 AFC8E16A4CE for ; Mon, 6 Sep 2004 02:43:40 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC0543D3F for ; Mon, 6 Sep 2004 02:43:39 +0000 (GMT) (envelope-from root@gits.dyndns.org) Received: from mail.gits.dyndns.org (20-241-118-80.kaptech.net [80.118.241.20]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 2A1C514B749; Mon, 6 Sep 2004 04:58:17 +0200 (CEST) Posted-Date: Mon, 6 Sep 2004 04:39:38 +0200 (CEST) X-Envelope-To: saw@online.de Received: from mail.gits.dyndns.org (IDENT:dxtplb68tcswjz15@localhost [127.0.0.1])i862dc56006072; Mon, 6 Sep 2004 04:39:54 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by mail.gits.dyndns.org (8.13.1/8.12.11/Submit) id i84Nc7Ul016102; Sun, 5 Sep 2004 01:38:07 +0200 (CEST) (envelope-from root) Message-Id: <200409042338.i84Nc7Ul016102@mail.gits.dyndns.org> In-Reply-To: <41381898.6040706@erpicon.de> To: saw@online.de Date: Sun, 5 Sep 2004 01:38:07 +0200 (CEST) From: Cyrille Lefevre X-Face: V|+c;4!|B?E%BE^{E6); aI.[< cc: Deng XueFeng Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cyrille.lefevre@laposte.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 02:43:40 -0000 --ELM1094341086-27608-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On Sep 3, 2004 09:09:12 am +0200, Sascha Wildner wrote: > Cyrille Lefevre wrote: > > > I have tested this patch also, it seems to work well, > > except that mouse in graphic mode ! it doesn't appear... > > since I have local modifications, I'll get rid of them > > and restart from scratch. PS : by scratch, I mean, no mods, your mods, then mines :) there are two more problems : - vidcontrol 132x60 doesn't work anymore, I've to say : vidcontrol MODE_268 - mutt doesn't display anything in any modes. > Do you mean the mouse pointer is not visible? If so, have you tried > 'vidcontrol -m on'? Is moused running? yes, moused is running and the mouse is ok on other text virtual terminals. > If the problem persists after removing your local modifications, I'd > like to know in which mode this happens. Please also attach the output as far as I remember me, I've tried some graphic modes like 800x600, 1024x768 and 1280x1024. as I said before, wait 'til monday :) > of 'vidcontrol -i mode' and the dmesg of a verbose boot (boot -v). see attachments (for instance, dmesg isn't in verbose mode, but I will on monday). PS : my fdc controller seems to be dead ! so, don't care :( Cyrille Lefevre -- mailto:cyrille.lefevre@laposte.net --ELM1094341086-27608-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Disposition: attachment; filename=vidcontrol.txt Content-Description: mode# flags type size font window linear buffer ------------------------------------------------------------------------------ 0 (0x000) 0x00000001 T 40x25 8x8 0xb8000 32k 32k 0x00000000 32k 1 (0x001) 0x00000001 T 40x25 8x8 0xb8000 32k 32k 0x00000000 32k 2 (0x002) 0x00000001 T 80x25 8x8 0xb8000 32k 32k 0x00000000 32k 3 (0x003) 0x00000001 T 80x25 8x8 0xb8000 32k 32k 0x00000000 32k 4 (0x004) 0x00000003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x00000000 32k 5 (0x005) 0x00000003 G 320x200x2 1 8x8 0xb8000 32k 32k 0x00000000 32k 6 (0x006) 0x00000003 G 640x200x1 1 8x8 0xb8000 32k 32k 0x00000000 32k 13 (0x00d) 0x00000003 G 320x200x4 4 8x8 0xa0000 64k 64k 0x00000000 256k 14 (0x00e) 0x00000003 G 640x200x4 4 8x8 0xa0000 64k 64k 0x00000000 256k 16 (0x010) 0x00000003 G 640x350x2 2 8x14 0xa0000 64k 64k 0x00000000 128k 18 (0x012) 0x00000003 G 640x350x4 4 8x14 0xa0000 64k 64k 0x00000000 256k 19 (0x013) 0x00000001 T 40x25 8x14 0xb8000 32k 32k 0x00000000 32k 20 (0x014) 0x00000001 T 40x25 8x14 0xb8000 32k 32k 0x00000000 32k 21 (0x015) 0x00000001 T 80x25 8x14 0xb8000 32k 32k 0x00000000 32k 22 (0x016) 0x00000001 T 80x25 8x14 0xb8000 32k 32k 0x00000000 32k 23 (0x017) 0x00000001 T 40x25 8x16 0xb8000 32k 32k 0x00000000 32k 24 (0x018) 0x00000001 T 80x25 8x16 0xb8000 32k 32k 0x00000000 32k 26 (0x01a) 0x00000003 G 640x480x4 4 8x16 0xa0000 64k 64k 0x00000000 256k 27 (0x01b) 0x00000003 G 640x480x4 4 8x16 0xa0000 64k 64k 0x00000000 256k 28 (0x01c) 0x00000003 G 320x200x8 1 8x8 0xa0000 64k 64k 0x00000000 64k 30 (0x01e) 0x00000001 T 80x50 8x8 0xb8000 32k 32k 0x00000000 32k 32 (0x020) 0x00000001 T 80x30 8x16 0xb8000 32k 32k 0x00000000 32k 34 (0x022) 0x00000001 T 80x60 8x8 0xb8000 32k 32k 0x00000000 32k 37 (0x025) 0x00000003 G 320x240x8 4 8x8 0xa0000 64k 64k 0x00000000 256k 112 (0x070) 0x00000000 T 80x43 8x8 0xb8000 32k 32k 0x00000000 32k 113 (0x071) 0x00000001 T 80x43 8x8 0xb8000 32k 32k 0x00000000 32k 256 (0x100) 0x0000000f G 640x400x8 1 8x16 0xa0000 64k 64k 0xff000000 4096k 257 (0x101) 0x0000000f G 640x480x8 1 8x16 0xa0000 64k 64k 0xff000000 4096k 258 (0x102) 0x0000000b G 800x600x4 4 8x14 0xa0000 64k 64k 0x00000000 4096k 259 (0x103) 0x0000000f G 800x600x8 1 8x16 0xa0000 64k 64k 0xff000000 4096k 261 (0x105) 0x0000000f G 1024x768x8 1 8x16 0xa0000 64k 64k 0xff000000 4096k 263 (0x107) 0x0000000f G 1280x1024x8 1 8x16 0xa0000 64k 64k 0xff000000 4096k 264 (0x108) 0x00000009 T 80x60 8x8 0xb8000 32k 32k 0x00000000 4096k 265 (0x109) 0x00000009 T 132x25 8x16 0xb8000 32k 32k 0x00000000 4096k 266 (0x10a) 0x00000009 T 132x43 8x8 0xb8000 32k 32k 0x00000000 4096k 267 (0x10b) 0x00000009 T 132x50 8x8 0xb8000 32k 32k 0x00000000 4096k 268 (0x10c) 0x00000009 T 132x60 8x8 0xb8000 32k 32k 0x00000000 4096k 272 (0x110) 0x0000000f G 640x480x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 273 (0x111) 0x0000000f G 640x480x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 274 (0x112) 0x0000000f G 640x480x32 1 8x16 0xa0000 64k 64k 0xff000000 4096k 275 (0x113) 0x0000000f G 800x600x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 276 (0x114) 0x0000000f G 800x600x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 277 (0x115) 0x0000000f G 800x600x32 1 8x16 0xa0000 64k 64k 0xff000000 4096k 278 (0x116) 0x0000000f G 1024x768x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 279 (0x117) 0x0000000f G 1024x768x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 280 (0x118) 0x0000000f G 1024x768x32 1 8x16 0xa0000 64k 64k 0xff000000 4096k 281 (0x119) 0x0000000f G 1280x1024x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 282 (0x11a) 0x0000000f G 1280x1024x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 284 (0x11c) 0x0000000f G 1600x1200x8 1 8x16 0xa0000 64k 64k 0xff000000 4096k 285 (0x11d) 0x0000000f G 1600x1200x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k 286 (0x11e) 0x0000000f G 1600x1200x16 1 8x16 0xa0000 64k 64k 0xff000000 4096k --ELM1094341086-27608-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Disposition: attachment; filename=dmesg.txt Content-Description: 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 #6: Thu Sep 2 02:04:23 CEST 2004 root@gits:/disk1/freebsd/current/obj/disk3/freebsd/current/src/sys/CUSTOM can't re-use a leaf (nsfbufs)! Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (198.95-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 134217728 (128 MB) avail memory = 121720832 (116 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 13.0 (no driver attached) pci0: at device 14.0 (no driver attached) ahc0: port 0xf800-0xf8ff mem 0xffbea000-0xffbeafff irq 11 at device 15.0 on pci0 ahc0: [GIANT-LOCKED] aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 9 at device 16.0 on pci0 ahc1: [GIANT-LOCKED] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs cpu0 on motherboard pmtimer0 on isa0 orm0: at iomem 0xed000-0xedfff,0xc8000-0xcd7ff,0xc0000-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 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 fdc0: ic_type 90 part_id 73 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 device_attach: fdc0 attach returned 2 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <8 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x20010 on isa0 sio0: type ST16650A sio1 at port 0x2f8-0x2ff irq 3 flags 0x20000 on isa0 sio1: type ST16650A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 speaker0: at port 0x61 on isa0 unknown: can't assign resources (port) unknown: can't assign resources (irq) ahc2: No resources alloated. fdc1: cannot reserve I/O port range (6 ports) ahc2: No resources alloated. ppc1: parallel port not found. unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ad0: 9543MB [19390/16/63] at ata0-master BIOSPIO ad1: 39082MB [79406/16/63] at ata0-slave BIOSPIO ad2: 9543MB [19390/16/63] at ata1-master BIOSPIO ad3: 19531MB [39683/16/63] at ata1-slave BIOSPIO WARNING: Expected rawoffset 6506325, found 13012713 Waiting 5 seconds for SCSI devices to settle da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2048MB (4194685 512 byte sectors: 255H 63S/T 261C) da1 at ahc1 bus 0 target 8 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8678MB (17773524 512 byte sectors: 255H 63S/T 1106C) da2 at ahc1 bus 0 target 9 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8678MB (17773524 512 byte sectors: 255H 63S/T 1106C) cd0 at ahc0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Mounting root from ufs:/dev/da0s1a xl0: <3Com 3c905B-COMBO Fast Etherlink XL> port 0xf480-0xf4ff mem 0xffbe9c00-0xffbe9c7f irq 11 at device 13.0 on pci0 xl0: Ethernet address: 00:01:02:e0:2d:61 xl0: [GIANT-LOCKED] miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Accounting enabled fdc0: cannot reserve I/O port range (6 ports) ppc0: parallel port not found. sbc0: at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 3,1 on isa0 sbc0: [GIANT-LOCKED] fdc1: cannot reserve I/O port range (6 ports) ahc2: No resources alloated. ppc1: parallel port not found. pcm0: on sbc0 pcm0: [GIANT-LOCKED] lrexec current loaded. Connection attempt to TCP 192.168.144.96:113 from 195.20.104.108:44806 flags:0xc2 wakeup from sleeping state (slept 00:00:05) --ELM1094341086-27608-0_-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 02:50: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 D72F816A4CE for ; Mon, 6 Sep 2004 02:50:49 +0000 (GMT) Received: from web21427.mail.yahoo.com (web21427.mail.yahoo.com [216.136.232.46]) by mx1.FreeBSD.org (Postfix) with SMTP id B771E43D41 for ; Mon, 6 Sep 2004 02:50:49 +0000 (GMT) (envelope-from mjacob44@yahoo.com) Message-ID: <20040906025049.77937.qmail@web21427.mail.yahoo.com> Received: from [192.67.166.1] by web21427.mail.yahoo.com via HTTP; Sun, 05 Sep 2004 19:50:49 PDT Date: Sun, 5 Sep 2004 19:50:49 -0700 (PDT) From: Matthew Jacob To: "Simon L. Nielsen" , freebsd-current@freebsd.org In-Reply-To: <20040905214943.GA759@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Jonathan Lemon cc: tackerman@FreeBSD.org cc: pdeuskar@FreeBSD.org Subject: Re: Deprication of the gx(4) driver - superseded by em(4) ? 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, 06 Sep 2004 02:50:50 -0000 "deprecation" yes, and the wx was deprecated as well. This whole situation stinks a bit. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 02: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 D4C1616A4CE for ; Mon, 6 Sep 2004 02:57:46 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC3A43D55 for ; Mon, 6 Sep 2004 02:57:46 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from focus.dantavious.com (pcp04630633pcs.gambrl01.md.comcast.net[68.49.58.89]) by comcast.net (rwcrmhc11) with ESMTP id <2004090602574601300ao1fie> (Authid: dantavious); Mon, 6 Sep 2004 02:57:46 +0000 From: Derrick Edwards To: freebsd-current@freebsd.org Date: Sun, 5 Sep 2004 23:07:16 -0400 User-Agent: KMail/1.7 References: <4139D650.9030506@pldrouin.net> <20040905190340.GC39255@abigail.blackend.org> <20040905193154.GD19729@cnd.mcgill.ca> In-Reply-To: <20040905193154.GD19729@cnd.mcgill.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409052307.16534.dantavious@comcast.net> Subject: Re: device pcm 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, 06 Sep 2004 02:57:46 -0000 On Sunday 05 September 2004 03:31 pm, Mathew Kanner wrote: Well guys still having probs with sound. I have tried all recommendtions. This is the outpit of my /dev/sndstat cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xc000, 0xc400 irq 17 bufsz 16384 (1p/1r/0v channels duplex default) Keep in mind that I do have snd_driver loaded in /boot/loader.conf even snd_ich for overkill Output of loader.conf nvidia_load="YES" hw.ata.atapi_dma="1" linux_load="YES" snd_driver_load="YES" snd_ich_load="YES" Can anyone explain why i do not have a driver associated with card in /dev/sndstat. Also, every one out of 50 reboots, I will get sound for 2 seconds then it dies. This is my pciconfig pcm0@pci0:31:5: class=0x040100 card=0x4941434d chip=0x24c58086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller' class = multimedia subclass = audio Thanks for the assistance Derrick > On Sep 05, Marc Fonvieille wrote: > > On Sun, Sep 05, 2004 at 03:05:32PM -0400, Mathew Kanner wrote: > > > Could you add that the easiest way to configure you sound in 5.X+ > > > is to: > > > > > > tube# kldload snd_driver > > > tube# cat /dev/sndstat > > > FreeBSD Audio Driver (newpcm) > > > Installed devices: > > > pcm0: at io 0xb800 irq 11 kld snd_cmi (1p/1r/0v > > > channels duplex default) pcm1: at io 0xb400 irq 5 > > > kld snd_emu10k1 (4p/2r/0v channels duplex) > > > > > > for each kld snd_foo > > > echo snd_foo_load="YES" >> /boot/loader.conf > > > > > > This method works because snd_driver is just dummy module that > > > loads all[1] the sound modules. (Oops, just noticed I missed uaudio). > > > Also, KLDs are the preferred method for sound usage and that ISA > > > cards likely won't need a hint (PNP). > > > > > > --Mat > > > [1] It only loads the sounds modules that it knew about at compile > > > time. Some sound modules are provided "third party" such as in the > > > ports, such modules will be missed by this method and will have to be > > > specifically loaded. > > > > You did not read the link :( > > Ok, other than you already have a section on PNP what did I > miss? > --Mat From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 04:09: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 7144916A4CE; Mon, 6 Sep 2004 04:09:05 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D13A43D46; Mon, 6 Sep 2004 04:09:05 +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 i864948b015947; Mon, 6 Sep 2004 00:09:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i86494ji019471; Mon, 6 Sep 2004 00:09:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6E0287303F; Mon, 6 Sep 2004 00:09:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040906040904.6E0287303F@freebsd-current.sentex.ca> Date: Mon, 6 Sep 2004 00:09:04 -0400 (EDT) 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: Mon, 06 Sep 2004 04:09:05 -0000 TB --- 2004-09-06 02:40:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-06 02:40:38 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-09-06 02:40:38 - checking out the source tree TB --- 2004-09-06 02:40:38 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-09-06 02:40:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-06 02:45:31 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-06 02:45:31 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-06 02:45:31 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/main.c cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/perform.c cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -o pkg_version main.o perform.o /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/../lib/libinstall.a -lfetch -lmd -lssl -lcrypto gzip -cn /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/pkg_install/version/pkg_version.1 > pkg_version.1.gz ===> usr.sbin/ppp cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp/acf.c /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp/acf.c: In function `acf_LayerPull': /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp/acf.c:76: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-09-06 04:09:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-06 04:09:04 - ERROR: failed to build world TB --- 2004-09-06 04:09:04 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:09: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 BC22C16A4CE; Mon, 6 Sep 2004 05:09:35 +0000 (GMT) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C26D343D4C; Mon, 6 Sep 2004 05:09:34 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1C4Blp-0008Gh-0M; Mon, 06 Sep 2004 09:10:25 +0400 Date: Mon, 6 Sep 2004 09:10:25 +0400 From: "Boris B. Samorodov" To: Andre Oppermann Message-ID: <20040906051024.GA31706@ipt.ru> References: <413B9A36.2D0B9696@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413B9A36.2D0B9696@freebsd.org> Sender: "Boris B. Samorodov" cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12 in kernel module uipc_mbuf2.c 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, 06 Sep 2004 05:09:35 -0000 On Mon, Sep 06, 2004 at 12:59:02AM +0200, Andre Oppermann wrote: > > Does it panic 'reliablily' in the same place or is it more of a random > occurence? I'm not long in the office tomorrow (my test machine is there) > but I'll try to reproduce it within the next few days. Yes. It panics 'reliably'. Here is the console message. ----- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc0e6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc053a1f0 stack pointer = 0x10:0xc7fcb8e8 frame pointer = 0x10:0xc7fcb8f0 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 = 37 (swi1: net) [thread 100038] Stopped at m_tag_locate+0x40: cmpl %ecx,0x8(%edx) ----- > Andre WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:24: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 CB9D916A4CE for ; Mon, 6 Sep 2004 05:24:56 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C56843D53 for ; Mon, 6 Sep 2004 05:24:56 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i865OmhV035339; Sun, 5 Sep 2004 22:24:52 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409060524.i865OmhV035339@gw.catspoiler.org> Date: Sun, 5 Sep 2004 22:24:48 -0700 (PDT) From: Don Lewis To: keramida@hellug.gr In-Reply-To: <20040906051526.GA8925@igloo.linux.gr> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? 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, 06 Sep 2004 05:24:56 -0000 On 6 Sep, Giorgos Keramidas wrote: > On 2004-09-05 18:33, Don Lewis wrote: >> Index: sbin/fsck_ffs/fsck.h >> =================================================================== >> RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v >> retrieving revision 1.32 >> diff -u -r1.32 fsck.h >> --- sbin/fsck_ffs/fsck.h 1 Sep 2004 05:48:06 -0000 1.32 >> +++ sbin/fsck_ffs/fsck.h 6 Sep 2004 00:41:31 -0000 >> @@ -84,6 +84,8 @@ >> #define DFOUND 04 /* directory found during descent */ >> #define DCLEAR 05 /* directory is to be cleared */ >> #define FCLEAR 06 /* file is to be cleared */ >> +#define FZLINK 07 /* inode is file with a link count of zero */ >> +#define DZLINK 10 /* inode is directory with a zero link count */ > > Just a minor note: > > 04, 05, 06, 07, are octals. > I think DZLINK should be 010 and not 10 (which is decimal). Yup. Someone else sent me a private message about this. From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:37: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 60C8716A4CE; Mon, 6 Sep 2004 05:37:37 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7159843D55; Mon, 6 Sep 2004 05:37:36 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i865O8jr023622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Sep 2004 01:24:09 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Brian Fundakowski Feldman Date: Mon, 6 Sep 2004 01:39:31 -0400 User-Agent: KMail/1.6.2 References: <200407271731.12282.mistry.7@osu.edu> <200409051315.25263.mistry.7@osu.edu> <20040905214625.GA952@green.homeunix.org> In-Reply-To: <20040905214625.GA952@green.homeunix.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_bg/OBch9/Cld1Au"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409060139.39036.mistry.7@osu.edu> X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_42, PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap 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, 06 Sep 2004 05:37:37 -0000 --Boundary-02=_bg/OBch9/Cld1Au Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 05 September 2004 05:46 pm, you wrote: > On Sun, Sep 05, 2004 at 01:15:15PM -0400, Anish Mistry wrote: > > On Sunday 29 August 2004 12:59 am, you wrote: > > > On Tue, Aug 10, 2004 at 01:53:14PM -0400, Anish Mistry wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > On Wednesday 04 August 2004 06:39 pm, you wrote: > > > > > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > > > > > Ok, so we need something like vm_map_findspace(), but for proce= ss > > > > > > address mapping? ie. pmap_findspace() that will return an > > > > > > address to a large enough free chunk? > > > > > > > > > > That's a good start, just to get something to work with. How this > > > > > fits in with the vm code and whether it is ultimately suitable in > > > > > the long run is probably up to Alan Cox. For now, just get > > > > > something that (a) doesn't break anything else; and (b) lets Wine > > > > > behave the way it needs to. > > > > > > > > > > AFAIK, there are still pthread issues with Wine, but those can't = be > > > > > addressed until the mmap issue has a work-around. > > > > > > > > I've got a small patch that gets by the initial problem about not > > > > being to mmap the memory for the libraries, but the addresses that > > > > are mmap'ed seem to seem to overlap with memory that the current > > > > pthread implementation want to mmap for the "red zone" when wine > > > > tries to create a thread. It can't mmap the "red zone" addresses > > > > since all those address mapping where gobbled up before the thread > > > > launched. > > > > I'll try to figure out a way to maybe leave a space for the "red > > > > zone" and see if that works. > > > > Someone who actually knows what they are doing should probably take= a > > > > look. > > > > > > The red pages are implemented by leaving the memory space unallocated; > > > I don't like that one bit -- this will cause those spaces to be > > > allocated but given no protection, which should provide the crash > > > feature that the guard pages are there for, but be less bogus (and it > > > doesn't use more "memory," but it will use a few more vm_map_entrys. > > > > > > Index: lib/libpthread/thread/thr_stack.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > RCS file: /usr/ncvs/src/lib/libpthread/thread/thr_stack.c,v > > > retrieving revision 1.8 > > > diff -u -r1.8 thr_stack.c > > > --- lib/libpthread/thread/thr_stack.c 14 Sep 2003 22:39:44 -0000 1.8 > > > +++ lib/libpthread/thread/thr_stack.c 29 Aug 2004 04:50:28 -0000 > > > @@ -214,6 +214,17 @@ > > > stacksize, PROT_READ | PROT_WRITE, MAP_STACK, > > > -1, 0)) =3D=3D MAP_FAILED) > > > attr->stackaddr_attr =3D NULL; > > > + if (attr->stackaddr_attr !=3D NULL) { > > > + void *red; > > > + > > > + red =3D mmap((char *)attr->stackaddr_attr + stacksize, > > > + _thr_guard_default, PROT_NONE, > > > + MAP_ANON | MAP_FIXED | MAP_PRIVATE, -1, 0); > > > + if (red =3D=3D MAP_FAILED) { > > > + (void)munmap(attr->stackaddr_attr, stacksize); > > > + attr->stackaddr_attr =3D NULL; > > > + } > > > + } > > > } > > > if (attr->stackaddr_attr !=3D NULL) > > > return (0); > > > > This is good. Can this be committed? > > Probably; can you verify it fixes the problem as you observe it? Hmmm...well I can't seem to reproduce this problem anymore with my latest=20 cvsup Saturday night, so I guess this doesn't need to be committed. =2D-=20 Anish Mistry --Boundary-02=_bg/OBch9/Cld1Au Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBO/gaxqA5ziudZT0RAoDrAJ9C0kZk2XJ/pDLeY/qNZCGPLQPOyQCfUhQd MR6t9mOqBmJmVEmn/oVL1ac= =hCG3 -----END PGP SIGNATURE----- --Boundary-02=_bg/OBch9/Cld1Au-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:43: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 1866D16A4CE for ; Mon, 6 Sep 2004 05:43:24 +0000 (GMT) Received: from mallard.zanker.org (mallard.zanker.org [217.169.19.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64AC343D48 for ; Mon, 6 Sep 2004 05:43:23 +0000 (GMT) (envelope-from mike@zanker.org) Received: from jemima.zanker.org ([217.169.19.67] ident=Mike) by mallard.zanker.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42) id 1C4CHf-0005SI-9d for freebsd-current@freebsd.org; Mon, 06 Sep 2004 06:43:19 +0100 Date: Mon, 06 Sep 2004 06:43:19 +0100 From: Mike Zanker To: freebsd-current@freebsd.org Message-ID: <7393CB5651ED271A2E9122F7@jemima.zanker.org> In-Reply-To: <200409060104.17383.michaelnottebrock@gmx.net> References: <200409040351.06438.michaelnottebrock@gmx.net> <20040904040928.GA11829@odin.ac.hmc.edu> <200409040641.58361.michaelnottebrock@gmx.net> <200409060104.17383.michaelnottebrock@gmx.net> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mallard-MailScanner: Found to be clean (of known viruses) X-Mallard-MailScanner-From: mike@zanker.org Subject: Re: Where did debug.acpi.disabled go? 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, 06 Sep 2004 05:43:24 -0000 On 06 September 2004 01:04 +0200 Michael Nottebrock wrote: >> fdc0: cmd 3 failed at out byte 1 of 3 >> device_attach: fdc0 attach returned 6 > > Just updated to 5.3-BETA3, no change. :-( Same problem here. Mike. From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:47: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 2276716A4CE; Mon, 6 Sep 2004 05:47:41 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4071843D5C; Mon, 6 Sep 2004 05:47:40 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i865Y5jr023638 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Sep 2004 01:34:06 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Gerald Pfeifer Date: Mon, 6 Sep 2004 01:49:35 -0400 User-Agent: KMail/1.6.2 References: <47158390.20040827112834@ulstu.ru> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_vp/OBGSiJ8HFpAB" Message-Id: <200409060149.35764.mistry.7@osu.edu> X-Spam-Status: No, hits=3.0 required=5.0 tests=IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, USER_AGENT_KMAIL,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Alan Cox cc: anvir@ulstu.ru cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap 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, 06 Sep 2004 05:47:41 -0000 --Boundary-00=_vp/OBGSiJ8HFpAB Content-Type: multipart/signed; charset="iso-8859-1"; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_vp/OB01aRadKGPG"; name=" " Content-Transfer-Encoding: 7bit --Boundary-02=_vp/OB01aRadKGPG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > [ John, sorry for the duplicate message; this is the correct one. ] > > On Fri, 27 Aug 2004, John Birrell wrote: > > Anish Mistry has developed a patch to choose an > > appropriate mmap address. He posted it to -current. I haven't had time = to > > test it. > > Thanks for the note. Will you have time to test/commit this before 5.3? > > Anish, do you have any news on this patch? (Wine has been broken for a > couple of months now, and it would be great to have at least 5.3 fixed.) > Well I guess this is my lucky day. Apply the attached patch for vm_mmap to= =20 your kernel and patch the August wine sources with the wine-mmap.patch and= =20 compile and install wine (be sure to use gmake). This is working on my dev= =20 system with 6-CURRENT as of Saturday night. The wine mmap patch just doesn't reserve the DOS area so DOS programs may n= ot=20 work. This seems to just work around a side effect of the kernel mmap patc= h. I still think that the kernel mmap patch has issues so I'm hoping Alan can= =20 give us some feedback. Anyway this worked for me, YMMV. =2D-=20 Anish Mistry --Boundary-02=_vp/OB01aRadKGPG Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBO/pvxqA5ziudZT0RAuEcAJ9KVTwau13wE0OiP+DoFV4t8a5p1gCghmKR OgmAA0fzj7wd6iqtezUw1gI= =VTFN -----END PGP SIGNATURE----- --Boundary-02=_vp/OB01aRadKGPG-- --Boundary-00=_vp/OBGSiJ8HFpAB Content-Type: text/x-diff; charset="iso-8859-1"; name="vm_mmap-wine-6-current.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap-wine-6-current.patch" --- vm_mmap.c.orig Thu Aug 5 03:04:33 2004 +++ vm_mmap.c Wed Aug 18 21:31:13 2004 @@ -208,6 +208,8 @@ vm_offset_t addr; vm_size_t size, pageoff; vm_prot_t prot, maxprot; + vm_map_t map; + void *handle; int flags, error; off_t pos; @@ -276,9 +278,26 @@ if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && addr < round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)))) + lim_max(td->td_proc, RLIMIT_DATA)))) { + /* + * XXX So much dirtyness someone who knows what they are doing + * will want to fix this monstrosity. + */ + map = &td->td_proc->p_vmspace->vm_map; + vm_map_lock(map); addr = round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)); + lim_max(td->td_proc, RLIMIT_DATA)); + if(vm_map_findspace(map, addr, size, &addr) != 0) { + /* + * since we can't grab the upper process address space bruteforce it. + */ + for(addr = 0;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + } + vm_map_unlock(map); + } + PROC_UNLOCK(td->td_proc); } if (flags & MAP_ANON) { --Boundary-00=_vp/OBGSiJ8HFpAB Content-Type: text/x-diff; charset="iso-8859-1"; name="wine-mmap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="wine-mmap.patch" --- libs/wine/mmap.c.orig Mon Sep 6 01:23:40 2004 +++ libs/wine/mmap.c Mon Sep 6 01:23:46 2004 @@ -294,7 +294,7 @@ area = LIST_ENTRY( ptr, struct reserved_area, entry ); if (!area->base) return; } - reserve_dos_area(); + /*reserve_dos_area();*/ } #else /* HAVE_MMAP */ --Boundary-00=_vp/OBGSiJ8HFpAB-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06:10: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 2CBFE16A4CE for ; Mon, 6 Sep 2004 06:10:22 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4337B43D69 for ; Mon, 6 Sep 2004 06:10:21 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (k8qqp5wv@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i866AJ4w019777; Mon, 6 Sep 2004 10:10:19 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 6 Sep 2004 10:10:19 +0400 (MSD) From: Maxim Konovalov To: Peter Jeremy In-Reply-To: <20040904080058.GV423@cirb503493.alcatel.com.au> Message-ID: <20040906100735.F19720@mp2.macomnet.net> References: <20040904080058.GV423@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: 5.3-BETA2 df(1) reports incorrect values for UFS1 FS 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, 06 Sep 2004 06:10:22 -0000 On Sat, 4 Sep 2004, 18:01+1000, Peter Jeremy wrote: > On a 4.10 system, my /home reports as: > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on > /dev/ad0s3g 86710002 71758104 8015098 90% 1803049 9038549 17% /home > > When I mount it on a 5.3-BETA2 system, I get: > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on > /dev/ad0s3g 86710002 1929924 77843278 2% 70983 10770615 1% /home > > This is somewhat disconcerting. As far as I can tell, all the files are > there but 5.3 doesn't realise it. > > fsck on 5.3 reports no errors and: > 1803048 files, 35879051 used, 42390039 free (1903 frags, 5298517 blocks, 0.0% fragmentation) > fsck on 4.10 reports no errors and: > 1803048 files, 35879051 used, 7475950 free (390462 frags, 885656 blocks, 0.9% fragmentation) > > Any ideas what is wrong with 5.3? More critically, is it safe to write > to a UFS1 filesystem with 5.3? Known bug with superblock summary: http://freebsd.rambler.ru/bsdmail/freebsd-current_2003/msg04802.html http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/65223 -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06: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 2912116A4CE for ; Mon, 6 Sep 2004 06:28:56 +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 23D9043D5C for ; Mon, 6 Sep 2004 06:28:54 +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 i866SkP0078618; Mon, 6 Sep 2004 08:28:50 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413C0378.1010003@DeepCore.dk> Date: Mon, 06 Sep 2004 08:28:08 +0200 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: "Thomas T. Veldhouse" References: <413B4660.6090203@veldy.net> <413B5361.9070201@DeepCore.dk> <413BBBC7.2000904@veldy.net> In-Reply-To: <413BBBC7.2000904@veldy.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org Subject: Re: ATTN Soren: BETA3 still hangs on ATAPI DVD Detection during boot 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, 06 Sep 2004 06:28:56 -0000 Thomas T. Veldhouse wrote: > S=F8ren Schmidt wrote: >=20 >> You need to run -current to get the latest fixes, they have not made=20 >> it in before BETA3 was cut. I have not had time to do it and nobody=20 >> else seem to have felt it was important enough to even offer to help..= =2E >> > You mentioned earlier to just copy the CURRENT files=20 > /usr/src/sys/dev/ata/* over into the 5.3-BETA and rebuild the kernel=20 > (GENERIC, no optimizations). I just did that today with the 19:30CDT=20 > CURRENT kernel sources and I am still seeing this hang. Should I be=20 > looking elsewhere for this fix (i.e. ACPI)? That should do it yes, however if you are still experiencing=20 lockups/hangs you shoudl disable ATAPI DMA in loader.conf and see if=20 that helps. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06:30: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 165F516A4CE for ; Mon, 6 Sep 2004 06:30:46 +0000 (GMT) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F5B43D3F for ; Mon, 6 Sep 2004 06:30:45 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1C4D2O-0008YM-HF for freebsd-current@freebsd.org; Mon, 06 Sep 2004 10:31:36 +0400 Date: Mon, 6 Sep 2004 10:31:36 +0400 From: "Boris B. Samorodov" To: freebsd-current@freebsd.org Message-ID: <20040906063136.GA32825@ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: "Boris B. Samorodov" Subject: gdb-6 in 5.3-BETA3 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, 06 Sep 2004 06:30:46 -0000 Hi! New gdb V.6 in base system doesn't have option '-k', while the ports's version has. Is it planned to be fixed till 5.3-RELEASE? ----- # uname -a FreeBSD gw.ipt.ru 5.3-BETA3 FreeBSD 5.3-BETA3 #7: Mon Sep 6 09:26:53 MSD 2004 bsam@gw.ipt.ru:/usr/obj/usr/src/sys/GW i386 ----- # gdb -k gdb: unrecognized option `-k' Use `gdb --help' for a complete list of options. ----- # gdb --version GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". ----- # gdb6 -k GNU gdb 20040803 [GDB v6.x for FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd5.3". ----- WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06:31: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 4CC8616A4CE for ; Mon, 6 Sep 2004 06:31:55 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2606943D3F for ; Mon, 6 Sep 2004 06:31:55 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 29843 invoked from network); 6 Sep 2004 06:31:54 -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 ; 6 Sep 2004 06:31:54 -0000 Received: from hydrogen.funkthat.com (lghcxi@localhost.funkthat.com [127.0.0.1])i866VruU073762; Sun, 5 Sep 2004 23:31:53 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i866Vqfh073761; Sun, 5 Sep 2004 23:31:52 -0700 (PDT) Date: Sun, 5 Sep 2004 23:31:52 -0700 From: John-Mark Gurney To: "Boris B. Samorodov" Message-ID: <20040906063152.GC72089@funkthat.com> Mail-Followup-To: "Boris B. Samorodov" , freebsd-current@freebsd.org References: <20040906063136.GA32825@ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906063136.GA32825@ipt.ru> 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: freebsd-current@freebsd.org Subject: Re: gdb-6 in 5.3-BETA3 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: Mon, 06 Sep 2004 06:31:55 -0000 Boris B. Samorodov wrote this message on Mon, Sep 06, 2004 at 10:31 +0400: > New gdb V.6 in base system doesn't have option '-k', while the ports's > version has. Is it planned to be fixed till 5.3-RELEASE? but there is kgdb.... -- 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 Mon Sep 6 06:41: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 4C15F16A4CF; Mon, 6 Sep 2004 06:41:18 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BF043D2D; Mon, 6 Sep 2004 06:41:17 +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 i866fHkl029138; Mon, 6 Sep 2004 02:41:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i866fGLk062674; Mon, 6 Sep 2004 02:41:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 23D977303F; Mon, 6 Sep 2004 02:41:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040906064117.23D977303F@freebsd-current.sentex.ca> Date: Mon, 6 Sep 2004 02:41:17 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 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: Mon, 06 Sep 2004 06:41:18 -0000 TB --- 2004-09-06 05:36:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-06 05:36:24 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-09-06 05:36:24 - checking out the source tree TB --- 2004-09-06 05:36:24 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-09-06 05:36:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-06 05:40:21 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-06 05:40:21 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-06 05:40:21 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/main.c cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/perform.c cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat=2 -Wno-format-extra-args -Werror -o pkg_version main.o perform.o /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/../lib/libinstall.a -lfetch -lmd -lssl -lcrypto gzip -cn /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/pkg_install/version/pkg_version.1 > pkg_version.1.gz ===> usr.sbin/ppp cc -O2 -pipe -DNOI4B -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp/acf.c /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp/acf.c: In function `acf_LayerPull': /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp/acf.c:76: warning: cast increases required alignment of target type *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin/ppp. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-09-06 06:41:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-06 06:41:16 - ERROR: failed to build world TB --- 2004-09-06 06:41:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 06:45: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 B263216A4CE for ; Mon, 6 Sep 2004 06:45:52 +0000 (GMT) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7290C43D46 for ; Mon, 6 Sep 2004 06:45:52 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1C4DH1-0008Zo-DD for freebsd-current@freebsd.org; Mon, 06 Sep 2004 10:46:43 +0400 Date: Mon, 6 Sep 2004 10:46:43 +0400 From: "Boris B. Samorodov" To: freebsd-current@freebsd.org Message-ID: <20040906064643.GB32825@ipt.ru> References: <20040906063136.GA32825@ipt.ru> <20040906063152.GC72089@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906063152.GC72089@funkthat.com> Sender: "Boris B. Samorodov" Subject: Re: gdb-6 in 5.3-BETA3 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, 06 Sep 2004 06:45:52 -0000 On Sun, Sep 05, 2004 at 11:31:52PM -0700, John-Mark Gurney wrote: > Boris B. Samorodov wrote this message on Mon, Sep 06, 2004 at 10:31 +0400: > > New gdb V.6 in base system doesn't have option '-k', while the ports's > > version has. Is it planned to be fixed till 5.3-RELEASE? > > but there is kgdb.... OK. kgdb works fine. But it is not clear from "man gdb", that if option "gdb -k" is not working, one should use "kgdb". > John-Mark Gurney Voice: +1 415 225 5579 WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 07:20: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 7013A16A4CE; Mon, 6 Sep 2004 07:20:18 +0000 (GMT) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E4443D48; Mon, 6 Sep 2004 07:20:18 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1C4DoK-0008dz-JZ; Mon, 06 Sep 2004 11:21:08 +0400 Date: Mon, 6 Sep 2004 11:21:08 +0400 From: "Boris B. Samorodov" To: Andre Oppermann Message-ID: <20040906072108.GC32825@ipt.ru> References: <413B9A36.2D0B9696@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413B9A36.2D0B9696@freebsd.org> Sender: "Boris B. Samorodov" cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12 in kernel module uipc_mbuf2.c 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, 06 Sep 2004 07:20:18 -0000 On Mon, Sep 06, 2004 at 12:59:02AM +0200, Andre Oppermann wrote: > > Does it panic 'reliablily' in the same place or is it more of a random > occurence? I'm not long in the office tomorrow (my test machine is there) > but I'll try to reproduce it within the next few days. Recompiled today to 5.3-BETA3. Here is the results. # uname -a FreeBSD gw.ipt.ru 5.3-BETA3 FreeBSD 5.3-BETA3 #7: Mon Sep 6 09:26:53 MSD 2004 bsam@gw.ipt.ru:/usr/obj/usr/src/sys/GW i386 ------ # addr2line -e /boot/kernel/kernel.debug 0xc053a0b0 /usr/src/sys/kern/uipc_mbuf2.c:389 ------ Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc0e6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc053a0b0 stack pointer = 0x10:0xc7fcb8e8 frame pointer = 0x10:0xc7fcb8f0 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 = 37 (swi1: net) [thread 100038] Stopped at m_tag_locate+0x40: cmpl %ecx,0x8(%edx) db> bt full No such command db> where m_tag_locate(c1541300,0,f,0,c14c3c00) at m_tag_locate+0x40 ether_output_frame(c1380000,c1541300,6,c7fcb9ac,c7fcb944) at ether_output_frame+0x3a ether_output(c1380000,c1541300,c7fcb9ac,c153b6b4,c7fcb9b0) at ether_output+0x41e ip_output(c1541300,0,c7fcb9a8,1,0) at ip_output+0x8e9 ip_forward(c1541300,1,12,0,1) at ip_forward+0x390 ip_input(c1541300,0,c06b91b3,e5,c073bd98) at ip_input+0x54c netisr_processqueue(c073bd98,c070a9c0,1,c06aed23,c12c6dc0) at netisr_processqueue+0x8e swi_net(0,0,c06ad32e,268,0) at swi_net+0xe9 ithread_loop(c1296b00,c7fcbd48,c06ad119,32c,deadc0de) at ithread_loop+0x172 fork_exit(c04e0060,c1296b00,c7fcbd48) at fork_exit+0xc6 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc7fcbd7c, ebp = 0 --- db> panic panic: from debugger cpuid = 0 Uptime: 4m3s Dumping 126 MB 16 32 48 64 80 96 112 Dump complete Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... ----- > Andre WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 07:30: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 CFF0616A4CE; Mon, 6 Sep 2004 07:30:32 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 444B743D39; Mon, 6 Sep 2004 07:30:31 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])i867URqO028346; Mon, 6 Sep 2004 10:30:28 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i867UEgN054583; Mon, 6 Sep 2004 10:30:14 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)i867UEMo054573; Mon, 6 Sep 2004 10:30:14 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Mon, 6 Sep 2004 10:30:14 +0300 From: Giorgos Keramidas To: "Bruce A. Mah" Message-ID: <20040906073014.GA13651@orion.daedalusnetworks.priv> References: <1094426835.767.50.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094426835.767.50.camel@localhost> cc: freebsd-doc@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: RFC: 5.3 Migration Guide 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, 06 Sep 2004 07:30:33 -0000 On 2004-09-05 16:27, "Bruce A. Mah" wrote: > > I'd like to solicit a pre-commit review on the document at: > > http://people.freebsd.org/~bmah/pub/article.html In section 4: On the i386 and pc98 platforms, a UserConfig utility exists on 4.X to allow boot-time configuration of ISA devices when booting from installation media. Under FreeBSD 5.X, this functionality has been replaced in part by the device.hints(5) mechanism (it allows specifying the same parameters, but with a very different interface). Do you think we should add a note about why the change was made? Having to learn something new regarding boot-time kernel configuration is probably going to raise a few complaints, but at least we can explain in a few short words why the change was made :-) From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 07:59: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 B4AE616A4CF for ; Mon, 6 Sep 2004 07:59:44 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 82B1C43D58 for ; Mon, 6 Sep 2004 07:59:43 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail 10091 invoked by uid 65534); 6 Sep 2004 07:59:41 -0000 Received: from unknown (EHLO [212.204.44.203]) (212.204.44.203) by mail.gmx.net (mp007) with SMTP; 06 Sep 2004 09:59:41 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: freebsd-current@freebsd.org In-Reply-To: <1094432328.878.7.camel@klamath.ankon.de.eu.org> References: <1094432328.878.7.camel@klamath.ankon.de.eu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6rJOoX/tXyDN7VTTqQHb" Message-Id: <1094457578.1787.18.camel@klamath.ankon.de.eu.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 06 Sep 2004 09:59:39 +0200 cc: Robert Watson Subject: Re: Panic (Page fault) related to ipv6? [softclock, nd6_timer, in6_purgeaddr, in6_unlink_ifa] 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, 06 Sep 2004 07:59:44 -0000 --=-6rJOoX/tXyDN7VTTqQHb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 2004-09-06 at 02:58, Andreas Kohn wrote: > Hi, >=20 > just got this panic, perhaps someone is interested. Happened when > reading a probably damaged CD, don't know if that is related (didn't > look so in the backtrace). >=20 > System is FreeBSD klamath.ankon.de.eu.org 6.0-CURRENT FreeBSD > 6.0-CURRENT #16: Sun Sep 5 12:18:47 CEST 2004 =20 > root@klamath.ankon.de.eu.org:/usr/obj/usr/src/sys/KLAMATH i386, > sources from around ~0900. >=20 > Kernel config contains IPV6, IPSEC (so no mpsafenet), ULE, and the > default setting for PREEMPTION (i didn't set any), no WITNESS or > INVARIANTS, but makeoptions DEBUG=3D-g. >=20 > Here it is: > ----- >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x1 > fault code =3D supervisor write, page not present > instruction pointer =3D 0x8:0xc05e5f12 > stack pointer =3D 0x10:0xcbf1dc0c > frame pointer =3D 0x10:0xcbf1dc28 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 27 (swi5: clock sio) > trap number =3D 12 > panic: page fault >=20 >=20 >=20 > (kgdb) bt full > #0 doadump () at pcpu.h:159 > #1 0xc051b576 in boot (howto=3D260) at > #2 0xc051bcf7 in panic (fmt=3D0xc0708284 "%s") > #3 0xc06de456 in trap_fatal (frame=3D0xcbf1dbcc, eva=3D1) > #4 0xc06de6fb in trap_pfault (frame=3D0xcbf1dbcc, usermode=3D0, eva=3D1) > #5 0xc06deaf5 in trap (frame=3D > #6 0xc06d019a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 > #7 0x00000018 in ?? () > #8 0x00000010 in ?? () > #9 0x00000010 in ?? () > #10 0xc1df0000 in ?? () > #11 0xffffffff in ?? () > #12 0xcbf1dc28 in ?? () > #13 0xcbf1dbf8 in ?? () > #14 0xc1df0000 in ?? () > #15 0xc1cd5200 in ?? () > #16 0xc1df0000 in ?? () > #17 0x00000001 in ?? () > #18 0x0000000c in ?? () > #19 0x00000002 in ?? () > #20 0xc05e5f12 in in6_unlink_ifa (ia=3D0x0, ifp=3D0xc1df0000) > #21 0xc05e615d in in6_purgeaddr (ifa=3D0xc1df0000) > #22 0xc06019bf in nd6_timer (ignored_arg=3D0x0) > #23 0xc052ab55 in softclock (dummy=3D0x0) at > #24 0xc0502229 in ithread_loop (arg=3D0xc18f8580) > #25 0xc0500f82 in fork_exit (callout=3D0xc0502170 , arg=3D0= x0, > #26 0xc06d01fc in fork_trampoline () at Okay, I read the thread on http://lists.freebsd.org/pipermail/freebsd-current/2004-September/036475.ht= ml (5.3-BETA3 panic, probably IPv6+SMP+mpsafenet related; rwatson CC'd), as= well as http://www.freebsd.org/cgi/query-pr.cgi?pr=3D70393 (similar panic = with PF). I don't have PF compiled into my kernel or loaded as module, and use ipfw2 only. This machine uses IPv6, but I don't need IPSEC currently and could remove it from the kernel configuration. I will try to apply both Robert Watson's patch and the patch from the PR, but as I don't know how to reproduce the panic it will be rather difficult to say if it is gone after patching. Just guessing here, but find below the values of *ifp. One thing I noticed and which puzzles me a little...is it pure coincidence that frame #16 has the same address listed as ifp? Regards, -- Andreas ----- #15 0xc1cd5200 in ?? () #16 0xc1df0000 in ?? () #17 0x00000001 in ?? () #18 0x0000000c in ?? () #19 0x00000002 in ?? () #20 0xc05e5f12 in in6_unlink_ifa (ia=3D0x0, ifp=3D0xc1df0000) at /usr/src/sys/netinet6/in6.c:1157 #21 0xc05e615d in in6_purgeaddr (ifa=3D0xc1df0000) at /usr/src/sys/netinet6/in6.c:1146 #22 0xc06019bf in nd6_timer (ignored_arg=3D0x0) at /usr/src/sys/netinet6/nd6.c:562 #23 0xc052ab55 in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout.c:259 #24 0xc0502229 in ithread_loop (arg=3D0xc18f8580) at /usr/src/sys/kern/kern_intr.c:547 #25 0xc0500f82 in fork_exit (callout=3D0xc0502170 , arg=3D0x0= , frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:807 #26 0xc06d01fc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) frame 20 #20 0xc05e5f12 in in6_unlink_ifa (ia=3D0x0, ifp=3D0xc1df0000) at /usr/src/sys/netinet6/in6.c:1157 1157 TAILQ_REMOVE(&ifp->if_addrlist, &ia->ia_ifa, ifa_list); (kgdb) p *ifp $1 =3D {if_softc =3D 0xc1d7eaa0, if_link =3D {tqe_next =3D 0xc1cc0330,=20 tqe_prev =3D 0x0},=20 if_xname =3D "\000\000\000\000\000\000\000\000\020\200\216=C1 mt=C0",=20 if_dname =3D 0xc1cd5880 "\037", if_dunit =3D 2, if_addrhead =3D {tqh_firs= t =3D 0x0,=20 tqh_last =3D 0x0}, if_klist =3D {kl_lock =3D 0x0, kl_list =3D {slh_firs= t =3D 0x0}},=20 if_pcount =3D 0, if_carp =3D 0x0, if_bpf =3D 0x0, if_index =3D 0, if_time= r =3D 0,=20 if_nvlans =3D 60132, if_flags =3D -1042816820, if_capabilities =3D 1,=20 if_capenable =3D -1039976912, if_linkmib =3D 0x3, if_linkmiblen =3D 3247342376,=20 if_data =3D {ifi_type =3D 96 '`', ifi_physical =3D 16 '\020',=20 ifi_addrlen =3D 117 'u', ifi_hdrlen =3D 192 '=C0', ifi_link_state =3D 0 '\0',=20 ifi_recvquota =3D 82 'R', ifi_xmitquota =3D 205 '=CD', ifi_datalen =3D = 193 '=C1',=20 ifi_mtu =3D 1, ifi_metric =3D 3254990384, ifi_baudrate =3D 0, ifi_ipack= ets =3D 0,=20 ifi_ierrors =3D 0, ifi_opackets =3D 0, ifi_oerrors =3D 1, ifi_collision= s =3D 0,=20 ifi_ibytes =3D 0, ifi_obytes =3D 3252151496, ifi_imcasts =3D 3252153196= ,=20 ifi_omcasts =3D 2, ifi_iqdrops =3D 3253484064, ifi_noproto =3D 3,=20 ifi_hwassist =3D 3247345724, ifi_unused =3D 3228881728, ifi_lastchange = =3D { tv_sec =3D -1043507072, tv_usec =3D 1}}, if_multiaddrs =3D {tqh_first= =3D 0x0,=20 tqh_last =3D 0x0}, if_amcount =3D 0, if_output =3D 0, if_input =3D 0,=20 if_start =3D 0, if_ioctl =3D 0, if_watchdog =3D 0, if_init =3D 0xc1cc0b28= ,=20 if_resolvemulti =3D 0xc1d7ed8c, if_snd =3D {ifq_head =3D 0x1,=20 ifq_tail =3D 0xc2033630, ifq_len =3D 3, ifq_maxlen =3D -1047624740,=20 ifq_drops =3D -1066069920, ifq_mtx =3D {mtx_object =3D {lo_class =3D 0xc1cd5200,=20 lo_name =3D 0x1
,=20 ---Type to continue, or q to quit--- lo_type =3D 0xc2033630 "=E4\232t=C0=F3=D0q=C0=F3=D0q=C0", lo_flags = =3D 0, lo_list =3D { tqe_next =3D 0x0, tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_loc= k =3D 1,=20 mtx_recurse =3D 0}, ifq_drv_head =3D 0x0, ifq_drv_tail =3D 0xc1df0264= ,=20 ifq_drv_len =3D -1042815936, ifq_drv_maxlen =3D 1, altq_type =3D -1040411352,=20 altq_flags =3D 10, altq_disc =3D 0xc18e9018, altq_ifp =3D 0xc0751060,=20 altq_enqueue =3D 0xc1cd5880, altq_dequeue =3D 0x1, altq_request =3D 0xc1fc9528,=20 altq_clfier =3D 0x4cc0, altq_classify =3D 0, altq_tbr =3D 0x0, altq_cdn= r =3D 0x0},=20 if_broadcastaddr =3D 0x9
, lltables =3D 0x4cc0= , if_label =3D 0x0, if_prefixhead =3D {tqh_first =3D 0xc1d7e330,=20 tqh_last =3D 0xc1d7e83c}, if_afdata =3D {0x2, 0xc1ec38dc, 0x3, 0xc18e80e8,=20 0xc074d340, 0xc18f8e00, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc1d7e440, 0xc1cc0a18, 0x1, 0xc1b6e318, 0x1, 0xc18e807c, 0xc0751060,=20 0xc1cd5880, 0x1, 0xc1b6e318, 0x18, 0x0, 0x0, 0x0, 0x3, 0x18, 0x0,=20 0xc1d7e8c4, 0xc1cc0908, 0x1, 0xc1ec4000, 0x3},=20 if_afdata_initialized =3D -1047622292, if_afdata_mtx =3D {mtx_object =3D = { lo_class =3D 0xc0751060, lo_name =3D 0xc18f8e00 "*\001",=20 lo_type =3D 0x4
, lo_flags =3D 3253485568,= =20 lo_list =3D {tqe_next =3D 0x3b, tqe_prev =3D 0x0}, lo_witness =3D 0x0= },=20 mtx_lock =3D 0, mtx_recurse =3D 3}, if_starttask =3D {ta_link =3D { stqe_next =3D 0x3b}, ta_pending =3D 0, ta_priority =3D -1042814712,=20 ta_func =3D 0xc1d7ed48, ta_context =3D 0x2}} (kgdb) frame 21 #21 0xc05e615d in in6_purgeaddr (ifa=3D0xc1df0000) at /usr/src/sys/netinet6/in6.c:1146 1146 in6_unlink_ifa(ia, ifp); (kgdb) p *ifp $2 =3D {if_softc =3D 0xc058e690, if_link =3D {tqe_next =3D 0xc058eb60,=20 tqe_prev =3D 0xc058e350}, if_xname =3D "=B0=DFX=C0@=F8X=C00=E2X=C0 =E9X= =C0",=20 if_dname =3D 0x3
, if_dunit =3D 1, if_addrhead =3D { tqh_first =3D 0xfffffff, tqh_last =3D 0xc058fce0}, if_klist =3D {kl_loc= k =3D 0x0,=20 kl_list =3D {slh_first =3D 0x0}}, if_pcount =3D 0, if_carp =3D 0x0, if_= bpf =3D 0x0,=20 if_index =3D 0, if_timer =3D 0, if_nvlans =3D 12438, if_flags =3D -301047= 508,=20 if_capabilities =3D -1727442502, if_capenable =3D 124634137,=20 if_linkmib =3D 0x706af48f, if_linkmiblen =3D 3915621685, if_data =3D { ifi_type =3D 163 '=A3', ifi_physical =3D 149 '\225', ifi_addrlen =3D 10= 0 'd',=20 ifi_hdrlen =3D 158 '\236', ifi_link_state =3D 50 '2',=20 ifi_recvquota =3D 136 '\210', ifi_xmitquota =3D 219 '=DB',=20 ifi_datalen =3D 14 '\016', ifi_mtu =3D 2044508324, ifi_metric =3D 3772115230,=20 ifi_baudrate =3D 2547177864, ifi_ipackets =3D 162941995,=20 ifi_ierrors =3D 2125561021, ifi_opackets =3D 3887607047,=20 ifi_oerrors =3D 2428444049, ifi_collisions =3D 498536548,=20 ifi_ibytes =3D 1789927666, ifi_obytes =3D 4089016648,=20 ifi_imcasts =3D 2227061214, ifi_omcasts =3D 450548861,=20 ifi_iqdrops =3D 1843258603, ifi_noproto =3D 4107580753,=20 ifi_hwassist =3D 2211677639, ifi_unused =3D 325883990, ifi_lastchange = =3D { tv_sec =3D 1684777152, tv_usec =3D -43845254}}, if_multiaddrs =3D { tqh_first =3D 0x8a65c9ec, tqh_last =3D 0x14015c4f}, if_amcount =3D 1661365465,=20 if_output =3D 0xfa0f3d63, if_input =3D 0x8d080df5, if_start =3D 0x3b6e20c= 8,=20 if_ioctl =3D 0x4c69105e, if_watchdog =3D 0xd56041e4, if_init =3D 0xa26771= 72, ---Type to continue, or q to quit--- if_resolvemulti =3D 0x3c03e4d1, if_snd =3D {ifq_head =3D 0x4b04d447,=20 ifq_tail =3D 0xd20d85fd, ifq_len =3D -1526024853, ifq_maxlen =3D 901097722,=20 ifq_drops =3D 1119000684, ifq_mtx =3D {mtx_object =3D {lo_class =3D 0xdbbbc9d6,=20 lo_name =3D 0xacbcf940
,=20 lo_type =3D 0x32d86ce3
,=20 lo_flags =3D 1172266101, lo_list =3D {tqe_next =3D 0xdcd60dcf,=20 tqe_prev =3D 0xabd13d59}, lo_witness =3D 0x26d930ac},=20 mtx_lock =3D 1373503546, mtx_recurse =3D 3369554304},=20 ifq_drv_head =3D 0xbfd06116, ifq_drv_tail =3D 0x21b4f4b5,=20 ifq_drv_len =3D 1454621731, ifq_drv_maxlen =3D -809855591,=20 altq_type =3D -1195530993, altq_flags =3D 671266974, altq_disc =3D 0x5f058808,=20 altq_ifp =3D 0xc60cd9b2, altq_enqueue =3D 0xb10be924,=20 altq_dequeue =3D 0x2f6f7c87, altq_request =3D 0x58684c11,=20 altq_clfier =3D 0xc1611dab, altq_classify =3D 0xb6662d3d,=20 altq_tbr =3D 0x76dc4190, altq_cdnr =3D 0x1db7106},=20 if_broadcastaddr =3D 0x98d220bc
,=20 lltables =3D 0xefd5102a, if_label =3D 0x71b18589, if_prefixhead =3D { tqh_first =3D 0x6b6b51f, tqh_last =3D 0x9fbfe4a5}, if_afdata =3D {0xe8b8d433,=20 0x7807c9a2, 0xf00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x86d3d2d,=20 0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,=20 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,=20 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,=20 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7,=20 ---Type to continue, or q to quit--- 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0},=20 if_afdata_initialized =3D 1141124467, if_afdata_mtx =3D {mtx_object =3D { lo_class =3D 0x33031de5,=20 lo_name =3D 0xaa0a4c5f
,=20 lo_type =3D 0xdd0d7cc9
,=20 lo_flags =3D 1342533948, lo_list =3D {tqe_next =3D 0x270241aa,=20 tqe_prev =3D 0xbe0b1010}, lo_witness =3D 0xc90c2086},=20 mtx_lock =3D 1466479909, mtx_recurse =3D 544179635}, if_starttask =3D { ta_link =3D {stqe_next =3D 0xb966d409}, ta_pending =3D -832445281,=20 ta_priority =3D 1591671054, ta_func =3D 0x29d9c998, ta_context =3D 0xb0d09822}} --=-6rJOoX/tXyDN7VTTqQHb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBPBjpYucd7Ow1ygwRAil0AJ97CKhvS7QUNsCQVCgmq+4b7XmlKQCdHY8f wIKEDHfrcVKbE+uBXFPye4A= =j9ty -----END PGP SIGNATURE----- --=-6rJOoX/tXyDN7VTTqQHb-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 08:10: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 DBA4916A4D0 for ; Mon, 6 Sep 2004 08:10:08 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5156043D46 for ; Mon, 6 Sep 2004 08:10:08 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 2F3892BDB7 for ; Mon, 6 Sep 2004 18:10:04 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id F3E2A511FA; Mon, 6 Sep 2004 17:40:01 +0930 (CST) Date: Mon, 6 Sep 2004 17:40:01 +0930 From: Greg 'groggy' Lehey To: "Boris B. Samorodov" Message-ID: <20040906081001.GJ26744@wantadilla.lemis.com> References: <20040906063136.GA32825@ipt.ru> <20040906063152.GC72089@funkthat.com> <20040906064643.GB32825@ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8tZVdKiiYitVG083" Content-Disposition: inline In-Reply-To: <20040906064643.GB32825@ipt.ru> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-current@freebsd.org Subject: Re: gdb-6 in 5.3-BETA3 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, 06 Sep 2004 08:10:09 -0000 --8tZVdKiiYitVG083 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Monday, 6 September 2004 at 10:46:43 +0400, Boris B. Samorodov wrote: > On Sun, Sep 05, 2004 at 11:31:52PM -0700, John-Mark Gurney wrote: > >> Boris B. Samorodov wrote this message on Mon, Sep 06, 2004 at 10:31 +040= 0: >>> New gdb V.6 in base system doesn't have option '-k', while the ports's >>> version has. Is it planned to be fixed till 5.3-RELEASE? >> >> but there is kgdb.... > > OK. kgdb works fine. > > But it is not clear from "man gdb", that if option "gdb -k" is not > working, one should use "kgdb". Indeed. I thought that kgdb was deprecated, and that we should be using gdb -k. It would be nice to come to an agreement on that. Note also that most recent versions of gdb seem to be broken when trying to access userland. On a machine built in May: GNU gdb 5.2.1 (FreeBSD) (kgdb) f 16 #16 0xc0621df8 in namei (ndp=3D0xd7c05c30) at /usr/src/sys/kern/vfs_looku= p.c:179 179 error =3D lookup(ndp); (kgdb) p *ndp $1 =3D { ni_dirp =3D 0x805f8a8---Can't read userspace from dump, or kernel proce= ss--- Same dump with recently ported gdb6. Backtrace contains many spurious "stack frames": GNU gdb 20040803 [GDB v6.x for FreeBSD] (partial bt) #6 0xc074c67c in trap (frame=3D {tf_fs =3D 0x18, tf_es =3D 0x10, tf_ds =3D 0x10, tf_edi =3D 0xc07ba= 264, tf_esi =3D 0x1, tf_ebp =3D 0xd7c05964, tf_isp =3D 0xd7c0594c, tf_ebx = =3D 0x0, tf_edx =3D 0x0, tf_ecx =3D 0xc1014000, tf_eax =3D 0x12, tf_trapno = =3D 0x3, tf_err =3D 0x0, tf_eip =3D 0xc073a4de, tf_cs =3D 0x8, tf_eflags = =3D 0x296, tf_esp =3D 0xd7c05998, tf_ss =3D 0xd7c05984}) at /usr/src/sys/i3= 86/i386/trap.c:579 #7 0xc073b7ca in calltrap () at {standard input}:94 #8 0x00000018 in ?? () #9 0x00000010 in ?? () #10 0x00000010 in ?? () #11 0xc07ba264 in ?? () #12 0x00000001 in ?? () #13 0xd7c05964 in ?? () #14 0xd7c0594c in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0xc1014000 in ?? () #18 0x00000012 in ?? () #19 0x00000003 in ?? () #20 0x00000000 in ?? () #21 0xc073a4de in Debugger (msg=3D0xc07b390c "panic") at machine/cpufunc.= h:56 #22 0xc05ddc85 in __panic (file=3D0xc07ba1fb "/usr/src/sys/kern/vfs_subr.= c", line=3D0x2f3,=20 fmt=3D0xc07ba264 "cleaned vnode isn't") at /usr/src/sys/kern/kern_shu= tdown.c:532 #23 0xc06259b0 in getnewvnode (tag=3D0xc07bdc45 "ufs", mp=3D0xc399d000, v= ops=3D0x0, vpp=3D0x0) at /usr/src/sys/kern/vfs_subr.c:785 #24 0xc06f7cb0 in ffs_vget (mp=3D0xc399d000, ino=3D0x3944d1, flags=3D0x2,= vpp=3D0xd7c05a84) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1252 #25 0xc06fe9da in ufs_lookup (ap=3D0xd7c05b40) at /usr/src/sys/ufs/ufs/uf= s_lookup.c:599 #26 0xc0704ae7 in ufs_vnoperate (ap=3D0x0) at /usr/src/sys/ufs/ufs/ufs_vn= ops.c:2819 #27 0xc061deb1 in vfs_cache_lookup (ap=3D0x0) at vnode_if.h:82 #28 0xc0704ae7 in ufs_vnoperate (ap=3D0x0) at /usr/src/sys/ufs/ufs/ufs_vn= ops.c:2819 #29 0xc0622377 in lookup (ndp=3D0xd7c05c30) at vnode_if.h:52 (kgdb) f 30 #30 0xc0621df8 in namei (ndp=3D0xd7c05c30) at /usr/src/sys/kern/vfs_looku= p.c:179 179 error =3D lookup(ndp); (kgdb) p *ndp Bus error (core dumped) I'd be happy to try other versions if people can give me some reason to expect that they might do better. The data in question is accessible: I can get at it with ddb, and it used to be possible with gdb. I suspect that the problem might be in a library, since older gdbs from other machines have the same problem, but they don't on the older machines. Greg -- Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --8tZVdKiiYitVG083 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBPBtZIubykFB6QiMRAhgyAKCnF8Z4DagbCI9+ZlCbZFQMdy+FogCglEJf nwTP9rSJmLYtYhJfXsbk6vM= =Db4p -----END PGP SIGNATURE----- --8tZVdKiiYitVG083-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 08:24: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 ABD5616A4CE for ; Mon, 6 Sep 2004 08:24:11 +0000 (GMT) Received: from portalis.it (mail2.portalis.it [213.199.4.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA04843D1F for ; Mon, 6 Sep 2004 08:24:09 +0000 (GMT) (envelope-from esaltato@tele2.it) Received: from [62.123.129.136] ([62.123.129.136]) by portalis.it with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 6 Sep 2004 10:44:07 +0200 Message-ID: <413C1EA7.6060707@tele2.it> Date: Mon, 06 Sep 2004 10:24:07 +0200 From: Esaltato User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke References: <41383F2B.5040201@tele2.it> <1094231547.727.12.camel@gyros> In-Reply-To: <1094231547.727.12.camel@gyros> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: No keyboard with Gnome and X.org (and gnome loaded behind KDE) 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, 06 Sep 2004 08:24:11 -0000 Joe Marcus Clarke wrote: >On Fri, 2004-09-03 at 05:53, Esaltato wrote: > > >>I got a problem with GNOME since switching to xorg. On KDE everything is >>fine, but on Gnome 2.6 (all my system has been portupgraded yesterday) >>my keystrokes are blocked; as I type the text cursor stops blinking and >>nothing gets written. If I press ctrl, shift and some letters a lot of >>times it may happen that I can write sometimes, but only as long as I >>hold shift down and I don't change the writing focus. It seems like if >>my keys command are getting intercepted. This only happens as root. >>I want to point out that I've been throughly searching for solutions, >>and that not a solution proposed on the net has solved this. >>It may be related to the problem of this message popping up on Gnome >>(which I don't have, let's clarify it now, more on this later): >> >>:::::::start message >>Error activating XKB configuration. >>Probably internal X server problem. >> >> > >You need to read /usr/ports/UPDATING. > >[snip] > > I won't tell to read my original email, just read the answer to the other mail and you'll get it. Maybe I should start typing everything with caps lock on. The problem is still here anyway, I hope to see something getting better in "xorg with gnome keyboard problems". >>Any idea? I seem the only one with this problem. As for now, I'm >>sticking with KDE, but I need/want GNOME. >>Oh, just another thing that may be related, but I don't think is, but >>anyway is annoying: when I go to the desktop properties and hide my >>icons from the KDE desktop my GNOME desktop comes along, with all the >>icons (just some of them are blank, since gnome is not completely >>loaded) (and yes, keyboard works). Moreover the GNOME desktop picture >>comes up when I turn off my PC: why? Is a part of GNOME being loaded >>aside with kde/kdm? >> >> > >No clue. Perhaps somewhere you're starting Nautilus. > >Joe > > I'm not. Something other is happening. From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 08:38: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 AE43116A4CE for ; Mon, 6 Sep 2004 08:38:10 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76D3543D1F for ; Mon, 6 Sep 2004 08:38:10 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id F2E4926; Mon, 6 Sep 2004 10:38:08 +0200 (CEST) Date: Mon, 6 Sep 2004 10:38:08 +0200 From: Andrea Campi To: Randy Bush Message-ID: <20040906083808.GA63126@webcom.it> References: <16699.28812.895951.64132@ran.psg.com> <000f01c49389$be8b9d80$1200a8c0@gsicomp.on.ca> <1094420141.59109.3.camel@rushlight.kf8nh.com> <16699.37465.743702.58597@ran.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16699.37465.743702.58597@ran.psg.com> User-Agent: Mutt/1.5.6i cc: FreeBSD Current cc: Matt Emmerton Subject: Re: resuming portupgrade 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, 06 Sep 2004 08:38:10 -0000 On Sun, Sep 05, 2004 at 03:25:29PM -0700, Randy Bush wrote: > well, that's what i am running now. but do i know that there were > not other dependency sub-trees that failed? It might not be an elegant solution, but look for packages that have their +COMMENT file older than the time you started the portupgrade. Something like: find /var/db/pkg -type f -name +COMMENT ! \ -newer /var/db/pkg/first_updated_port/+COMMENT | awk -F/ '{print $5}' should do the trick. Hackish, yes, but effective. Bye, Andrea -- There's no place like ~ From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 09:32: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 1EC6416A4CE for ; Mon, 6 Sep 2004 09:32:59 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD1CF43D53 for ; Mon, 6 Sep 2004 09:32:57 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (oifyjhrv@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i869WtsU020417 for ; Mon, 6 Sep 2004 13:32:55 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 6 Sep 2004 13:32:55 +0400 (MSD) From: Maxim Konovalov To: current@freebsd.org Message-ID: <20040906132805.G20402@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: IPFW2 #if's removal 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, 06 Sep 2004 09:32:59 -0000 Hello, An enclosed diff removes ~90 lines of "#if !IPFW2" dead code and a little "FreeBSD_version" snipped. The purpose is to make the code a little bit easier to read and maintain. Is it desirable to commit it in HEAD and MFC to RELENG_5? Are there any objections/drawbacks? Index: lib/libalias/alias_db.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_db.c,v retrieving revision 1.61 diff -u -r1.61 alias_db.c --- lib/libalias/alias_db.c 6 Jul 2004 12:13:28 -0000 1.61 +++ lib/libalias/alias_db.c 5 Sep 2004 12:19:50 -0000 @@ -2473,17 +2473,12 @@ file, but making variables global is evil too. ****************/ -#ifndef IPFW2 -#define IPFW2 1 /* use new ipfw code */ -#endif - /* Firewall include files */ #include #include #include #include -#if IPFW2 /* support for new firewall code */ /* * helper function, updates the pointer to cmd with the length * of the current command, and also cleans up the first word of @@ -2554,8 +2549,6 @@ return ((char *)cmd - (char *)buf); } -#endif /* IPFW2 */ - static void ClearAllFWHoles(struct libalias *la); @@ -2648,7 +2641,6 @@ * add fwhole accept tcp from OAddr OPort to DAddr DPort add fwhole * accept tcp from DAddr DPort to OAddr OPort */ -#if IPFW2 if (GetOriginalPort(lnk) != 0 && GetDestPort(lnk) != 0) { u_int32_t rulebuf[255]; int i; @@ -2669,46 +2661,6 @@ if (r) err(1, "alias punch inbound(2) setsockopt(IP_FW_ADD)"); } -#else /* !IPFW2, old code to generate ipfw rule */ - - /* Build generic part of the two rules */ - rule.fw_number = fwhole; - IP_FW_SETNSRCP(&rule, 1); /* Number of source ports. */ - IP_FW_SETNDSTP(&rule, 1); /* Number of destination ports. */ - rule.fw_flg = IP_FW_F_ACCEPT | IP_FW_F_IN | IP_FW_F_OUT; - rule.fw_prot = IPPROTO_TCP; - rule.fw_smsk.s_addr = INADDR_BROADCAST; - rule.fw_dmsk.s_addr = INADDR_BROADCAST; - - /* Build and apply specific part of the rules */ - rule.fw_src = GetOriginalAddress(lnk); - rule.fw_dst = GetDestAddress(lnk); - rule.fw_uar.fw_pts[0] = ntohs(GetOriginalPort(lnk)); - rule.fw_uar.fw_pts[1] = ntohs(GetDestPort(lnk)); - - /* - * Skip non-bound links - XXX should not be strictly necessary, but - * seems to leave hole if not done. Leak of non-bound links? (Code - * should be left even if the problem is fixed - it is a clear - * optimization) - */ - if (rule.fw_uar.fw_pts[0] != 0 && rule.fw_uar.fw_pts[1] != 0) { - r = setsockopt(fireWallFD, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule); -#ifdef DEBUG - if (r) - err(1, "alias punch inbound(1) setsockopt(IP_FW_ADD)"); -#endif - rule.fw_src = GetDestAddress(lnk); - rule.fw_dst = GetOriginalAddress(lnk); - rule.fw_uar.fw_pts[0] = ntohs(GetDestPort(lnk)); - rule.fw_uar.fw_pts[1] = ntohs(GetOriginalPort(lnk)); - r = setsockopt(fireWallFD, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule); -#ifdef DEBUG - if (r) - err(1, "alias punch inbound(2) setsockopt(IP_FW_ADD)"); -#endif - } -#endif /* !IPFW2 */ /* Indicate hole applied */ lnk->data.tcp->fwhole = fwhole; fw_setfield(la, la->fireWallField, fwhole); @@ -2732,14 +2684,8 @@ return; memset(&rule, 0, sizeof rule); /* useless for ipfw2 */ -#if IPFW2 while (!setsockopt(la->fireWallFD, IPPROTO_IP, IP_FW_DEL, &fwhole, sizeof fwhole)); -#else /* !IPFW2 */ - rule.fw_number = fwhole; - while (!setsockopt(fireWallFD, IPPROTO_IP, IP_FW_DEL, - &rule, sizeof rule)); -#endif /* !IPFW2 */ fw_clrfield(la, la->fireWallField, fwhole); lnk->data.tcp->fwhole = -1; } @@ -2757,14 +2703,9 @@ memset(&rule, 0, sizeof rule); for (i = la->fireWallBaseNum; i < la->fireWallBaseNum + la->fireWallNumNums; i++) { -#if IPFW2 int r = i; while (!setsockopt(la->fireWallFD, IPPROTO_IP, IP_FW_DEL, &r, sizeof r)); -#else /* !IPFW2 */ - rule.fw_number = i; - while (!setsockopt(fireWallFD, IPPROTO_IP, IP_FW_DEL, &rule, sizeof rule)); -#endif /* !IPFW2 */ } /* XXX: third arg correct here ? /phk */ memset(la->fireWallField, 0, la->fireWallNumNums); Index: sys/netinet/ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.84 diff -u -r1.84 ip_dummynet.c --- sys/netinet/ip_dummynet.c 25 Aug 2004 09:31:30 -0000 1.84 +++ sys/netinet/ip_dummynet.c 5 Sep 2004 12:17:45 -0000 @@ -1063,7 +1063,6 @@ struct dn_flow_set * locate_flowset(int pipe_nr, struct ip_fw *rule) { -#if IPFW2 struct dn_flow_set *fs; ipfw_insn *cmd = rule->cmd + rule->act_ofs; @@ -1079,11 +1078,6 @@ return fs; if (cmd->opcode == O_QUEUE) -#else /* !IPFW2 */ - struct dn_flow_set *fs = NULL ; - - if ( (rule->fw_flg & IP_FW_F_COMMAND) == IP_FW_F_QUEUE ) -#endif /* !IPFW2 */ for (fs=all_flow_sets; fs && fs->fs_nr != pipe_nr; fs=fs->next) ; else { @@ -1094,16 +1088,11 @@ fs = &(p1->fs) ; } /* record for the future */ -#if IPFW2 #ifdef __i386__ ((ipfw_insn_pipe *)cmd)->pipe_ptr = fs; #else bcopy(&fs, & ((ipfw_insn_pipe *)cmd)->pipe_ptr, sizeof(fs)); #endif -#else - if (fs != NULL) - rule->pipe_ptr = fs; -#endif return fs ; } @@ -1131,20 +1120,14 @@ u_int64_t len = m->m_pkthdr.len ; struct dn_flow_queue *q = NULL ; int is_pipe; -#if IPFW2 ipfw_insn *cmd = fwa->rule->cmd + fwa->rule->act_ofs; -#endif KASSERT(m->m_nextpkt == NULL, ("dummynet_io: mbuf queue passed to dummynet")); -#if IPFW2 if (cmd->opcode == O_LOG) cmd += F_LEN(cmd); is_pipe = (cmd->opcode == O_PIPE); -#else - is_pipe = (fwa->rule->fw_flg & IP_FW_F_COMMAND) == IP_FW_F_PIPE; -#endif pipe_nr &= 0xffff ; Index: sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.90 diff -u -r1.90 ip_fw.h --- sys/netinet/ip_fw.h 19 Aug 2004 17:38:47 -0000 1.90 +++ sys/netinet/ip_fw.h 5 Sep 2004 12:18:00 -0000 @@ -27,7 +27,6 @@ #ifndef _IPFW2_H #define _IPFW2_H -#define IPFW2 1 /* * The kernel representation of ipfw rules is made of a list of Index: sys/netinet/ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.74 diff -u -r1.74 ip_fw2.c --- sys/netinet/ip_fw2.c 26 Aug 2004 14:18:30 -0000 1.74 +++ sys/netinet/ip_fw2.c 5 Sep 2004 12:20:16 -0000 @@ -43,8 +43,6 @@ #endif /* INET */ #endif -#define IPFW2 1 -#if IPFW2 #include #include #include @@ -3089,14 +3087,9 @@ */ if (sopt->sopt_name == IP_FW_ADD || (sopt->sopt_dir == SOPT_SET && sopt->sopt_name != IP_FW_RESETLOG)) { -#if __FreeBSD_version >= 500034 error = securelevel_ge(sopt->sopt_td->td_ucred, 3); if (error) return (error); -#else /* FreeBSD 4.x */ - if (securelevel >= 3) - return (EPERM); -#endif } error = 0; @@ -3436,5 +3429,3 @@ IPFW_LOCK_DESTROY(&layer3_chain); printf("IP firewall unloaded\n"); } - -#endif /* IPFW2 */ %%% -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 09:48: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 CB9BC16A4CE for ; Mon, 6 Sep 2004 09:48:10 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B4143D4C for ; Mon, 6 Sep 2004 09:48:06 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i869m6Ib028651; Mon, 6 Sep 2004 02:48:06 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i869m6ca028650; Mon, 6 Sep 2004 02:48:06 -0700 (PDT) (envelope-from rizzo) Date: Mon, 6 Sep 2004 02:48:06 -0700 From: Luigi Rizzo To: Maxim Konovalov Message-ID: <20040906024806.A28553@xorpc.icir.org> References: <20040906132805.G20402@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040906132805.G20402@mp2.macomnet.net>; from maxim@macomnet.ru on Mon, Sep 06, 2004 at 01:32:55PM +0400 cc: current@freebsd.org Subject: Re: IPFW2 #if's removal 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, 06 Sep 2004 09:48:10 -0000 On Mon, Sep 06, 2004 at 01:32:55PM +0400, Maxim Konovalov wrote: > Hello, > > An enclosed diff removes ~90 lines of "#if !IPFW2" dead code and a > little "FreeBSD_version" snipped. The purpose is to make the code a > little bit easier to read and maintain. Is it desirable to commit it > in HEAD and MFC to RELENG_5? Are there any objections/drawbacks? this change makes the backport to 4.x a PITA. Given that this is not a functional change but purely 'whitespace", i'd postpone it to the time when we declare 4.x unsupported, or at least 'IPFW1 on 4.x unsupported'. If you really really need to commit something of this, please leave the kernel part alone. [patch omitted] cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 19:09: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 58E4316A4CE for ; Sun, 5 Sep 2004 19:09:21 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EAD743D3F for ; Sun, 5 Sep 2004 19:09:21 +0000 (GMT) (envelope-from sirgay@arcor.de) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C42O8-0007BI-00 for current@freebsd.org; Sun, 05 Sep 2004 21:09:20 +0200 Received: from [217.248.10.122] (helo=cover.otfa) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1C42O7-000820-00 for current@freebsd.org; Sun, 05 Sep 2004 21:09:19 +0200 Received: from localhost (localhost.otfa [127.0.0.1]) by cover.otfa (Postfix) with ESMTP id CFE443A98 for ; Sun, 5 Sep 2004 21:09:17 +0200 (CEST) Received: from shadowx (shadowx.otfa [192.168.0.101]) by cover.otfa (Postfix) with SMTP id D3AF43B33 for ; Sun, 5 Sep 2004 20:43:18 +0200 (CEST) Date: Sun, 5 Sep 2004 20:46:26 +0200 From: Sirgay To: current@freebsd.org Message-Id: <20040905204626.6452a1b6@shadowx> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: I suppose it's clean - otfa.local X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:9a641afe6a4489782b6db108cb0f0bd9 X-Mailman-Approved-At: Mon, 06 Sep 2004 11:58:45 +0000 Subject: zone: PV ENTRY(0xc1033000) slab 0xc8374da0 freed address 0xc83747e8 unaligned 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, 05 Sep 2004 19:09:21 -0000 Everytime I run "make buildworld", I get the same lines and find myself in the debug-prompt. Here is my uname -a: FreeBSD baustelle.otfa.local 5.3-BETA3 FreeBSD 5.3-BETA3 #0: Sun Sep 5 15:58:07 CEST 2004 =20 root@baustelle.otfa.local:/usr/obj/usr/src/sys/GENERIC i386 And here are the last lines of output: zone: PV ENTRY(0xc1033000) slab 0xc8374da0 freed address 0xc83747e8 unaligned. panic: should be 0xc83747e0 cpuid =3D 0 KDB: enter: panic [thread 100096] Stopped at kdb_enter+0x2b: nop db>tr kdb_enter(c07f099b) at kdb_enter+0x2b panic(c080a2fe,c83747e0,c080a2cc,c080f4bb,c1033000) at panic+0x127 uma_dbg_free(c1033000,0,c83747e8) at uma_dbg_free+0xa4 uma_zfree_arg(c1033000,c83747e8,0) at uma_zfree_arg+0xf3 pmap_remove_entry(c15e1da4,c10d5278,962b000,962b000,9800000) at pmap_remove_entry+0x106 pmap_remove_pte(c15e1da4,bfc258ac,962b000) at pmap_remove_pte+0xda pmap_remove(c15e1da4,8068000,995e000) at pmap_remove_+0x106 vm_map_de=F6ete(c15e1ce4,8068000,995e00) at vm_map_delete+0x159 obreak(c1d56b00,cd940d14,1,12,287) at obreak+0x1a9 syscall(2f,2f,2f,9959000,8055060) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (17, FreeBSD ELF32, obreak), eip =3D 0x280d883b, esp =3D 0xbfbfe93c, ebp =3D 0xbfbfe978 ---=20 db> I used an unmodified 5.2.1-p9 GENERIC-System and upgraded it without errors. The sources are from about 11:30 today (Sunday 05.09.2004). From owner-freebsd-current@FreeBSD.ORG Sun Sep 5 20: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 A35A816A4CE for ; Sun, 5 Sep 2004 20:32:35 +0000 (GMT) Received: from jive.SoftHome.net (jive.SoftHome.net [66.54.152.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 3FD8C43D39 for ; Sun, 5 Sep 2004 20:32:35 +0000 (GMT) (envelope-from ertank@softhome.net) Received: (qmail 27741 invoked by uid 417); 5 Sep 2004 20:32:34 -0000 Received: from mambo-.softhome.net (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 5 Sep 2004 20:32:34 -0000 Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Sun, 05 Sep 2004 14:32:34 -0600 From: ertank@softhome.net To: freebsd-current@freebsd.org Date: Sun, 05 Sep 2004 14:32:34 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: ertank@softhome.net X-Originating-IP: [81.215.120.155] Message-ID: X-Mailman-Approved-At: Mon, 06 Sep 2004 11:58:45 +0000 Subject: 5.3-BETA2 and BETA3 boot 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: Sun, 05 Sep 2004 20:32:35 -0000 Hi, I could not find my solution in the list archieves. I could not decide which list to post. I am directed this list after I post to stable, so here it goes. I can not boot with very recent sources. I have FreeBSD 5.3-BETA2 #0: Tue Aug 31 22:36:53 EEST 2004 sources with cvsup. This kernel locks during boot, before mounting disks, and most probably during identification of disks. BETA1 was locked previously, too. By "lock" I mean first main console freeze, after several seconds keybord lights freeze. Keyboard does not work. Screen stays same. Only reset from case or re-cycling the power helps. There is no core dump or log. Below is the output of the screen of a verbose boot: After initializin "lo0" there is two times below paragraph and system locks: --- ata0: reinit channel .. ata0: reset tp1 mask=03 ostat=50 ostat1=50 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=10 devices=0x9 ata0: resetting done .. --- I have VIA chipset mainboard with onboard display. Mainboard model is: P4MAC-MLB or P4MAC-M I am not quite sure about it at the moment. It is an AZZA mainboard. North bridge is VIA P4M266A, Southbridge is VIA VT8235. I/O Chipset is Winbond W83697HF. I do not have this problem with my old kernel "FreeBSD 5.2-CURRENT #0: Thu Jul 1 22:40:57 EEST 2004" with same hardware. Yesterday, I tried again with 3 Sept 2004 evening sources. Now, I read "BETA3" during boot. Same problem persists. Hope above helps to find the problem. Regards, Ertan Kucukoglu From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 04:30: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 A142316A4CF for ; Mon, 6 Sep 2004 04:30:18 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B1CA43D39 for ; Mon, 6 Sep 2004 04:30:17 +0000 (GMT) (envelope-from sam.wun@authtec.net) Received: (qmail 93287 invoked from network); 6 Sep 2004 04:30:15 -0000 Received: from unknown (HELO [192.168.4.129]) (samwun@hgcbroadband.com@[221.127.106.219]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 6 Sep 2004 04:30:15 -0000 Message-ID: <413BE6CC.9010200@authtec.net> Date: Mon, 06 Sep 2004 12:25:48 +0800 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Sep 2004 11:58:45 +0000 Subject: PF+CARP is not yet migrated to Beta53. 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, 06 Sep 2004 04:30:18 -0000 Hi, I just found that PF CARP is not yet migrated to Beta53. At the mement, I will have to apply CARP patches to the src manually after installed Beta53. I think I will still rely on my own release of FreeBSD53 to enable PF+CARP for the time being.... Sam. From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 05:21: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 1752916A4CE; Mon, 6 Sep 2004 05:21:35 +0000 (GMT) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E895A43D1F; Mon, 6 Sep 2004 05:21:33 +0000 (GMT) (envelope-from keramida@hellug.gr) Received: from igloo.linux.gr (localhost [127.0.0.1])i865FZD1009343; Mon, 6 Sep 2004 08:15:35 +0300 Received: (from keramida@localhost) by igloo.linux.gr (8.12.11/8.12.11/Debian-5) id i865FWfb009338; Mon, 6 Sep 2004 08:15:33 +0300 X-Authentication-Warning: igloo.linux.gr: keramida set sender to keramida@linux.gr using -f Date: Mon, 6 Sep 2004 08:15:27 +0300 From: Giorgos Keramidas To: Don Lewis Message-ID: <20040906051526.GA8925@igloo.linux.gr> References: <200409041920.i84JKTKw032364@gw.catspoiler.org> <200409060133.i861Xafc035069@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409060133.i861Xafc035069@gw.catspoiler.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.891, required 5, autolearn=not spam, AWL 0.01, BAYES_00 -4.90) X-MailScanner-From: keramida@linux.gr X-Mailman-Approved-At: Mon, 06 Sep 2004 11:58:45 +0000 cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? 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, 06 Sep 2004 05:21:35 -0000 On 2004-09-05 18:33, Don Lewis wrote: > Index: sbin/fsck_ffs/fsck.h > =================================================================== > RCS file: /home/ncvs/src/sbin/fsck_ffs/fsck.h,v > retrieving revision 1.32 > diff -u -r1.32 fsck.h > --- sbin/fsck_ffs/fsck.h 1 Sep 2004 05:48:06 -0000 1.32 > +++ sbin/fsck_ffs/fsck.h 6 Sep 2004 00:41:31 -0000 > @@ -84,6 +84,8 @@ > #define DFOUND 04 /* directory found during descent */ > #define DCLEAR 05 /* directory is to be cleared */ > #define FCLEAR 06 /* file is to be cleared */ > +#define FZLINK 07 /* inode is file with a link count of zero */ > +#define DZLINK 10 /* inode is directory with a zero link count */ Just a minor note: 04, 05, 06, 07, are octals. I think DZLINK should be 010 and not 10 (which is decimal). From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 12:22: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 64EDF16A4CE for ; Mon, 6 Sep 2004 12:22:55 +0000 (GMT) Received: from Sammael.Blosphere.net (sammael.Blosphere.net [193.66.203.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B719243D2D for ; Mon, 6 Sep 2004 12:22:54 +0000 (GMT) (envelope-from sty@iki.fi) Received: from [172.16.1.170] (p5165-ipad27souka.saitama.ocn.ne.jp [220.104.75.165]) by Sammael.Blosphere.net (Postfix) with ESMTP id 48D01400BA for ; Mon, 6 Sep 2004 15:22:51 +0300 (EEST) Message-ID: <413C56B6.70508@iki.fi> Date: Mon, 06 Sep 2004 21:23:18 +0900 From: =?ISO-8859-1?Q?Tommi_L=E4tti?= User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4136CE19.5020804@iki.fi> <4136CF5A.5010600@iki.fi> In-Reply-To: <4136CF5A.5010600@iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: strange crashes 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, 06 Sep 2004 12:22:55 -0000 I was now able to get some backtraces from 2 separate crashes: This first one is when I was dd:ing a 37 gig file from a gdbe'd partition. --- clip --- Sammael [15:09] [/usr/obj/usr/src/sys/SAMMAEL]# gdb -k kernel.debug /var/crash/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... panic: Illegal sector state (JUNK ?) panic messages: --- panic: Illegal sector state (JUNK ?) syncing disks, buffers remaining... 3867 3867 3867 3867 3867 3867 3867 3867 3867 3867 3867 3867 3867 3867 3867 ad6: WARNING - READ_DMA interrupt was seen but timeout fired LBA=16215349 3867 3867 3867 3867 3867 giving up on 42 buffers Uptime: 1h42m40s ad6: WARNING - READ_DMA interrupt was seen but timeout fired LBA=16215349 Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- Reading symbols from /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /boot/kernel/daemon_saver.ko...done. Loaded symbols for /boot/kernel/daemon_saver.ko Reading symbols from /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/linux/linux.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) backtrace #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04c7477 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc04c77c8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc048d735 in g_bde_worker (arg=0x0) at /usr/src/sys/geom/bde/g_bde_work.c:605 #4 0xc04b30d4 in fork_exit (callout=0xc048d530 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 (kgdb) list *0xc048d530 0xc048d530 is in g_bde_worker (/usr/src/sys/geom/bde/g_bde_work.c:537). 532 * XXX: using a thread here is probably not needed. 533 */ 534 535 void 536 g_bde_worker(void *arg) 537 { 538 struct g_bde_softc *sc; 539 struct g_bde_work *wp; 540 struct g_geom *gp; 541 int busy, error; --- clip --- And this second one is from a yet another stange crash occured during the weekend. I have a nasty feeling now that the Mylex raid controller might be the culprit: --- clip --- Sammael [15:12] [/usr/obj/usr/src/sys/SAMMAEL]# gdb -k kernel.debug /var/crash/vmcore.1 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... panic: free: address 0xcf81f000(0xcf81f000) has not been allocated. panic messages: --- panic: free: address 0xcf81f000(0xcf81f000) has not been allocated. syncing disks, buffers remaining... 3867 3865 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 3864 giving up on 1725 buffers Uptime: 17h3m31s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- Reading symbols from /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /boot/kernel/daemon_saver.ko...done. Loaded symbols for /boot/kernel/daemon_saver.ko Reading symbols from /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/SAMMAEL/modules/usr/src/sys/modules/linux/linux.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) backtrace #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04c7477 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc04c77c8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc04bc2f7 in free (addr=0xcf81f000, type=0xc0658b00) at /usr/src/sys/kern/kern_malloc.c:306 #4 0xc047478f in mlx_enquire (sc=0xc43c4000, command=0, bufsize=12, complete=0xc0474290 ) at /usr/src/sys/dev/mlx/mlx.c:1559 #5 0xc0473bf4 in mlx_periodic (data=0xc43c4000) at /usr/src/sys/dev/mlx/mlx.c:1059 #6 0xc04d7d08 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:225 #7 0xc04b40e2 in ithread_loop (arg=0xc1913580) at /usr/src/sys/kern/kern_intr.c:544 #8 0xc04b30d4 in fork_exit (callout=0xc04b3f50 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 (kgdb) list *0xc0474290 0xc0474290 is in mlx_periodic_rebuild (/usr/src/sys/dev/mlx/mlx.c:1347). 1342 /******************************************************************************** 1343 * Handle check/rebuild operations in progress. 1344 */ 1345 static void 1346 mlx_periodic_rebuild(struct mlx_command *mc) 1347 { 1348 struct mlx_softc *sc = mc->mc_sc; 1349 struct mlx_rebuild_status *mr = (struct mlx_rebuild_status *)mc->mc_data; 1350 1351 switch(mc->mc_status) { (kgdb) list *0xc04b3f50 0xc04b3f50 is in ithread_loop (/usr/src/sys/kern/kern_intr.c:483). 478 /* 479 * This is the main code for interrupt threads. 480 */ 481 static void 482 ithread_loop(void *arg) 483 { 484 struct ithd *ithd; /* our thread context */ 485 struct intrhand *ih; /* and our interrupt handler chain */ 486 struct thread *td; 487 struct proc *p; --- clip --- any thoughts? -- br, Tommi From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 12:40: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 7AB7C16A4CE for ; Mon, 6 Sep 2004 12:40:05 +0000 (GMT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEFC743D31 for ; Mon, 6 Sep 2004 12:40:04 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.12.11/jtpda-5.4) with ESMTP id i86Cdqtx021849 for ; Mon, 6 Sep 2004 14:39:52 +0200 (CEST) X-Ids: 167 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) i86Ce1cP029566 for ; Mon, 6 Sep 2004 14:40:01 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.1/8.13.1/Submit) id i86Ce1nR029563; Mon, 6 Sep 2004 14:40:01 +0200 (MEST) (envelope-from arno) To: current@freebsd.org From: "Arno J. Klaassen" Date: 06 Sep 2004 14:40:01 +0200 Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at shiva.jussieu.fr with ID 413C5A98.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr Subject: BETA3 boot loader 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: Mon, 06 Sep 2004 12:40:05 -0000 On my of my systems (ASUS7N266) I cannot boot BETA3 (cvs sources from last night) : loader seems to load kernel and then spontaneously reboots. Moving /boot/loader.old to /boot/loader solves it. FYI, Arno From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:00: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 6D6CA16A4CE for ; Mon, 6 Sep 2004 13:00:46 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D8F643D31 for ; Mon, 6 Sep 2004 13:00:20 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I3M0071IESILZ@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Mon, 06 Sep 2004 15:00:19 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 06 Sep 2004 15:00:18 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92])i86D0IRA025278; Mon, 06 Sep 2004 15:00:18 +0200 (MEST) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id BEFC62846E; Mon, 06 Sep 2004 15:00:12 +0200 (CEST) Received: by gondor.middleearth (Postfix, from userid 1001) id DD777613A; Mon, 06 Sep 2004 15:00:11 +0200 (CEST) Date: Mon, 06 Sep 2004 15:00:11 +0200 From: Christian Brueffer In-reply-to: <413C56B6.70508@iki.fi> To: Tommi =?iso-8859-1?Q?L=E4tti?= Message-id: <20040906130011.GL66117@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=kERJ49nCKmnv470N; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.5.1i X-Operating-System: FreeBSD 5.2-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <4136CE19.5020804@iki.fi> <4136CF5A.5010600@iki.fi> <413C56B6.70508@iki.fi> cc: freebsd-current@freebsd.org Subject: Re: strange crashes 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, 06 Sep 2004 13:00:47 -0000 --kERJ49nCKmnv470N Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 06, 2004 at 09:23:18PM +0900, Tommi L=E4tti wrote: > I was now able to get some backtraces from 2 separate crashes: >=20 >=20 > This first one is when I was dd:ing a 37 gig file from a gdbe'd partition. >=20 > --- clip --- > Sammael [15:09] [/usr/obj/usr/src/sys/SAMMAEL]# gdb -k kernel.debug=20 > /var/crash/vmcore.0 > GNU gdb 5.2.1 (FreeBSD) > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-unknown-freebsd"... > panic: Illegal sector state (JUNK ?) > panic messages: > --- > panic: Illegal sector state (JUNK ?) >=20 I had this one before. I think I can reproduce here more easily with just trying to copy something off a dying gbde encrypted disc. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --kERJ49nCKmnv470N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBPF9bbHYXjKDtmC0RAgmJAKCQbO9zU+/AKCAKfZXo09dTzZGc7ACgwWqd ctEKO18Fgoufa9qcjOmShlc= =EsL/ -----END PGP SIGNATURE----- --kERJ49nCKmnv470N-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13:28: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 4834716A4CE; Mon, 6 Sep 2004 13:28:19 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A32943D60; Mon, 6 Sep 2004 13:28:18 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received-SPF: pass (eva.fit.vutbr.cz: domain of xdivac02@eva.fit.vutbr.cz designates 127.0.0.1 as permitted sender) receiver=eva.fit.vutbr.cz; client_ip=127.0.0.1; envelope-from=xdivac02@eva.fit.vutbr.cz; Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id i86DSDY6053425 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 15:28:13 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.12.11/8.12.5/Submit) id i86DSD64053423; Mon, 6 Sep 2004 15:28:13 +0200 (CEST) Date: Mon, 6 Sep 2004 15:28:13 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20040906132813.GA53245@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: mlaier@freebsd.org Subject: ftp-proxy@pf not working on recent current and/or RELENG_5 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, 06 Sep 2004 13:28:19 -0000 Hi, with this pf.conf and PROPERLY set up inetd I am not able to use ftp-proxy... it simply doesnt work and I am pretty sure it worked before. I see this on RELENG_5 and on -CURRENT too... If I am doing anything wrong pls tell me pf.conf: ext_if="vr0" int_if="xl0" #normalize packets scrub in all altq on $ext_if bandwidth 256Kb cbq queue {ssh_i web other} queue ssh_i bandwidth 25% cbq(borrow ecn) queue web bandwidth 25% cbq(borrow ecn) queue other bandwidth 50% cbq(borrow default ecn) #ftp redirection rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021 #nat nat on $ext_if from $int_if:network to any -> ($ext_if) #rules #default to block all block in on $ext_if all #pass all out while keeping state. and queue it pass out on $ext_if from any to any keep state queue other #queuing pass on $ext_if proto tcp from any to any port ssh keep state queue(ssh_i, other) pass out on $ext_if proto tcp from any to any port http keep state queue web #ftp proxy pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state queue other #allow icmp pass in on $ext_if inet proto icmp from any to any From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 13: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 7C80016A4CF for ; Mon, 6 Sep 2004 13:53:16 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 493DB43D3F for ; Mon, 6 Sep 2004 13:53:15 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 873C350B81 for ; Mon, 6 Sep 2004 22:53:13 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 0B95250B7E for ; Mon, 6 Sep 2004 22:53:12 +0900 (JST) Date: Mon, 06 Sep 2004 22:53:12 +0900 Message-ID: <7m3c1vv707.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: panic: sched_add: kse already in run queue 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, 06 Sep 2004 13:53:16 -0000 This is the current as of 2004.09.05.23.30.00+00 (just after Julian's sched_4bsd.c cleanup). I cannot break to the debugger so cannot get trace of this. ----- panic: sched_add: kse 0xc45692f4 (firefox-bin) already in run queue cpuid = 1 KDB: enter: panic ----- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Mon Sep 6 14:20: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 4827016A4CE for ; Mon, 6 Sep 2004 14:20:53 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 434E643D6E for ; Mon, 6 Sep 2004 14:20:50 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 68E8F304B; Mon, 6 Sep 2004 09:20:49 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05664-10; Mon, 6 Sep 2004 09:20:44 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id D04A83049; Mon, 6 Sep 2004 09:20:43 -0500 (CDT) Message-ID: <413C7230.8090607@veldy.net> Date: Mon, 06 Sep 2004 09:20:32 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <413B4660.6090203@veldy.net> <413B5361.9070201@DeepCore.dk> <413BBBC7.2000904@veldy.net> <413C0378.1010003@DeepCore.dk> In-Reply-To: <413C0378.1010003@DeepCore.dk> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7BF9DD4832A0C53D8E1ED6A2" X-Virus-Scanned: by amavisd-new at veldy.net cc: freebsd-current@freebsd.org Subject: Re: ATTN Soren: BETA3 still hangs on ATAPI DVD Detection during boot 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, 06 Sep 2004 14:20:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7BF9DD4832A0C53D8E1ED6A2 Content-Type: multipart/mixed; boundary="------------070101010107010501080700" This is a multi-part message in MIME format. --------------070101010107010501080700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Søren Schmidt wrote: > Thomas T. Veldhouse wrote: > >> You mentioned earlier to just copy the CURRENT files >> /usr/src/sys/dev/ata/* over into the 5.3-BETA and rebuild the kernel >> (GENERIC, no optimizations). I just did that today with the 19:30CDT >> CURRENT kernel sources and I am still seeing this hang. Should I be >> looking elsewhere for this fix (i.e. ACPI)? > > > That should do it yes, however if you are still experiencing > lockups/hangs you shoudl disable ATAPI DMA in loader.conf and see if > that helps. > Soren, Again, even with the new code, I experience a freeze ONLY during boot when it is detecting acd0. This does not happen when I boot verbosely. The drive works perfectly with DMA active (as UDMA33) once the machine is booted. I will attach the updated dmesg output, in case it changed after the ata update from CURRENT, but the device in question is this one: LITEON DVD-ROM LTD163/GDHJ. I also notice that the atapi reset with verbose logging on is 30us and then 40us, but when booting the default kernel (option 1), it is 30us and then 50us ... when it locks up solid. ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 30us ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 40us ata1-master: setting PIO4 on Intel ICH2 chip ata1-master: setting UDMA33 on Intel ICH2 chip ata1-slave: setting PIO4 on Intel ICH2 chip ata1-slave: setting UDMA33 on Intel ICH2 chip acd0: DVDROM drive at ata1 as master acd0: 512KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc Tom Veldhouse --------------070101010107010501080700 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.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. FreeBSD 5.3-BETA3 #0: Sun Sep 5 19:56:34 CDT 2004 root@cascade.veldy.net:/usr/src/sys/i386/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a2b000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a2b21c. Calibrating clock(s) ... i8254 clock: 1193179 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3049499900 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3049.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 536276992 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x000000001f640fff, 513900544 bytes (125464 pages) avail memory = 515112960 (491 MB) Table 'FACP' at 0xfd588 Table 'SSDT' at 0xfffe5e96 Table 'APIC' at 0xfd5fc MADT: Found table at 0xfd5fc MP Configuration Table version 1.4 found at 0xc00f0000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: disabled MADT: Found CPU APIC ID 3 ACPI ID 4: disabled ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbe8e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> random: io:
mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25308086) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fba30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 14 15 embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 2 12 A 0x62 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 A 0x60 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 B 0x61 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 C 0x62 3 4 5 6 7 9 10 11 14 15 slot 1 2 7 D 0x63 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 A 0x61 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 B 0x62 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 C 0x63 3 4 5 6 7 9 10 11 14 15 slot 2 2 8 D 0x60 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 A 0x62 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 B 0x63 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 C 0x60 3 4 5 6 7 9 10 11 14 15 slot 3 2 9 D 0x61 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 A 0x63 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 B 0x60 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 C 0x61 3 4 5 6 7 9 10 11 14 15 slot 4 2 10 D 0x62 3 4 5 6 7 9 10 11 14 15 embedded 2 1 A 0x63 3 4 5 6 7 9 10 11 14 15 embedded 2 1 B 0x62 3 4 5 6 7 9 10 11 14 15 embedded 2 1 C 0x60 3 4 5 6 7 9 10 11 14 15 embedded 2 2 A 0x62 3 4 5 6 7 9 10 11 14 15 embedded 2 2 B 0x61 3 4 5 6 7 9 10 11 14 15 embedded 2 2 C 0x63 3 4 5 6 7 9 10 11 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 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 ACPI timer looks GOOD min = 3, max = 3, width = 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=0x8086, dev=0x2530, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2532, revid=0x04 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244e, revid=0x04 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2440, revid=0x04 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x244b, revid=0x04 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ccf0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2443, revid=0x04 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xff800000-0xff9fffff pcib1: prefetched decode 0xe8000000-0xf7ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base f0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xf0000000-0xf7ffffff map[14]: type 4, range 32, base 0000ec00, size 8, enabled pcib1: device (null) requested decoded I/O range 0xec00-0xecff map[18]: type 1, range 32, base ff8f0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xff8f0000-0xff8fffff pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x1002, dev=0x4e44, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0183, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base e8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe8000000-0xefffffff map[14]: type 1, range 32, base ff8e0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xff8e0000-0xff8effff found-> vendor=0x1002, dev=0x4e64, revid=0x00 bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xff600000-0xff7fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: pci2: on pcib2 pci2: physical bus=2 map[20]: type 4, range 32, base 0000dce0, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdce0-0xdcff pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 19 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=1, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=19 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dcc0, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdcc0-0xdcdf pcib2: matched entry for 2.1.INTB pcib2: slot 1 INTB hardwired to IRQ 18 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=1, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=18 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6ffc00, size 8, enabled pcib2: device (null) requested decoded memory range 0xff6ffc00-0xff6ffcff pcib2: matched entry for 2.1.INTC pcib2: slot 1 INTC hardwired to IRQ 16 found-> vendor=0x1106, dev=0x3104, revid=0x51 bus=2, slot=1, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=16 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dca0, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdca0-0xdcbf pcib2: matched entry for 2.2.INTA pcib2: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=2, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dc80, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdc80-0xdc9f pcib2: matched entry for 2.2.INTB pcib2: slot 2 INTB hardwired to IRQ 17 found-> vendor=0x1106, dev=0x3038, revid=0x50 bus=2, slot=2, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6ff800, size 8, enabled pcib2: device (null) requested decoded memory range 0xff6ff800-0xff6ff8ff pcib2: matched entry for 2.2.INTC pcib2: slot 2 INTC hardwired to IRQ 19 found-> vendor=0x1106, dev=0x3104, revid=0x51 bus=2, slot=2, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=19 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base ff6fe000, size 12, enabled pcib2: device (null) requested decoded memory range 0xff6fe000-0xff6fefff map[14]: type 4, range 32, base 0000dc70, size 4, enabled pcib2: device (null) requested decoded I/O range 0xdc70-0xdc7f pcib2: matched entry for 2.8.INTA pcib2: slot 8 INTA hardwired to IRQ 17 found-> vendor=0x14e4, dev=0x4212, revid=0x02 bus=2, slot=8, func=0 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc40, size 5, enabled pcib2: device (null) requested decoded I/O range 0xdc40-0xdc5f pcib2: matched entry for 2.9.INTA pcib2: slot 9 INTA hardwired to IRQ 18 found-> vendor=0x1102, dev=0x0002, revid=0x0a bus=2, slot=9, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=18 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc68, size 3, enabled pcib2: device (null) requested decoded I/O range 0xdc68-0xdc6f found-> vendor=0x1102, dev=0x7002, revid=0x0a bus=2, slot=9, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ff6fd000, size 12, enabled pcib2: device (null) requested decoded memory range 0xff6fd000-0xff6fdfff map[14]: type 4, range 32, base 0000dc00, size 6, enabled pcib2: device (null) requested decoded I/O range 0xdc00-0xdc3f map[18]: type 1, range 32, base ff6c0000, size 17, enabled pcib2: device (null) requested decoded memory range 0xff6c0000-0xff6dffff pcib2: matched entry for 2.12.INTA pcib2: slot 12 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1229, revid=0x10 bus=2, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 uhci0: port 0xdce0-0xdcff irq 19 at device 1.0 on pci2 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdce0 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 uscanner0: Visioneer USB Scanner, rev 1.10/1.00, addr 2 uhci1: port 0xdcc0-0xdcdf irq 18 at device 1.1 on pci2 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdcc0 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 pci2: at device 1.2 (no driver attached) uhci2: port 0xdca0-0xdcbf irq 18 at device 2.0 on pci2 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdca0 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 ugen0: Logitech Logitech Extreme 3D Pro, rev 1.10/35.00, addr 2 uhci3: port 0xdc80-0xdc9f irq 17 at device 2.1 on pci2 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xdc80 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 pci2: at device 2.2 (no driver attached) pci2: at device 8.0 (no driver attached) pci2: at device 9.0 (no driver attached) pci2: One of the paragraphs you appear not to have quoted from my e-mail was this one: % One nice thing about using this experimental code is that I hope it will % allow us to reason more effectively about the extent to which improving % per-cpu data structures improves efficiency -- I can now much more % easily say "OK, what happens if eliminate the cost of locking for common % place mbuf allocation/free". I've also started looking at per-interface % caches based on the same model, which has some similar limitations (but % also some similar benefits), such as stuffing per-interface uma caches % in struct ifnet. I.e., using per-thread UMA caches is a 30-60 minute hack that allows me to explore and measure the performance benefits (and costs) of several different approaches, including per-cpu, per-thread, and per-data structure/object caching without doing the full implementation up front. Per-thread caching, for example, can simulate the effects of non-preemption and mutex avoidance in micro-benchmarking, although in the general case under macro-benchmark perspective it suffers from a number of problems (including the draining, balancing, and extra storage cost issues). I didn't attempt to address these problems under the assumption that the current implementation is a tool for exploring performance, not something to actually use. In doing so, my hope was to identify which areas will offer the most immediate performance benefits, be it simply cutting down on costly operations (such as the entropy harvesting code for Yarrow which appears to have found its way into our interrupt path), rethinking locking strategies, optimizing out/coalescing locking, optimizing out excess memory allocation, optimizing synchronization primitives with the same semantics, changing synchronization assumptions to offer weaker/stronger semantics, etc. Right now, though, the greatest obstacle in my immediate path appears to be a bug in the current version of the if_em driver that causes the interfaces on my test box to wedge under even moderate load. The if_em cards I have on other machines seem not to do this, which suggests a driver weirdness with this particular version of the chipset/card. Go figure... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 06:37: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 427C116A4CE for ; Thu, 9 Sep 2004 06:37:48 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F82C43D3F for ; Thu, 9 Sep 2004 06:37:47 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C5IYz-0000JR-1n; Thu, 09 Sep 2004 10:37:45 +0400 From: Vladimir Grebenschikov To: Eric Anholt In-Reply-To: <1094686987.871.10.camel@leguin> References: <1094502674.2668.4.camel@localhost> <1094631615.860.7.camel@leguin> <1094634253.2172.13.camel@localhost> <1094686987.871.10.camel@leguin> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Thu, 09 Sep 2004 10:37:44 +0400 Message-Id: <1094711864.1043.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Jose M Rodriguez cc: "current@freebsd.org" Subject: Re: ATI Radeon LY Mobility M6: DRM does not work - locking issue ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 06:37:48 -0000 =F7 =D3=D2, 08/09/2004 =D7 16:43 -0700, Eric Anholt =D0=C9=DB=C5=D4: > On Wed, 2004-09-08 at 05:23, Jose M Rodriguez wrote: > > On Wed, 08 Sep 2004 13:04:13 +0400, Vladimir Grebenschikov =20 > > wrote: > >=20 > > > =F7 =D3=D2, 08/09/2004 =D7 01:20 -0700, Eric Anholt =D0=C9=DB=C5=D4: > > >> On Mon, 2004-09-06 at 13:31, Vladimir Grebenschikov wrote: > > >> > Hi > > >> > > > >> > 6-CURRENT > > >> > > > >> > from dmesg: > > >> > > > >> > drm0: port 0x3000-0x30ff mem > > >> > 0xd0100000-0xd010ffff,0xd8000000-0xdfffffff irq 9 at device 0.0 on= =20 > > >> pci1 > > >> > info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 > > >> > error: [drm:pid2477:radeon_cp_init] *ERROR* radeon_cp_init called > > >> > without lock held > > >> > error: [drm:pid2477:radeon_unlock] *ERROR* Process 2477 using kern= el > > >> > context 0 > > >> > > >> If you look in your dmesg, does agp initialization come before or af= ter > > >> the drm? This sure looks like the symptoms of agp initialization co= ming > > >> after (or not at all), but if you say your agp is loaded and attache= d, > > >> I'm not sure how that would happen. > > > > > > dmesg: > > > > > > drm0: port 0x3000-0x30ff mem > > > 0xd0100000-0xd010ffff,0xd8000000-0xdfffffff irq 9 at device 0.0 on pc= i1 > > > info: [drm] AGP at 0xe0000000 256MB > > > info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 > > > > > > I have solved problem, it need to make depth 16 or there is no enough > > > memory to serve direct rendering on 1400x1050 screen with 24 bpp. > > > > >=20 > > Get an X -configure and check driver options. > > You may need: > > Options "AGPSize" "256" # AGP Aperture size. MUST fit in bios setting= s >=20 > This won't affect his problem, since only command buffers (and maybe > textures -- I don't remember the status of our R100 driver) get > allocated from AGP, and not the front/back/depth. It will also wire > 256MB of memory for essentially no purpose at all. Yes, it does not helps, with 256 it makes mess on X start, and freezes console, with 64 it allocates 64 Mb, mostly for textures: (II) RADEON(0): [agp] Mode 0x1f000217 [AGP 0x0000/0x0000; Card 0x1002/0x4c59] (II) RADEON(0): [agp] 65536 kB allocated with handle 0xc1e9c740 (II) RADEON(0): [agp] ring handle =3D 0xe0000000 (II) RADEON(0): [agp] Ring mapped at 0x29422000 (II) RADEON(0): [agp] ring read ptr handle =3D 0xe0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x282cf000 (II) RADEON(0): [agp] vertex/indirect buffers handle =3D 0xe0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x29523000 (II) RADEON(0): [agp] GART texture map handle =3D 0xe0302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x29723000 (II) RADEON(0): [drm] register handle =3D 0xd0100000 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 64 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 61 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1408,5957) (II) RADEON(0): Reserved area from (0,1050) to (1408,1052) (II) RADEON(0): Largest offscreen area available: 1408 x 4905 When with default value it is: (II) RADEON(0): [agp] Mode 0x1f000217 [AGP 0x0000/0x0000; Card 0x1002/0x4c59] (II) RADEON(0): [agp] 8192 kB allocated with handle 0xc1bba000 (II) RADEON(0): [agp] ring handle =3D 0xe0000000 (II) RADEON(0): [agp] Ring mapped at 0x29422000 (II) RADEON(0): [agp] ring read ptr handle =3D 0xe0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x282cf000 (II) RADEON(0): [agp] vertex/indirect buffers handle =3D 0xe0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x29523000 (II) RADEON(0): [agp] GART texture map handle =3D 0xe0302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x29723000 (II) RADEON(0): [drm] register handle =3D 0xd0100000 (II) RADEON(0): [drm] register handle =3D 0xd0100000 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1408,5957) (II) RADEON(0): Reserved area from (0,1050) to (1408,1052) (II) RADEON(0): Largest offscreen area available: 1408 x 4905 > > Options "AGPMode" "4" # Set AGP Speed DANGEROUS but very effective >=20 > I would be interested in reports of "very effective." The effectiveness > that I've heard from anyone so far is "not measurable" to 1-2%. Seems to be enabled successful (both mode 4 and fast-write): (**) RADEON(0): Using AGP 4x mode (**) RADEON(0): Enabling AGP Fast Write (II) RADEON(0): Depth moves disabled by default But can't see any difference with glxgears as fps metter. it is gives about 470 fps with default window size on=20 ATI M6 16Mb + PentiumM 1700MHz --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 06:48: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 BC95D16A4CE for ; Thu, 9 Sep 2004 06:48:04 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60E3F43D3F for ; Thu, 9 Sep 2004 06:48:04 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id i896lwX04825 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Thu, 9 Sep 2004 02:48:03 -0400 In-Reply-To: <20040905124526.F15143@midi.ihme.net> References: <20040905124526.F15143@midi.ihme.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <24D02CEA-022C-11D9-870B-000A95C4D7BC@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: Suleiman Souhlal Date: Thu, 9 Sep 2004 02:47:40 -0400 To: =?ISO-8859-1?Q?Markus_H=E4stbacka?= X-Mailer: Apple Mail (2.619) cc: freebsd-current@FreeBSD.org Subject: Re: Sound performance problems in FreeBSD 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, 09 Sep 2004 06:48:04 -0000 Hello, On Sep 5, 2004, at 5:56 AM, Markus H=E4stbacka wrote: > Hello list, I've experienced sound performance issues from the very=20 > first day I tested 5.x. The problem was that sound skipped whatever I=20= > did. Now I've reduced the problem a bit with changing my kernel config=20= > (No, any debug option isn't on or haven't ever been on when I've=20 > tested sound performance). After I recompiled the new kernel the sound=20= > didn't skip anymore, but now after 10 hour uptime and 5 hours of mp3=20= > playing the skipping is back. The skipping is like every second=20 > there's a weird noise if I listen to something, like the track would=20= > go slower for 2/10 seconds of every second, you can imagine how=20 > annoying this can be. FYI, after a few IRC discussions with Markus, we've discovered that=20= turning off the memory part of Gnome's System Monitor applet, would get=20= rid of the skips. I believe the problem is that both sysctl and the=20 sound drivers are Giant-locked, and so there is some contention. An=20 easy way to reproduce these skips is to run `while true; do sysctl=20 vm.vmtotal; done`, while playing an mp3. So, it would be nice to have giant-free sysctl and/or sound drivers..=20= :) Bye -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 06:50: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 7F90F16A4CE for ; Thu, 9 Sep 2004 06:50:10 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE77343D64 for ; Thu, 9 Sep 2004 06:50:09 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C5Iky-0000LC-TW; Thu, 09 Sep 2004 10:50:08 +0400 From: Vladimir Grebenschikov To: Eric Anholt In-Reply-To: <1094685817.871.4.camel@leguin> References: <1094502674.2668.4.camel@localhost> <1094631615.860.7.camel@leguin> <1094634253.2172.13.camel@localhost> <1094685817.871.4.camel@leguin> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Thu, 09 Sep 2004 10:50:08 +0400 Message-Id: <1094712608.1043.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: Re: ATI Radeon LY Mobility M6: DRM does not work - locking issue ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 06:50:10 -0000 =F7 =D3=D2, 08/09/2004 =D7 16:23 -0700, Eric Anholt =D0=C9=DB=C5=D4: > On Wed, 2004-09-08 at 02:04, Vladimir Grebenschikov wrote: > > =F7 =D3=D2, 08/09/2004 =D7 01:20 -0700, Eric Anholt =D0=C9=DB=C5=D4: > > > On Mon, 2004-09-06 at 13:31, Vladimir Grebenschikov wrote: > > > > Hi > > > >=20 > > > > 6-CURRENT > > > >=20 > > > > from dmesg: > > > >=20 > > > > drm0: port 0x3000-0x30ff mem > > > > 0xd0100000-0xd010ffff,0xd8000000-0xdfffffff irq 9 at device 0.0 on = pci1 > > > > info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 > > > > error: [drm:pid2477:radeon_cp_init] *ERROR* radeon_cp_init called > > > > without lock held > > > > error: [drm:pid2477:radeon_unlock] *ERROR* Process 2477 using kerne= l > > > > context 0 > > >=20 > > > If you look in your dmesg, does agp initialization come before or aft= er > > > the drm? This sure looks like the symptoms of agp initialization com= ing > > > after (or not at all), but if you say your agp is loaded and attached= , > > > I'm not sure how that would happen. > >=20 > > dmesg: > >=20 > > drm0: port 0x3000-0x30ff mem > > 0xd0100000-0xd010ffff,0xd8000000-0xdfffffff irq 9 at device 0.0 on pci1 > > info: [drm] AGP at 0xe0000000 256MB > > info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 > >=20 > > I have solved problem, it need to make depth 16 or there is no enough > > memory to serve direct rendering on 1400x1050 screen with 24 bpp. > >=20 > > and both modules should be loaded before X start > >=20 > > with 16 bpp: > > (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2f20000 > > (II) RADEON(0): [drm] mapped SAREA 0xc2f20000 to 0x283c2000 > > (II) RADEON(0): [drm] framebuffer handle =3D 0xd8000000 > > (II) RADEON(0): [drm] added 1 reserved context for kernel > > (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x0000/0x0000; Card > > 0x1002/0x4c59] > > (II) RADEON(0): [agp] 8192 kB allocated with handle 0xc1e8fac0 > > (II) RADEON(0): [agp] ring handle =3D 0xe0000000 > > (II) RADEON(0): [agp] Ring mapped at 0x29422000 > > (II) RADEON(0): [agp] ring read ptr handle =3D 0xe0101000 > > (II) RADEON(0): [agp] Ring read ptr mapped at 0x282cf000 > > (II) RADEON(0): [agp] vertex/indirect buffers handle =3D 0xe0102000 > > (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x29523000 > > (II) RADEON(0): [agp] GART texture map handle =3D 0xe0302000 > > (II) RADEON(0): [agp] GART Texture map mapped at 0x29723000 > > (II) RADEON(0): [drm] register handle =3D 0xd0100000 > > (II) RADEON(0): [dri] Visual configs initialized > > (II) RADEON(0): CP in BM mode > > (II) RADEON(0): Using 8 MB GART aperture > > (II) RADEON(0): Using 1 MB for the ring buffer > > (II) RADEON(0): Using 2 MB for vertex/indirect buffers > > (II) RADEON(0): Using 5 MB for GART textures > > (II) RADEON(0): Memory manager initialized to (0,0) (1408,5957) > > (II) RADEON(0): Reserved area from (0,1050) to (1408,1052) > > (II) RADEON(0): Largest offscreen area available: 1408 x 4905 > > (II) RADEON(0): Will use back buffer at offset 0x5b8000 > > (II) RADEON(0): Will use depth buffer at offset 0x88a000 > > (II) RADEON(0): Will use 4736 kb for textures at offset 0xb60000 > > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA > > Screen to screen bit blits > > Solid filled rectangles > > 8x8 mono pattern filled rectangles > > Indirect CPU to Screen color expansion > > Solid Lines > > Dashed Lines > > Scanline Image Writes > > Offscreen Pixmaps > > Setting up tile and stipple cache: > > 32 128x128 slots > > 32 256x256 slots > > 15 512x512 slots > > (II) RADEON(0): Acceleration enabled > > (=3D=3D) RADEON(0): Backing store disabled > > (=3D=3D) RADEON(0): Silken mouse enabled > > (II) RADEON(0): Using hardware cursor (scanline 1052) > > (II) RADEON(0): Largest offscreen area available: 1408 x 4899 > > (II) RADEON(0): X context handle =3D 0x00000001 > > (II) RADEON(0): [drm] installed DRM signal handler > > (II) RADEON(0): [DRI] installation complete > > (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers > > (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers > > (II) RADEON(0): [drm] dma control initialized, using IRQ 9 > > (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 > > (II) RADEON(0): Direct rendering enabled > >=20 > > With 24 bpp: > > (WW) RADEON(0): Static buffer allocation failed -- need at least 17325 > > kB video memory > > (II) RADEON(0): Memory manager initialized to (0,0) (1408,2978) > > (II) RADEON(0): Reserved area from (0,1050) to (1408,1052) > > (II) RADEON(0): Largest offscreen area available: 1408 x 1926 > > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) > > Screen to screen bit blits > > Solid filled rectangles > > 8x8 mono pattern filled rectangles > > Indirect CPU to Screen color expansion > > Solid Lines > > Dashed Lines > > Scanline Image Writes > > Offscreen Pixmaps > > Setting up tile and stipple cache: > > 32 128x128 slots > > 13 256x256 slots > > 5 512x512 slots > > (II) RADEON(0): Acceleration enabled > > (=3D=3D) RADEON(0): Backing store disabled > > (=3D=3D) RADEON(0): Silken mouse enabled > > (II) RADEON(0): Using hardware cursor (scanline 1052) > > (II) RADEON(0): Largest offscreen area available: 1408 x 1923 > > (II) RADEON(0): Direct rendering disabled > >=20 > >=20 > > So how required memory calculated ? > >=20 > > VRAM =3D width * height * 24 / 8 =3D 4368000 =3D 4266 Kb=20 > > but it wants 17325 ... >=20 > Your card can't accelerate 24bpp for anything more complicated than 2d > source copies, only 24/32 depth with 32 bpp, so you're actually at > 32bpp. Also, front, back, and depth buffers are allocated statically at > startup all with the same bpp, so there are 3 buffers. So, width * > height * 4 * 3 is how much you need. I see, options are: lower resolution for OpenGL apps or bpp 16 for OpenGL apps (there is no vram upgrades for my notebook) Also, as I understand OpenGL can't be turned on while changing physical resolution by Ctrl-Alt-+/- on the fly ? > (These logs posted here are different from what was initially posted.=20 > I'm still curious as to what was happening previously.) Actually I not seen more warnings as in initial post. Something was fixed not know what exactly, may be fresh -CURRENT helps. --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 06:58: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 CCEB216A4CF for ; Thu, 9 Sep 2004 06:58:02 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id E272B43D41 for ; Thu, 9 Sep 2004 06:58:00 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 45215 invoked by uid 0); 9 Sep 2004 06:54:30 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 9 Sep 2004 06:54:30 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 587B61315B6; Thu, 9 Sep 2004 14:57:57 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00754-10; Thu, 9 Sep 2004 14:57:48 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 46E041315AD; Thu, 9 Sep 2004 14:57:48 +0800 (CST) Date: Thu, 9 Sep 2004 14:57:48 +0800 From: Xin LI To: current@FreeBSD.org Message-ID: <20040909065748.GA3065@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.2-delphij FreeBSD 5.2-delphij #0: Tue Aug 17 14:22:25 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: re@FreeBSD.org Subject: [PATCH] Restore lost NetBSD tag in rc.d/ipmon 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, 09 Sep 2004 06:58:02 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, -CURRENT While I am looking at the recent NetBSD RCng changes I by chance found that NetBSD header tag was not complete in etc/rc.d/ipmon, which could be brought back with the following patch: Index: ipmon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/fcvs/src/etc/rc.d/ipmon,v retrieving revision 1.11 diff -u -r1.11 ipmon --- ipmon 23 Apr 2004 15:43:13 -0000 1.11 +++ ipmon 9 Sep 2004 06:41:58 -0000 @@ -1,6 +1,6 @@ #!/bin/sh # -# $NetBSD: ipmon,v 2002/04/18 05:02:01 lukem Exp $ +# $NetBSD: ipmon,v 1.9 2002/04/18 05:02:01 lukem Exp $ # $FreeBSD: src/etc/rc.d/ipmon,v 1.11 2004/04/23 15:43:13 darrenr Exp $ # =20 Given that this is a trivial change, will someone please consider commit it so it will have a chance of being MFC'ed into the RELENG_5 (and the 5.3-RELEASE)? Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBP/7sOfuToMruuMARAhYjAJ465MQE822HHEWgm1rT6RiinU9gOACdEnow AgjtrKQIKfq483KfB7EXTcg= =nRAg -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 07:19: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 B556F16A4CE for ; Thu, 9 Sep 2004 07:19:14 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6284043D2D for ; Thu, 9 Sep 2004 07:19:14 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C5JD7-0000Qs-Ab; Thu, 09 Sep 2004 11:19:13 +0400 From: Vladimir Grebenschikov To: Jose M Rodriguez In-Reply-To: References: <1094502674.2668.4.camel@localhost> <1094631615.860.7.camel@leguin> <1094634253.2172.13.camel@localhost> <1094686987.871.10.camel@leguin> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Thu, 09 Sep 2004 11:19:12 +0400 Message-Id: <1094714352.1043.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: Re: ATI Radeon LY Mobility M6: DRM does not work - locking issue ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 07:19:14 -0000 =F7 =DE=D4, 09/09/2004 =D7 08:55 +0200, Jose M Rodriguez =D0=C9=DB=C5=D4: > On Thu, 09 Sep 2004 10:37:44 +0400, Vladimir Grebenschikov = =20 > wrote: >=20 > > =F7 =D3=D2, 08/09/2004 =D7 16:43 -0700, Eric Anholt =D0=C9=DB=C5=D4: > >> On Wed, 2004-09-08 at 05:23, Jose M Rodriguez wrote: > >> > On Wed, 08 Sep 2004 13:04:13 +0400, Vladimir Grebenschikov =20 > >> > >> > wrote: > >> > ... > > > >> > Options "AGPMode" "4" # Set AGP Speed DANGEROUS but very effecti= ve > >> > >> I would be interested in reports of "very effective." The effectivene= ss > >> that I've heard from anyone so far is "not measurable" to 1-2%. > > > > Seems to be enabled successful (both mode 4 and fast-write): > > > > (**) RADEON(0): Using AGP 4x mode > > (**) RADEON(0): Enabling AGP Fast Write > > (II) RADEON(0): Depth moves disabled by default > > > > But can't see any difference with glxgears as fps metter. > > it is gives about 470 fps with default window size on > > ATI M6 16Mb + PentiumM 1700MHz > > > No. you need textures, not 3D. 3D commands can't waste I/O bandwirth. Ok, can you advise simple tool to make tests (I know there is GL games, but may be something simplier) ? > But, after a closer look, I don't think you can take any significative =20 > advantage. >=20 > Try adjust your bios AGP aperture zise (2xram, 32MB). =20 Unfortunately I have no video subsystem setup options in BIOS. Option "AGPSize" "64"=20 works but not increase 16Mb limit for static buffer > And even not =20 > loading glx & dri modules. Not helps, still=20 (WW) RADEON(0): Static buffer allocation failed -- need at least 17325 kB video memory > I've got this with 32 Mb. I think it may be possible with 16. >=20 > Fell free to send a full X log on private mail. Ok, will send you logs by separate private mail. > -- > josemi >=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 07:59: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 9CF7816A4CE for ; Thu, 9 Sep 2004 07:59:27 +0000 (GMT) Received: from ei.bzerk.org (ei.xs4all.nl [213.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AC2843D46 for ; Thu, 9 Sep 2004 07:59:27 +0000 (GMT) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.13.1/8.12.10) with ESMTP id i897xVNe073593 for ; Thu, 9 Sep 2004 09:59:32 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.13.1/8.13.1/Submit) id i897xUYC073556 for freebsd-current@freebsd.org; Thu, 9 Sep 2004 09:59:30 +0200 (CEST) (envelope-from mail25@bzerk.org) X-Authentication-Warning: ei.bzerk.org: bulk set sender to mail25@bzerk.org using -f Date: Thu, 9 Sep 2004 09:59:29 +0200 From: Ruben de Groot To: freebsd-current@freebsd.org Message-ID: <20040909075928.GA50494@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: release build breaks in src/release/scripts/split-file.sh 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, 09 Sep 2004 07:59:27 -0000 I can't successfully build a release of RELENG_5 on my build machine (releng_5_2, releng_5_1 and releng_4 are OK) because of an issue with /bin/sh manifesting itself in the split-file.sh script. Here's the problem: $ uname -r # this is the build machine 5.1-RELEASE-p16 $ i=1 $ i=$((i + 1)) arith: syntax error: "i + 1" $ uname -r 5.3-ALPHA $ i=1 $ i=$((i + 1)) $ echo $i 2 Is this a known issue and has anyone got a workaround for this (I can't upgrade the build machine, at least not a.t.m.) thanks, Ruben From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08:11: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 26E2516A4CE for ; Thu, 9 Sep 2004 08:11:18 +0000 (GMT) Received: from smtp.easystreet.com (smtp.easystreet.com [69.30.22.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F33EC43D5A for ; Thu, 9 Sep 2004 08:11:17 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from [192.168.0.103] (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.easystreet.com (Postfix) with ESMTP id 06E866DC00D; Thu, 9 Sep 2004 00:03:48 -0700 (PDT) From: Eric Anholt To: vova@fbsd.ru In-Reply-To: <1094714352.1043.28.camel@localhost> References: <1094502674.2668.4.camel@localhost> <1094631615.860.7.camel@leguin> <1094634253.2172.13.camel@localhost> <1094714352.1043.28.camel@localhost> Content-Type: text/plain; charset=koi8-r Message-Id: <1094717476.4554.14.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 01:11:17 -0700 Content-Transfer-Encoding: 8bit cc: Jose M Rodriguez cc: "current@freebsd.org" Subject: Re: ATI Radeon LY Mobility M6: DRM does not work - locking 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: Thu, 09 Sep 2004 08:11:18 -0000 On Thu, 2004-09-09 at 00:19, Vladimir Grebenschikov wrote: > ÷ ÞÔ, 09/09/2004 × 08:55 +0200, Jose M Rodriguez ÐÉÛÅÔ: > > On Thu, 09 Sep 2004 10:37:44 +0400, Vladimir Grebenschikov > > wrote: > > > > > ÷ ÓÒ, 08/09/2004 × 16:43 -0700, Eric Anholt ÐÉÛÅÔ: > > >> On Wed, 2004-09-08 at 05:23, Jose M Rodriguez wrote: > > >> > On Wed, 08 Sep 2004 13:04:13 +0400, Vladimir Grebenschikov > > >> > > >> > wrote: > > >> > ... > > > > > >> > Options "AGPMode" "4" # Set AGP Speed DANGEROUS but very effective > > >> > > >> I would be interested in reports of "very effective." The effectiveness > > >> that I've heard from anyone so far is "not measurable" to 1-2%. > > > > > > Seems to be enabled successful (both mode 4 and fast-write): > > > > > > (**) RADEON(0): Using AGP 4x mode > > > (**) RADEON(0): Enabling AGP Fast Write > > > (II) RADEON(0): Depth moves disabled by default > > > > > > But can't see any difference with glxgears as fps metter. > > > it is gives about 470 fps with default window size on > > > ATI M6 16Mb + PentiumM 1700MHz > > > > > No. you need textures, not 3D. 3D commands can't waste I/O bandwirth. > > Ok, can you advise simple tool to make tests (I know there is GL games, > but may be something simplier) ? Commands do use bandwidth -- remember the mapping of"vertex/indirect and ring buffers in the Xorg.0.log? Those are in AGP. Now, let's take for example ipers. On my highly untuned system, I'm seeing 400,000 polys/sec. Each vertex has at least 3 coordinates plus two texture coordinates, and I bet a color as well, so let's say (8 * 4) bytes/vert * 4 vert/poly (I think it's drawing quads) * > 400,000 polys/sec. That's 51MB/sec -- not that big compared to even my 1x AGP, and this is an app designed to spew lots of vertices, but still is bandwidth used. And that's with (I'm pretty sure) a bad compile of Mesa, and we've had to disable some of the optimizations for producing vertices quickly in exchange for new features (3d textures). However, as always, glxgears is still the wrong thing to test with. > > And even not > > loading glx & dri modules. > > Not helps, still > (WW) RADEON(0): Static buffer allocation failed -- need at least 17325 > kB video memory Sounds like you made a mistake in configuration -- that only happens if the DRI was enabled. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08: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 5925216A4CE for ; Thu, 9 Sep 2004 08:24:08 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01A3F43D4C for ; Thu, 9 Sep 2004 08:24:07 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id i898O4Eg010775 for ; Thu, 9 Sep 2004 10:24:05 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <41401326.90200@withagen.nl> Date: Thu, 09 Sep 2004 10:24:06 +0200 From: Willem Jan Withagen 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: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Still getting Signal 6 with BETA3 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, 09 Sep 2004 08:24:08 -0000 Hi, I've been away for a week, so I've missed a part of the discussion on signal 6, but I'm still getting them. Running AMD64 on dual opteron with 1 Gb. Anything I can do to help fix this?? I also found a panic on my screen this morning but I'll put that in another thread. --WjW After make -j 32 buildworld: cc -pipe -g -DTERMIOS -DANSI_SOURCE -I/home2/src/secure/lib/libcrypto/../../../ crypto/openssl -I/home2/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/home2/src/secure/lib/libcrypto -DOPENSSL_THREADS -DOPENSSL_NO_IDEA -D NO_IDEA -c /home2/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/sha/s ha1_one.c cc: Internal error: Abort trap (program as) Please submit a full bug report. See for instructions. cc: Internal error: Abort trap (program as) Please submit a full bug report. See for instructions. cc: Internal error: Abort trap (program as) Please submit a full bug report. See for instructions. Abort trap Abort trap Abort trap cc: Internal error: Abort trap (program as) Please submit a full bug report. See for instructions. Abort trap Abort trap *** Signal 6 *** Error code 134 *** Error code 134 *** Error code 1 *** Error code 134 *** Error code 134 *** Error code 134 *** Error code 1 *** Error code 1 *** Error code 1 cc -pipe -g -DTERMIOS -DANSI_SOURCE -I/home2/src/secure/lib/libcrypto/../../../ crypto/openssl -I/home2/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/home2/src/secure/lib/libcrypto -DOPENSSL_THREADS -DOPENSSL_NO_IDEA -D NO_IDEA -c /home2/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/sha/s ha1dgst.c 10 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08:25: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 991E616A4CE; Thu, 9 Sep 2004 08:25:30 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01C0443D4C; Thu, 9 Sep 2004 08:25:30 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id C94FED424F; Thu, 9 Sep 2004 10:25:28 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id AC94B8AB4C; Thu, 9 Sep 2004 10:25:28 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 925BE8AA76; Thu, 9 Sep 2004 10:25:28 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 6D347D424F; Thu, 9 Sep 2004 10:25:28 +0200 (CEST) Received: from igor.q.local (igor [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i898PSTH011371; Thu, 9 Sep 2004 10:25:28 +0200 (CEST) (envelope-from q@igor.q.local) Received: from igor.q.local (localhost [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id i898PRum027679; Thu, 9 Sep 2004 10:25:27 +0200 (CEST) (envelope-from q@igor.q.local) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id i898PQNs027678; Thu, 9 Sep 2004 10:25:26 +0200 (CEST) (envelope-from q) Date: Thu, 9 Sep 2004 10:25:25 +0200 From: Ulrich Spoerlein To: Suleiman Souhlal Message-ID: <20040909082525.GA778@galgenberg.net> Mail-Followup-To: Suleiman Souhlal , Markus =?iso-8859-15?Q?H=E4stbacka?= , freebsd-current@FreeBSD.org References: <20040905124526.F15143@midi.ihme.net> <24D02CEA-022C-11D9-870B-000A95C4D7BC@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <24D02CEA-022C-11D9-870B-000A95C4D7BC@FreeBSD.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-current@FreeBSD.org cc: Markus =?iso-8859-15?Q?H=E4stbacka?= Subject: Re: Sound performance problems in FreeBSD 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, 09 Sep 2004 08:25:30 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 09.09.2004 at 02:47:40 -0400, Suleiman Souhlal wrote: > FYI, after a few IRC discussions with Markus, we've discovered that=20 > turning off the memory part of Gnome's System Monitor applet, would get= =20 > rid of the skips. I believe the problem is that both sysctl and the=20 > sound drivers are Giant-locked, and so there is some contention. An=20 > easy way to reproduce these skips is to run `while true; do sysctl=20 > vm.vmtotal; done`, while playing an mp3. Not repdrocueable here on 5.3-BETA3. Even extracting the Mozilla sources no longer produces skips ind mp3 playback. pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff40= 0-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: % cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xb800, 0xbc40 irq 5 bufsz 16384 kld snd= _ich (1p/1r/4v channels duplex default) Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBQBN1mArGtfDbn0QRArmmAKCQUlyxmWI6je8i+aCt6XmmmrIVCQCgrg4G cFe6ow+n5IwNCtwnBnBm70U= =1N2o -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08:26: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 C9F0316A4CE for ; Thu, 9 Sep 2004 08:26:18 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3ED43D5D for ; Thu, 9 Sep 2004 08:26:18 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id i898QGEg010886 for ; Thu, 9 Sep 2004 10:26:17 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <414013AA.6060908@withagen.nl> Date: Thu, 09 Sep 2004 10:26:18 +0200 From: Willem Jan Withagen 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: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: spin lock sched lock held by 0xffffff007b7d2940 for > 5 seconds 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, 09 Sep 2004 08:26:18 -0000 Found a panic on my bos this morning: spin lock sched lock held by 0xffffff007b7d2940 for > 5 seconds panic: spin lock held too long cpuid = 1 KDB: stack backtrace: kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d1 _mtx_lock_spin() at _mtx_lock_spin+0xd0 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0xcc hardclock_process() at hardclock_process+0x47 forwarded_hardclock() at forwarded_hardclock+0x21 Xhardclock() at Xhardclock+0x76 tc_windup() at tc_windup+0x113 tc_setclock() at tc_setclock+0xc7 settime() at settime+0x160 clock_settime() at clock_settime+0x87 syscall() at syscall+0x320 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (233, FreeBSD ELF64, clock_settime), rip = 0x2007b53ec, rsp = 0x7fff ffffeb38, rbp = 0x7fffffffeb80 --- KDB: enter: panic BUT KDB does not let me in.... So cant offer anything other than this. --WjW From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08:36: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 2C6E016A4CE; Thu, 9 Sep 2004 08:36: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 11CF043D39; Thu, 9 Sep 2004 08:36:52 +0000 (GMT) (envelope-from ru@ip.net.ua) 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 i898aemM007573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 11:36:40 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i898ah1W044368; Thu, 9 Sep 2004 11:36:43 +0300 (EEST) (envelope-from ru) Date: Thu, 9 Sep 2004 11:36:42 +0300 From: Ruslan Ermilov To: Ruben de Groot , freebsd-current@freebsd.org Message-ID: <20040909083641.GA44288@ip.net.ua> Mail-Followup-To: Ruslan Ermilov , Ruben de Groot , freebsd-current@freebsd.org References: <20040909075928.GA50494@ei.bzerk.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20040909075928.GA50494@ei.bzerk.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: re@freebsd.org Subject: Re: release build breaks in src/release/scripts/split-file.sh 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, 09 Sep 2004 08:36:53 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2004 at 09:59:29AM +0200, Ruben de Groot wrote: >=20 > I can't successfully build a release of RELENG_5 on my build machine=20 > (releng_5_2, releng_5_1 and releng_4 are OK) because of an issue with > /bin/sh manifesting itself in the split-file.sh script. Here's the > problem: >=20 > $ uname -r # this is the build machine > 5.1-RELEASE-p16 > $ i=3D1 > $ i=3D$((i + 1)) > arith: syntax error: "i + 1" >=20 > $ uname -r > 5.3-ALPHA > $ i=3D1 > $ i=3D$((i + 1)) > $ echo $i > 2 >=20 > Is this a known issue and has anyone got a workaround for this (I can't > upgrade the build machine, at least not a.t.m.) >=20 Yes. This has been fixed in HEAD on August 26. re@, should I MFC this into RELENG_5? %%% Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/release/Makefile,v retrieving revision 1.853.2.1 diff -u -r1.853.2.1 Makefile --- Makefile 29 Aug 2004 05:37:20 -0000 1.853.2.1 +++ Makefile 9 Sep 2004 08:22:07 -0000 @@ -1081,7 +1081,7 @@ ${RD}/floppyset/${FLOPPYBASE} ${FLPSPLITSIZE} "${FLOPPYDESC}" ( splitfile=3D${SPLITDIR}/`basename ${SPLITFILE}`.split ; \ lines=3D`cat $${splitfile} | wc -l`; \ - lines=3D$$((lines - 1)) ; \ + lines=3D$$(($$lines - 1)) ; \ for line in `jot $$lines`; do \ file=3D`head -n $$(($${line} + 1)) $${splitfile} | tail -1 | cut -f 1 -d= ' '` ; \ sh -e ${DOFS_SH} ${RD}/floppies/${FLOPPYBASE}$${line}.flp \ Index: scripts/split-file.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/release/scripts/split-file.sh,v retrieving revision 1.1 diff -u -r1.1 split-file.sh --- scripts/split-file.sh 26 Jan 2004 19:45:09 -0000 1.1 +++ scripts/split-file.sh 9 Sep 2004 08:22:14 -0000 @@ -35,5 +35,5 @@ i=3D1 for file in ${files}; do echo `basename ${file}` "\"${DESCR} floppy ${i}\"" >> ${DEST}/${prefix}.s= plit - i=3D$((i + 1)) + i=3D$(($i + 1)) done %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBQBYZqRfpzJluFF4RAgFNAJ9xEffAY/VYUkbDBASlapvJvc39BQCfTvKS vsjVOPGo3xYKIMMUg19wz3M= =KJBz -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08:49: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 3ECAA16A4CF for ; Thu, 9 Sep 2004 08:49:41 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 6334743D3F for ; Thu, 9 Sep 2004 08:49:39 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 4817 invoked from network); 9 Sep 2004 08:47:36 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 9 Sep 2004 08:47:36 -0000 Received: (qmail 1633 invoked by uid 1000); 9 Sep 2004 08:50:02 -0000 Date: Thu, 9 Sep 2004 11:50:02 +0300 From: Peter Pentchev To: "M. Warner Losh" Message-ID: <20040909085002.GA1509@straylight.m.ringlet.net> Mail-Followup-To: "M. Warner Losh" , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20040908150943.GA1924@straylight.m.ringlet.net> <20040908.113707.54185659.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20040908.113707.54185659.imp@bsdimp.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Fix USB panics 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, 09 Sep 2004 08:49:41 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 08, 2004 at 11:37:07AM -0600, M. Warner Losh wrote: > Peter, >=20 > thanks again for the excellent anaylsis of the problem. I introduced > this when I cleaned up the load a driver will now cause usb to attach > a device case. You are correct as far as I can tell and can test. > Here's the patch that I've come up with. Does it work for you? Yes, this patch works just fine. I assume you will commit it without the printf and indentation chunks, though? :) Thanks again! 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 because I didn't think of a good beginning of it. --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBQBk67Ri2jRYZRVMRAopIAJ98eSIIUhmMpEUcVnju9Q5NxHxF/ACeNZuC 1VNZevODkiFrUAZWi+O/YJo= =wcRF -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 08:55: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 C8BCA16A4CE; Thu, 9 Sep 2004 08:55:02 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 841F443D31; Thu, 9 Sep 2004 08:55:02 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i898t1la072489; Thu, 9 Sep 2004 01:55:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i898t1R8072488; Thu, 9 Sep 2004 01:55:01 -0700 (PDT) (envelope-from dillon) Date: Thu, 9 Sep 2004 01:55:01 -0700 (PDT) From: Matthew Dillon Message-Id: <200409090855.i898t1R8072488@apollo.backplane.com> To: Robert Watson References: cc: scottl@freebsd.org cc: Gerrit Nagelhout cc: current@freebsd.org Subject: Re: FreeBSD 5.3 Bridge performance take II 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, 09 Sep 2004 08:55:02 -0000 :% One nice thing about using this experimental code is that I hope it will :% allow us to reason more effectively about the extent to which improving :% per-cpu data structures improves efficiency -- I can now much more :% easily say "OK, what happens if eliminate the cost of locking for common :% place mbuf allocation/free". I've also started looking at per-interface :% caches based on the same model, which has some similar limitations (but :% also some similar benefits), such as stuffing per-interface uma caches :% in struct ifnet. : :I.e., using per-thread UMA caches is a 30-60 minute hack that allows me to :explore and measure the performance benefits (and costs) of several :different approaches, including per-cpu, per-thread, and per-data :structure/object caching without doing the full implementation up front. :Per-thread caching, for example, can simulate the effects of :non-preemption and mutex avoidance in micro-benchmarking, although in the :general case under macro-benchmark perspective it suffers from a number of :problems (including the draining, balancing, and extra storage cost :issues). I didn't attempt to address these problems under the assumption :that the current implementation is a tool for exploring performance, not :something to actually use. : Well, I see some major problems with this avenue of development. I see this as an end-run around existing, broken (or perceived to be broken) APIs. If you don't believe that the slab allocator has severe performance issues then the slab allocator (aka malloc()) should simply be used directly. If you do believe that the slab allocator has severe performance issues then the correct solution is to FIRST FIX THE SLAB ALLOCATOR. Until the slab allocator is fixed the system-wide overhead will skew the results from any other optimization tests you try to make. i.e. results from other optimizations may appear to be less effective simply due to being washed out by the slab allocator's overhead. In the same respect, the idea that a per-thread memory cache is going to be more efficient then a per-cpu memory cache implies that it is too expensive to implement the locking required to implement a per-cpu memory cache vs a per-thread memory cache. If that is the implication, the solution is to fix the required locking. Frankly it should be no more expensive then a critical section and a critical section to access per-cpu data should be no more then a nanosecond or two more expensive then access to a per-thread data structure. Per-thread caching APIs have major design hurdles to overcome. I've already listed a few of them, but there are many, many more. For example, locality of reference may seem to be a slam dunk but you actually get better locality of reference with a per-cpu cache, especially when a thread migrates between cpus, but also because the cache is able to take advantage of and reuse a very recently reused chunk of data that might have been freed by some other thread on the same cpu... so you get it even after a context switch (and you don't get that with a per-thread cache). This is a case that can occur quite often, especially when interrupt threads are shipping data to protocol threads. I could go on and on, but I am not going to because I think it damn well ought to be obvious. It seems clear to me that it makes little sense to spend time on a per-thread memory cache when a per-cpu memory cache is, just from an algorithmic point of view, going to be far more effective, far easier to manage, possible to have larger (deterministic) hysteresis without creating too much non-deterministic slop, and so on and so forth. If this is just an experiment, and therefore something that will never be committed, then I still don't understand why you are even wasting time working on it when you could be fixing the slab allocator instead. IMHO I do not believe that a per-thread memory cache would even come close to characterizing the performance benefits of a mutexless per-cpu cache. While the base overhead is similar, the side effects and management requirements are going to be very different. If the experiment is supposed to characterize the potential performance improvement over the slab allocator, then I believe it is already too flawed to be an accurate measure of that. Now does this mean that caches in front of the slab allocator are bad? No, it doesn't. I use front-end caches in several places in DragonFly and you definitely want to do the same thing in FreeBSD. The difference, I think, is that we only use front-end caches for performance-critical subsystems and when we do, we implement the code directly into the subsystem. We depend on our core slab allocator (i.e. malloc()) far more then you seem to want to depend on yours. FreeBSD seems to depend on its UMA type-stable zone allocator for the same thing but that has a lot of extra, unnecessary overhead. The MBUF allocator is a good example of this. You guys are making several extra procedural calls that we aren't in the mbuf allocation path. The way I see it, if it's important enough to require its own front-end cache over simply using the slab allocator, then you might as well go whole hog. But it is also important to make your slab allocator fast so there are fewer situations where you feel that you need to bypass it. A front-end cache is not supposed to be a workaround for a slow slab allocator but instead is supposed to be an ultra-optimized implementation to reduce overhead in a critical subsystem. :In doing so, my hope was to identify which areas will offer the most :immediate performance benefits, be it simply cutting down on costly :operations (such as the entropy harvesting code for Yarrow which appears :to have found its way into our interrupt path), rethinking locking :strategies, optimizing out/coalescing locking, optimizing out excess :memory allocation, optimizing synchronization primitives with the same :semantics, changing synchronization assumptions to offer weaker/stronger :semantics, etc. :... : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects :robert@fledge.watson.org Principal Research Scientist, McAfee Research Well, I guess identifying the problem areas is good, but it isn't rocket science. It should be glaringly obvious without requiring all that much actual testing. One big problem you face is that a great deal of the performance issues in FreeBSD are not from any single subsystem, but from overheads sprinkled throughout the entire codebase. Taken singly, these overheads are not significant. A single mutex could be argued to be not all that significant... but having to obtain and release 11 mutexes in a code path *IS* significant. A single memory allocation might not be significant, but having to make three or four in a critical path can be. And so on, and so forth. Testing performance with little tweaks here and there is not going to give you any worthwhile results, IMHO. Just fixing one thing isn't going to solve the performance problem. You have to fix the entire path. It isn't JUST the mutex overhead that's the problem. It's the mutex overhead, the scheduler overhead, all the myrid calls you have to make to pin the thread, or enter a critical section (if you have to do it too often)... it's the atomic-access requirement to the per-cpu %fs:globaldata data which makes it impossible to cache per-cpu data. It's the 4BSD/ULE scheduler being used to schedule kernel threads, its the thread switching overhead, the microtime calls in the switch path, coding requirements to deal with preemption, cpu migration, giant lock handling, uma zone allocator's callback API, and a dozen other things. Taken singly these items produce a fractional degredation. Taken singly these items aren't necessarily even 'bad'. Taken together and you have... well, you have the situation you find yourself in now. To really fix the problem you need to be willing to clean up ALL of these subsystems. Well, first you need to recognize that they all need to be cleaned up, and I gather that some FreeBSD developers still don't recognize that as the problem. Once you recognize that its a problem you then need to go and do the work. Cleaning up the subsystems is only the first step... it gives you a nice solid reasonably high performing base to work with. You still have to deal with the higher-level critical pathing issues once you've cleaned up the subsystems. This is where things like front-end caches really show their stuff. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 09:37: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 DC0F816A4CE for ; Thu, 9 Sep 2004 09:37:11 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58FAD43D53 for ; Thu, 9 Sep 2004 09:37:11 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from [192.168.0.100] (eiterra.achedra.org [192.168.0.100]) by error404.nls.net (8.12.10/8.12.10) with ESMTP id i899bAF8029363; Thu, 9 Sep 2004 05:37:10 -0400 (EDT) (envelope-from ketrien@error404.nls.net) Message-ID: <41402540.2060504@error404.nls.net> Date: Thu, 09 Sep 2004 05:41:20 -0400 From: "Ketrien I. Saihr-Kesenchedra" User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <41401326.90200@withagen.nl> In-Reply-To: <41401326.90200@withagen.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Still getting Signal 6 with BETA3 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, 09 Sep 2004 09:37:12 -0000 Willem Jan Withagen wrote: > Hi, > > I've been away for a week, so I've missed a part of the discussion on > signal 6, but I'm still getting them. Running AMD64 on dual opteron > with 1 Gb. > Anything I can do to help fix this?? > > I also found a panic on my screen this morning but I'll put that in > another thread. I'll one up that. 5.3-BETA1 -and- 5.3-BETA3 produce sig10 and sig11 on 90% of world, including sendmail, sshd, and more on the 4-way I'm working on here. I could go back to the 5.3-BETA kernels, but they've both done the ffs_alloc free panic that was discussed recently on this box when buildworld's been attempted, and ata from RELENG_5 branch of about two hours ago just hardlocks the box. That's wonderful. Especially since it has an LSI Ultra320-0 and I need ata so that we can debug the amr(4) panics at boot, which kept the box unusable. When the amr panics started making themselves known, they've been combined with a broken world, so basically 5.3-BETA's been completely unusable period. Only way it's run is with ACPI turned off, which means I've got one of four CPUs going. ACPI just hardlocks. (Didn't do that on 5.2.1-RELEASE.) If I'm lucky I can get ata to sometimes boot the 20G IDE I threw on the box just so I can try and debug amr(4). I say sometimes because 9 in 10 times, it just hardlocks the box. Including off RELENG_5 from about 2 hours ago. Talk about exposing showstoppers. I'd share the ffs panics, but I'd need panics that didn't get halfway through printing without hardlocking the box, or working ata so I could boot the box. 5.2.1-RELEASE just hardlocks at init. So kindly don't bother me with demands for more detailed information on the panics and hardlocks. If I had more information, it'd be directly in the hands of people who need it. The ffs panics are the same ones I saw mentioned before, XfastFree and what have you. Yeah. I'm justifiably grumpy. Been fighting this box since last week, and have yet to get anything on it that actually works, save Win2k3 beta. (Linux doesn't count as working. Don't ask.) -ksaihr / ketrien at error404 dot nls dot net "Yeah. It's sleep deprivation. Don't worry, you get used to it eventually." From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 09:38: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 EC8E216A4CE; Thu, 9 Sep 2004 09:38:50 +0000 (GMT) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id A544D43D5D; Thu, 9 Sep 2004 09:38:50 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id B71C03813E; Thu, 9 Sep 2004 11:38:49 +0200 (CEST) From: "Daniel Eriksson" To: "'Robert Watson'" Date: Thu, 9 Sep 2004 11:38:47 +0200 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSV9yooILzA42WVTsuFeBzUt/yJjQAWK5DA cc: current@freebsd.org Subject: RE: FreeBSD 5.3 Bridge performance take II 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, 09 Sep 2004 09:38:51 -0000 Robert Watson wrote: > If you're not already disabling harvesting of entropy on interrupts and > in network processing, you really want to for performance purposes. How do I disable this without causing entropy starvation for "typical" use cases (ssl? ssh?)? I googled a bit and found nothing at all about how to disable excessive harvesting. # sysctl -a | grep harvest kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 These are the knobs I know about. Is it enough to turn kern.random.sys.harvest.ethernet and kern.random.sys.harvest.interrupt to 0, or are there other things I need to do too? /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 11:07: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 D1DED16A4CE; Thu, 9 Sep 2004 11:07:47 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A09B43D39; Thu, 9 Sep 2004 11:07:47 +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 i89B7k2u066055; Thu, 9 Sep 2004 07:07:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i89B7kvs007142; Thu, 9 Sep 2004 07:07:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7CFF77303F; Thu, 9 Sep 2004 07:07:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040909110746.7CFF77303F@freebsd-current.sentex.ca> Date: Thu, 9 Sep 2004 07:07:46 -0400 (EDT) Subject: [releng_5 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: Thu, 09 Sep 2004 11:07:48 -0000 TB --- 2004-09-09 09:40:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-09 09:40:41 - starting RELENG_5 tinderbox run for ia64/ia64 TB --- 2004-09-09 09:40:41 - checking out the source tree TB --- 2004-09-09 09:40:41 - cd /home/tinderbox/RELENG_5/ia64/ia64 TB --- 2004-09-09 09:40:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-09 09:48:19 - building world (CFLAGS=-O -pipe) TB --- 2004-09-09 09:48:19 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-09 09:48:19 - /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-09-09 10:48:06 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-09 10:48:06 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-09 10:48:06 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Sep 9 10:48:06 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 >>> Kernel build for GENERIC completed on Thu Sep 9 11:01:02 UTC 2004 TB --- 2004-09-09 11:01:02 - generating LINT kernel config TB --- 2004-09-09 11:01:02 - cd /home/tinderbox/RELENG_5/ia64/ia64/src/sys/ia64/conf TB --- 2004-09-09 11:01:02 - /usr/bin/make -B LINT TB --- 2004-09-09 11:01:02 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-09 11:01:02 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-09 11:01:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 9 11:01:02 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 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/gate/g_gate.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_iso9660.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_msdosfs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_ufs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2483: warning: 'sc' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/obj/ia64/tinderbox/RELENG_5/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. TB --- 2004-09-09 11:07:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-09 11:07:46 - ERROR: failed to build lint kernel TB --- 2004-09-09 11:07:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 11: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 4D66216A4CE; Thu, 9 Sep 2004 11:23:53 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E985543D2D; Thu, 9 Sep 2004 11:23:52 +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 i89BNqps002215; Thu, 9 Sep 2004 07:23:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i89BNpvl043905; Thu, 9 Sep 2004 07:23:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DEFCC7303F; Thu, 9 Sep 2004 07:23:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040909112351.DEFCC7303F@freebsd-current.sentex.ca> Date: Thu, 9 Sep 2004 07:23:51 -0400 (EDT) Subject: [releng_5 tinderbox] failure on powerpc/powerpc 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: Thu, 09 Sep 2004 11:23:53 -0000 TB --- 2004-09-09 11:07:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-09 11:07:46 - starting RELENG_5 tinderbox run for powerpc/powerpc TB --- 2004-09-09 11:07:46 - checking out the source tree TB --- 2004-09-09 11:07:46 - cd /home/tinderbox/RELENG_5/powerpc/powerpc TB --- 2004-09-09 11:07:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-09 11:15:28 - building world (CFLAGS=-O -pipe) TB --- 2004-09-09 11:15:28 - cd /home/tinderbox/RELENG_5/powerpc/powerpc/src TB --- 2004-09-09 11:15:28 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REP.c -o asn1_TGS_REP.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REQ.c -o asn1_TGS_REQ.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_Ticket.c -o asn1_Ticket.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TicketFlags.c -o asn1_TicketFlags.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TransitedEncoding.c -o asn1_TransitedEncoding.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_UNSIGNED.c -o asn1_UNSIGNED.So building shared library libasn1.so.7 Abort trap (core dumped) *** Error code 134 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. TB --- 2004-09-09 11:23:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-09 11:23:51 - ERROR: failed to build world TB --- 2004-09-09 11:23:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 21:06: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 C60E116A4CF for ; Wed, 8 Sep 2004 21:06:24 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31CF343D53 for ; Wed, 8 Sep 2004 21:06:24 +0000 (GMT) (envelope-from aaron.glenn@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so1657rnl for ; Wed, 08 Sep 2004 14:06:23 -0700 (PDT) Received: by 10.38.2.71 with SMTP id 71mr16941rnb; Wed, 08 Sep 2004 14:06:23 -0700 (PDT) Received: by 10.38.79.78 with HTTP; Wed, 8 Sep 2004 14:06:23 -0700 (PDT) Message-ID: <18f60194040908140660aa1ead@mail.gmail.com> Date: Wed, 8 Sep 2004 14:06:23 -0700 From: Aaron Glenn To: freebsd-current@freebsd.org In-Reply-To: <20040908155810.71ab34eb@vixen42.24-119-122-191.cpe.cableone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <18f601940409081213604d1233@mail.gmail.com> <20040908155810.71ab34eb@vixen42.24-119-122-191.cpe.cableone.net> X-Mailman-Approved-At: Thu, 09 Sep 2004 11:47:30 +0000 Subject: Re: Abnormally high CPU usage on BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aaron Glenn List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 21:06:24 -0000 I cvsup'ed to RELENG_5 of today, compiled a GENERIC kernel with unneeded drivers stripped out (SCSI RAID, USB NIC, etc) and it seems to be running just fine. the PCI interrupt routing table message still shows, which worries me. Thanks for any insights; please cc me as I'm not subscribed to -current (though I probably should) aaron.glenn On Wed, 8 Sep 2004 15:58:10 -0500, Vulpes Velox wrote: > On Wed, 8 Sep 2004 12:13:18 -0700 > Aaron Glenn wrote: > > > All, > > > > I don't recall having this issue with 5.3-BETA2, but to be honest I > > can't be entirely sure. I just put a fresh install of BETA3 on a P4 > > 2.8GHz machine and while untaring ports.tgz I get bsdtar hovering > > around 80% CPU usage. The machine becomes noticably sluggish, where > > neither previous BETA did before. I find the "pcib1: could not get > > PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND" > > line in my dmesg curious, but I'm not sure what, if anything, I > > can/should do about that. > > > > Should I recompile my kernel disabling WITNESS and the like? Below > > is a complete dmesg; the motherboard is an Intel SE7210TP1-E. Please > > cc me as I'm not subscribed to -questions. > > > > Current would probally be a better list to try out. I would also mess > with APIC setting in the bios or compile them into the kernel. > FreeBSD 5.3-BETA3 uniball# 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 5.3-BETA3 #0: Sat Sep 4 12:07:48 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf33 Stepping = 3 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073676288 (1023 MB) avail memory = 1041121280 (992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface 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 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 3.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci1: on pcib1 em0: port 0xbc00-0xbc1f mem 0xfc5e0000-0xfc5fffff irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:02:b3:e9:b6:1c em0: Speed:N/A Duplex:N/A pcib2: at device 28.0 on pci0 pci2: on pcib2 uhci0: port 0xe800-0xe81f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xec00-0xec1f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no driver attached) pci0: at device 29.7 (no driver attached) pcib3: at device 30.0 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) fxp0: port 0xcc00-0xcc3f mem 0xfe6a0000-0xfe6bffff,0xfe6fe000-0xfe6fefff irq 17 at device 1.0 on pci3 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:e9:b6:1d isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xd400-0xd40f,0xd800-0xd803,0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe407 irq 18 at device 31.2 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 orm0: at iomem 0xe0000-0xe3fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ATAPI_RESET time = 60us acd0: CDROM at ata0-master UDMA33 ad4: 35304MB [71730/16/63] at ata2-master SATA150 ad6: 35304MB [71730/16/63] at ata3-master SATA150 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad4s1a uniball# From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 22:47: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 C642B16A4CE; Wed, 8 Sep 2004 22:47:50 +0000 (GMT) Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8747843D31; Wed, 8 Sep 2004 22:47:50 +0000 (GMT) (envelope-from pavlin@icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i88MlmwK049087; Wed, 8 Sep 2004 15:47:48 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200409082247.i88MlmwK049087@possum.icir.org> To: Harti Brandt In-Reply-To: Message from Harti Brandt <20040908140335.R23565@beagle.kn.op.dlr.de> Date: Wed, 08 Sep 2004 15:47:48 -0700 From: Pavlin Radoslavov X-Mailman-Approved-At: Thu, 09 Sep 2004 11:47:30 +0000 cc: Craig Rodrigues cc: freebsd-current@freebsd.org cc: Pavlin Radoslavov Subject: Re: g++ may fail to compile __packed structures 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, 08 Sep 2004 22:47:50 -0000 > PR>> On Mon, Sep 06, 2004 at 01:24:15PM -0700, Pavlin Radoslavov wrote: > PR>> > It appears that the lastest g++ compiler that comes with FreeBSD may > PR>> > fail to compile a __packed structure when one of its fields is > PR>> > passed by reference. At the end of this email is a sample program > PR>> > that demonstrates the problem. The compilation error is: > PR>> > > PR>> > pavlin@carp[14] g++34 test.cc > PR>> > test.cc: In function `int main()': > PR>> > test.cc:22: error: cannot bind packed field `f1.foo::f' to `int&' > PR>> > Exit 1 > PR>> > > PR>> > The problem appears to exist only with the recent g++ compiler that > PR>> > comes with FreeBSD: > PR>> > PR>> This change was made recently to gcc: > PR>> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01664.html > PR> > PR>Yes, I am aware of that patch (when I did some search on the subject > PR>before posting my email). However, again, when I use the vanilla g++ > PR>3.4.1 which is 2 months old, or even the vanilla 3.4.2 which was > PR>just released today, I don't get the compilation error. > PR>Hence, why the disparity between the vanilla gcc and the lastest > PR>gcc that comes with FreeBSD? > PR> > PR>> Apparently in C++, you are not allowed to have non-const references > PR>> to packed fields. See: > PR>> http://www.comnets.rwth-aachen.de/doc/c++std/decl.html#dcl.init.ref > PR> > PR>The above URL doesn't say anything about packed fields. > PR>Please correct me if I am wrong, but I think that __packed is not > PR>part of the C or C++ standart, hence this leaves some gray area for > PR>interpretation. Anyway, this is a subject for the gcc ML... > PR> > PR>However, I am trying to find-out why the FreeBSD gcc behaves > PR>different from the vanilla gcc, and which compiler has the "right" > PR>behavior. > > Neither. As you said __packed is not part of any standard. If you take > into account that a reference is essentially a pointer (at least in the > case of a function argument) this pointer could easily have the wrong > alignment, because your packed field may have the wrong alignment. To > catch this case the compiler would need to propagate that information at > run-time to the function. In short: don't use such features. If you need > packed (because you're accessing hardware) pass by value not by reference. Yes, I understand why __packed can be problematic, and I am not arguing what the behavior of the compiler should be. What I find confusing is that the compiler that comes with FreeBSD behaves differently from the vanilla gcc compiler (from gcc.gnu.org). I am trying to find-out whether the difference in the behavior was intentional or because of an overlook somewhere. In either case, I believe the desired behavior is that both compilers should be consistent. Thanks, Pavlin P.S. BTW, the reason I came across __packed is because sometime in the not so distant pass, "struct ip" inside was (re)defined as __packed. From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 04:48: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 4E65016A4CE for ; Thu, 9 Sep 2004 04:48:15 +0000 (GMT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [62.67.200.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E3343D45 for ; Thu, 9 Sep 2004 04:48:14 +0000 (GMT) (envelope-from changethis@mark.reidel.info) Received: (qmail 25755 invoked from network); 9 Sep 2004 04:48:10 -0000 Received: from unknown (HELO karm.dyndns.org) (793055@[217.232.160.5]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 04:48:10 -0000 Received: (qmail 89395 invoked by uid 0); 9 Sep 2004 04:48:02 -0000 Received: from unknown (HELO ?192.168.42.12?) (192.168.42.12) by karm.dyndns.org with SMTP; 9 Sep 2004 04:48:02 -0000 Message-ID: <413FE07E.2070302@mark.reidel.info> Date: Thu, 09 Sep 2004 06:47:58 +0200 From: Mark Daniel Reidel User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040807) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Sep 2004 11:47:30 +0000 Subject: DMA-aware drive runs at PIO since upgrading to 5.3beta 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, 09 Sep 2004 04:48:15 -0000 Hi there! Since I upgraded from a current as of end of July to 5.3 beta2, I noticed, that by CDRW now runs on PIO4 which is quite annoying, since it was running on WDMA perfectly well before :o( My other drive, a DVD is detected fine, here's the dmesg snip: ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 40us ata0-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ATAPI_RESET time = 10us ata0-master: setting PIO4 on VIA 82C686B chip ata0-slave: setting PIO4 on VIA 82C686B chip ata0-slave: setting UDMA33 on VIA 82C686B chip acd0: CDRW drive at ata0 as master acd0: read 6890KB/s (6890KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM unknown acd1: DVDROM drive at ata0 as slave acd1: read 2750KB/s (6875KB/s), 512KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc Any idea why it's doing this? My other PC at work has a CDROM which is also now run on PIO4 instead of DMA since the upgrade, so I guess it's nothing specific to my hardware since I have an Athlon and a P4 at work. Any help would be appreciated, because burning at PIO4 is not what I'd like to to from now on as you can imagine ;o) - Mark -- Fortune cookie of the hour: "I'm not under the alkafluence of inkahol that some thinkle peep I am. It's just the drunker I sit here the longer I get." From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 05:50: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 E7C9116A4CE for ; Thu, 9 Sep 2004 05:50:24 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EF2643D5E for ; Thu, 9 Sep 2004 05:50:23 +0000 (GMT) (envelope-from sam.wun@authtec.net) Received: (qmail 36756 invoked from network); 9 Sep 2004 05:50:21 -0000 Received: from unknown (HELO [192.168.4.129]) (samwun@hgcbroadband.com@[221.127.106.232]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 05:50:21 -0000 Message-ID: <413FEE0F.6070302@authtec.net> Date: Thu, 09 Sep 2004 13:45:51 +0800 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <413BE6CC.9010200@authtec.net> <20040907175400.GD17387@odin.ac.hmc.edu> <200409080000.58832.max@love2party.net> In-Reply-To: <200409080000.58832.max@love2party.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Sep 2004 11:47:30 +0000 cc: freebsd-current@freebsd.org Subject: Re: PF+CARP is not yet migrated to Beta53 - some testing tools 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, 09 Sep 2004 05:50:25 -0000 Max Laier wrote: >On Tuesday 07 September 2004 19:54, Brooks Davis wrote: > > >>On Mon, Sep 06, 2004 at 12:25:48PM +0800, sam wrote: >> >> >>>I just found that PF CARP is not yet migrated to Beta53. >>>At the mement, I will have to apply CARP patches to the src manually >>>after installed Beta53. >>>I think I will still rely on my own release of FreeBSD53 to enable >>>PF+CARP for the time being.... >>> >>> >>Yes, that's correct. The ABI changes required by CARP were made, but >>it was deemed that there wasn't time to actually implement CARP before >>5.3. It should be in 5.4. >> >> > >I hope that I have enough time to polish it for 5.4 - no chance for 5.3 (I >think I said that whenever posting patches). Help testing! Provide feedback! > >Thanks! > > > Hi, I would like to commit to the testing. I recently purchased few P4 machines. They will be used for the testing of the PF+PFSYNC+CARP stuff. One thing I am still looking for is some testing tools. Do you have any suggestion about which tools I can use to test the load balancing and redundancy control in this particular case? Thanks Sam From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 10:15: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 C9F8016A4CE; Thu, 9 Sep 2004 10:15:43 +0000 (GMT) Received: from kiuru.kpnet.fi (kiuru.kpnet.fi [193.184.122.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B17DA43D3F; Thu, 9 Sep 2004 10:15:42 +0000 (GMT) (envelope-from midian@ihme.org) Received: from [192.168.1.57] (adsl-36-92.regionline.fi [194.211.36.92]) by kiuru.kpnet.fi (8.12.8/8.12.8) with ESMTP id i89AFggZ002853; Thu, 9 Sep 2004 13:15:42 +0300 Date: Thu, 9 Sep 2004 13:15:38 +0300 (EEST) From: =?iso-8859-1?Q?Markus_H=E4stbacka?= X-X-Sender: midian@midi.ihme.net To: Ulrich Spoerlein In-Reply-To: <20040909082525.GA778@galgenberg.net> Message-ID: <20040909131015.T48921@midi.ihme.net> References: <20040905124526.F15143@midi.ihme.net> <24D02CEA-022C-11D9-870B-000A95C4D7BC@FreeBSD.org> <20040909082525.GA778@galgenberg.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 09 Sep 2004 11:47:30 +0000 cc: freebsd-current@FreeBSD.org cc: Suleiman Souhlal Subject: Re: Sound performance problems in FreeBSD 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, 09 Sep 2004 10:15:43 -0000 On Thu, 9 Sep 2004, Ulrich Spoerlein wrote: > Not repdrocueable here on 5.3-BETA3. Even extracting the Mozilla sources > no longer produces skips ind mp3 playback. > > pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff400-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 5 at device 31.5 on pci0 > pcm0: [GIANT-LOCKED] > pcm0: > % cat /dev/sndstat > FreeBSD Audio Driver (newpcm) > Installed devices: > pcm0: at io 0xb800, 0xbc40 irq 5 bufsz 16384 kld snd_ich (1p/1r/4v channels duplex default) > is your buffersize higher than 4k? The MP3 playing worked well when I had 16k buffer, but that meant high sound latency for games, and it wouldn't be a solution to fix it by highing the sound buffersize. So the only thing I can live with is 4k at the moment. Markus From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 11:56: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 D258816A4CE; Thu, 9 Sep 2004 11:56:48 +0000 (GMT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F66E43D5A; Thu, 9 Sep 2004 11:56:48 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i89BueTH017566; Thu, 9 Sep 2004 07:56:40 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i89Bue8l017565; Thu, 9 Sep 2004 07:56:40 -0400 (EDT) Date: Thu, 9 Sep 2004 07:56:40 -0400 From: Ken Smith To: Ruslan Ermilov , Ruben de Groot , freebsd-current@FreeBSD.org Message-ID: <20040909115640.GA17338@electra.cse.Buffalo.EDU> References: <20040909075928.GA50494@ei.bzerk.org> <20040909083641.GA44288@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909083641.GA44288@ip.net.ua> User-Agent: Mutt/1.4.1i Subject: Re: release build breaks in src/release/scripts/split-file.sh 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, 09 Sep 2004 11:56:48 -0000 On Thu, Sep 09, 2004 at 11:36:42AM +0300, Ruslan Ermilov wrote: > Yes. This has been fixed in HEAD on August 26. > > re@, should I MFC this into RELENG_5? > > %%% > Index: Makefile > =================================================================== > RCS file: /home/ncvs/src/release/Makefile,v > retrieving revision 1.853.2.1 > diff -u -r1.853.2.1 Makefile > --- Makefile 29 Aug 2004 05:37:20 -0000 1.853.2.1 > +++ Makefile 9 Sep 2004 08:22:07 -0000 > @@ -1081,7 +1081,7 @@ > ${RD}/floppyset/${FLOPPYBASE} ${FLPSPLITSIZE} "${FLOPPYDESC}" > ( splitfile=${SPLITDIR}/`basename ${SPLITFILE}`.split ; \ > lines=`cat $${splitfile} | wc -l`; \ > - lines=$$((lines - 1)) ; \ > + lines=$$(($$lines - 1)) ; \ > for line in `jot $$lines`; do \ > file=`head -n $$(($${line} + 1)) $${splitfile} | tail -1 | cut -f 1 -d ' '` ; \ > sh -e ${DOFS_SH} ${RD}/floppies/${FLOPPYBASE}$${line}.flp \ > Index: scripts/split-file.sh > =================================================================== > RCS file: /home/ncvs/src/release/scripts/split-file.sh,v > retrieving revision 1.1 > diff -u -r1.1 split-file.sh > --- scripts/split-file.sh 26 Jan 2004 19:45:09 -0000 1.1 > +++ scripts/split-file.sh 9 Sep 2004 08:22:14 -0000 > @@ -35,5 +35,5 @@ > i=1 > for file in ${files}; do > echo `basename ${file}` "\"${DESCR} floppy ${i}\"" >> ${DEST}/${prefix}.split > - i=$((i + 1)) > + i=$(($i + 1)) > done > %%% Yes please. Thanks. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 12:48: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 47C1016A4CE for ; Thu, 9 Sep 2004 12:48:39 +0000 (GMT) Received: from smtp.prodigy.net.mx (nlpproxy03.prodigy.net.mx [148.235.52.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80C143D5E for ; Thu, 9 Sep 2004 12:48:38 +0000 (GMT) (envelope-from eculp@prodigy.net.mx) Received: from prodigy.net.mx (du-148-235-52-33.prodigy.net.mx [148.235.52.33]) by smtp.prodigy.net.mx (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3R008IZY8X2X@smtp.prodigy.net.mx>; Thu, 09 Sep 2004 07:48:33 -0500 (CDT) Received: from [148.235.52.103] (Forwarded-For: [201.129.94.187]) by nlpmail03.prodigy.net.mx (mshttpd); Thu, 09 Sep 2004 07:51:40 -0500 Date: Thu, 09 Sep 2004 07:51:40 -0500 From: eculp To: current@freebsd.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.01 (built Aug 26 2004) Content-type: text/plain; charset=us-ascii Content-language: es Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: es Priority: non-urgent X-Priority: 5 (Lowest) Subject: snd_ich no longer works. 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, 09 Sep 2004 12:48:39 -0000 I just realized that my onboard pcm0@pci0:2:7: class=0x040100 card=0xa00c1019 chip=0x70121039 rev=0xa0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7012 PCI Audio Accelerator' class = multimedia That uses snd_ich no longer works with my new world and kernel from yesterday morning but the by going back to a kernel from Sept 3, it works fine. Is this a known issue? Is there something that I can do to help isolate the issue? Thanks, ed P.S. This is an AMD Duron CPU: AMD Duron(tm) (1600.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400000 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 13:51: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 1550E16A4CE for ; Thu, 9 Sep 2004 13:51:57 +0000 (GMT) Received: from smtp.prodigy.net.mx (nlpproxy10.prodigy.net.mx [148.235.52.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF67B43D49 for ; Thu, 9 Sep 2004 13:51:56 +0000 (GMT) (envelope-from eculp@prodigy.net.mx) Received: from prodigy.net.mx (du-148-235-52-33.prodigy.net.mx [148.235.52.33]) by smtp.prodigy.net.mx (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3S000SQ16HDH@smtp.prodigy.net.mx>; Thu, 09 Sep 2004 08:51:53 -0500 (CDT) Received: from [148.235.52.103] (Forwarded-For: [201.129.94.187]) by nlpmail03.prodigy.net.mx (mshttpd); Thu, 09 Sep 2004 08:55:00 -0500 Date: Thu, 09 Sep 2004 08:55:00 -0500 From: eculp To: current@freebsd.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.01 (built Aug 26 2004) Content-type: text/plain; charset=us-ascii Content-language: es Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: es Priority: non-urgent X-Priority: 5 (Lowest) Subject: device_attach: fdc0 attach returned 6 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, 09 Sep 2004 13:51:57 -0000 I've been seeing this for some time on Athlon machines with via chipset. Is there a work around or a fix in the works before 5.3 release? Thanks, ed From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 13:55: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 EA2FA16A4CE for ; Thu, 9 Sep 2004 13:55:57 +0000 (GMT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id A61F443D1F for ; Thu, 9 Sep 2004 13:55:57 +0000 (GMT) (envelope-from my-subs@mail.ru) Received: from [82.81.86.35] (port=59477 helo=ant.zoo) by mx2.mail.ru with smtp id 1C5PP1-000KeA-00 for freebsd-current@freebsd.org; Thu, 09 Sep 2004 17:55:56 +0400 Date: Thu, 9 Sep 2004 16:55:47 +0300 From: Alexander Portnoy To: freebsd-current@freebsd.org Message-Id: <20040909165547.7b5d889f.my-subs@mail.ru> In-Reply-To: <413FE07E.2070302@mark.reidel.info> References: <413FE07E.2070302@mark.reidel.info> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: Not detected Subject: Re: DMA-aware drive runs at PIO since upgrading to 5.3beta 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, 09 Sep 2004 13:55:58 -0000 On Thu, 09 Sep 2004 06:47:58 +0200 Mark Daniel Reidel wrote: > Hi there! > > Since I upgraded from a current as of end of July to 5.3 beta2, I noticed, > that by CDRW now runs on PIO4 which is quite annoying, since it was running > on WDMA perfectly well before :o( My other drive, a DVD is detected fine, > here's the dmesg snip: > > ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin > ATAPI_RESET time = 40us > ata0-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin > ATAPI_RESET time = 10us > ata0-master: setting PIO4 on VIA 82C686B chip > ata0-slave: setting PIO4 on VIA 82C686B chip > ata0-slave: setting UDMA33 on VIA 82C686B chip > acd0: CDRW drive at ata0 as master > acd0: read 6890KB/s (6890KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, PIO4 > acd0: Reads: CDR, CDRW, CDDA stream, packet > acd0: Writes: CDR, CDRW, test write, burnproof > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: CD-ROM unknown > acd1: DVDROM drive at ata0 > as slave > acd1: read 2750KB/s (6875KB/s), 512KB buffer, UDMA33 > acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet > acd1: Writes: > acd1: Audio: play, 256 volume levels > acd1: Mechanism: ejectable tray, unlocked > acd1: Medium: no/blank disc > > Any idea why it's doing this? My other PC at work has a CDROM which is also > now run on PIO4 instead of DMA since the upgrade, so I guess it's nothing > specific to my hardware since I have an Athlon and a P4 at work. > Any help would be appreciated, because burning at PIO4 is not what I'd like > to to from now on as you can imagine ;o) > > - Mark Mee too :-( Since I upgraded from 5.2.1 to 5.3-BETA3. This happens also under FreeBSD-6.0-CURRENT (2004.08.29.21.12.19). acd0: CDRW at ata1-master PIO4 hw.ata.atapi_dma: 1 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:40: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 AC98616A4CE; Thu, 9 Sep 2004 14:40:36 +0000 (GMT) Received: from exchange.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 465BE43D45; Thu, 9 Sep 2004 14:40:36 +0000 (GMT) (envelope-from gnagelhout@sandvine.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Thu, 9 Sep 2004 10:40:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 5.3 Bridge performance take II Thread-Index: AcSWMkxnjywMNrSUSCWEa9M2UyF0FAAR4KhQ From: "Gerrit Nagelhout" To: "Robert Watson" , cc: scottl@freebsd.org Subject: RE: FreeBSD 5.3 Bridge performance take II 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, 09 Sep 2004 14:40:36 -0000 Robert Watson wrote: >=20 > Right now, though, the greatest obstacle in my immediate path=20 > appears to > be a bug in the current version of the if_em driver that causes the > interfaces on my test box to wedge under even moderate load. =20 > The if_em > cards I have on other machines seem not to do this, which suggests a > driver weirdness with this particular version of the chipset/card. Go > figure... >=20 You may want to check the version of the chipset on that card. There = are definitely older em cards out there which require some special = alignments on the transmitter side to avoid hangs. If I remember correctly, the=20 linux driver on the Intel web site has a workaround for this that is not in the FreeBSD driver. The problem is that the workaround for this=20 involves splitting mbufs if the alignment isn't correct, and this is = quite expensive. Gerrit From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:42: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 1E53716A4CE for ; Thu, 9 Sep 2004 14:42:08 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BA943D45 for ; Thu, 9 Sep 2004 14:42:07 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 6F0AE50B82 for ; Thu, 9 Sep 2004 23:42:06 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 42AC850C00 for ; Thu, 9 Sep 2004 23:42:04 +0900 (JST) Date: Thu, 09 Sep 2004 23:42:04 +0900 Message-ID: <7mhdq7sdvn.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: panic: mutex Giant not owned 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, 09 Sep 2004 14:42:08 -0000 This is current as of 2004.09.08.20.00.00+00. This panic is happened during test for kqueue-using application. ----- panic: mutex Giant not owned at /usr/src/sys/kern/kern_event.c:1334 cpuid = 1 KDB: enter: panic [thread 100305] Stopped at kdb_enter+0x2b: nop db> trace kdb_enter(c068845a) at kdb_enter+0x2b panic(c0687917,c0698812,c06857cf,536,c4262bf4) at panic+0x127 _mtx_assert(c06f2280,1,c06857cf,536,c4262bf4) at _mtx_assert+0x5c kqueue_close(c4262bf4,c43d27d0) at kqueue_close+0x28 fdrop_locked(c4262bf4,c43d27d0,c344bd24,0,c06853b7) at fdrop_locked+0x84 fdrop(c4262bf4,c43d27d0) at fdrop+0x24 kevent(c43d27d0,ed139d14,6,7,282) at kevent+0x1d6 syscall(2f,2f,2f,bfaedb80,1) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f ----- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:52:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id EC65816A4CF; Thu, 9 Sep 2004 14:52:07 +0000 (GMT) Date: Thu, 9 Sep 2004 14:52:07 +0000 From: Kris Kennaway To: current@freeBSD.org Message-ID: <20040909145207.GA89026@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Stack overrun and double fault in UFS (with backtrace) 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, 09 Sep 2004 14:52:08 -0000 I updated one of the SMP package machines to 6.0, and it blew up overnight with this: Fatal double fault: eip = 0xc05709c7 esp = 0xe7ec7f94 ebp = 0xe7ec8168 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: enter: panic jhb [=BigKnife] suggested the following: try this for "fun" well, first do a 'show pcpu' to get the value of curthread then do call db_backtrace(0xc25be960, 0, 0xe7ec8168, 0xc05709c7) (that's db_backtrace(curthread, NULL, ebp, eip) and see if it can give you a backtrace.. ugh , woops add another arg of '-1' forgot to specify count of frames to do :-P db> show pcpu cpuid = 0 curthread = 0xc25be960: pid 51128 "rm" curpcb = 0xe7ec9da0 fpcurthread = none idlethread = 0xc224e960: pid 14 "idle: cpu0" APIC ID = 0 currentldt = 0x30 spin locks held: db> call db_backtrace(0xc25be960, 0, 0xe7ec8168, 0xc05709c7, -1) buf_splay(170c00,0,0,d6f16740,0) at buf_splay+0x2b gbincore(c25fee70,170c00,0,c25fee70,0) at gbincore+0x8d getblk(c25fee70,170c00,0,4000,0) at getblk+0xa0 breadn(c25fee70,170c00,0,4000,0) at breadn+0x31 bread(c25fee70,170c00,0,4000,0) at bread+0x20 ffs_update(ca712630,1,c0519a72,c0716910,0) at ffs_update+0x224 ffs_truncate(ca712630,0,0,c00,0) at ffs_truncate+0xbaf ufs_inactive(e7ec8520,e7ec8538,c05722e6,e7ec8520,c070c460) at ufs_inactive+0xbc ufs_vnoperate(e7ec8520,c070c460,ca712630,c25be960,e7ec855c) at ufs_vnoperate+0x13 vput(ca712630,c06fc7d8,ce9df080,ca712630,cd819760) at vput+0x10e handle_workitem_remove(cd819760,ca712630) at handle_workitem_remove+0x101 process_worklist_item(0,10,0,10,0) at process_worklist_item+0x161 request_cleanup(1,1) at request_cleanup+0x66 inodedep_lookup(c25ad000,19550,1,e7ec85dc,c06fc7d8) at inodedep_lookup+0xb2 softdep_change_linkcnt(c2b05690) at softdep_change_linkcnt+0x25 ufs_inactive(e7ec862c,e7ec8644,c05722e6,e7ec862c,c070c460) at ufs_inactive+0x133 ufs_vnoperate(e7ec862c,c070c460,c4cb8528,c25be960,e7ec8668) at ufs_vnoperate+0x13 vput(c4cb8528,c06fc7d8,cef69100,c4cb8528,c5fcf500) at vput+0x10e handle_workitem_remove(c5fcf500,c4cb8528) at handle_workitem_remove+0x101 process_worklist_item(0,10,0,1954f,e7ec86c4) at process_worklist_item+0x161 request_cleanup(1,1) at request_cleanup+0x5d inodedep_lookup(c25ad000,1954f,1,e7ec86e0,c06fc7d8) at inodedep_lookup+0xb2 softdep_change_linkcnt(cacb4ec4) at softdep_change_linkcnt+0x25 ufs_inactive(e7ec8730,e7ec8748,c05722e6,e7ec8730,c070c460) at ufs_inactive+0x133 ufs_vnoperate(e7ec8730,c070c460,ca8aae70,c25be960,e7ec876c) at ufs_vnoperate+0x13 vput(ca8aae70,c06fc7d8,cfbf9e80,ca8aae70,d181d940) at vput+0x10e handle_workitem_remove(d181d940,ca8aae70) at handle_workitem_remove+0x101 process_worklist_item(0,10,0,10,0) at process_worklist_item+0x161 request_cleanup(1,1) at request_cleanup+0x66 inodedep_lookup(c25ad000,1954e,1,e7ec87ec,c06fc7d8) at inodedep_lookup+0xb2 softdep_change_linkcnt(c5a8c71c) at softdep_change_linkcnt+0x25 ufs_inactive(e7ec883c,e7ec8854,c05722e6,e7ec883c,c070c460) at ufs_inactive+0x133 ufs_vnoperate(e7ec883c,c070c460,cba16630,c25be960,e7ec8878) at ufs_vnoperate+0x13 vput(cba16630,c06fc7d8,cdf36a80,cba16630,cfac2060) at vput+0x10e handle_workitem_remove(cfac2060,cba16630) at handle_workitem_remove+0x101 process_worklist_item(0,10,0,10,0) at process_worklist_item+0x161 [...about another dozen iterations of this...] request_cleanup(1,1) at request_cleanup+0x66 inodedep_lookup(c25ad000,19534,1,e7ec9ab4,c06fc7d8) at inodedep_lookup+0xb2 softdep_change_linkcnt(c4424c94) at softdep_change_linkcnt+0x25 ufs_inactive(e7ec9b04,e7ec9b1c,c05722e6,e7ec9b04,c070c460) at ufs_inactive+0x133 ufs_vnoperate(e7ec9b04,c070c460,c49df840,c25be960,e7ec9b40) at ufs_vnoperate+0x13 vput(c49df840,c06fc7d8,cd388c80,c49df840,cfe438c0) at vput+0x10e handle_workitem_remove(cfe438c0,c49df840) at handle_workitem_remove+0x101 process_worklist_item(0,10,0,c646f604,e7ec9ba0) at process_worklist_item+0x161 request_cleanup(2,0) at request_cleanup+0x5d newdirrem(d6e61488,c646f604,c5c58dac,0,e7ec9bbc) at newdirrem+0x3b softdep_setup_remove(d6e61488,c646f604,c5c58dac,0,c5c58dac) at softdep_setup_remove+0x1c ufs_dirremove(c4d78d68,c5c58dac,800c,0,e7ec9c34) at ufs_dirremove+0x135 ufs_remove(e7ec9c38,e7ec9cc4,c0576b30,e7ec9c38,c2558c00) at ufs_remove+0x4b ufs_vnoperate(e7ec9c38) at ufs_vnoperate+0x13 kern_unlink(c25be960,8056aa8,0,c0716540,0) at kern_unlink+0x144 unlink(c25be960,e7ec9d14,1,7d,292) at unlink+0x29 syscall(805002f,804002f,bfbf002f,1,804c000) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (10, FreeBSD ELF32, unlink), eip = 0x280c258f, esp = 0xbfbfe82c, ebp = 0xbfbfe858 --- looks like infinite recursion until it blew teh stack Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:52: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 7152C16A4CE for ; Thu, 9 Sep 2004 14:52:55 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE8AC43D55 for ; Thu, 9 Sep 2004 14:52:54 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id EEB0150C16 for ; Thu, 9 Sep 2004 23:52:53 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 54C8A50B7E for ; Thu, 9 Sep 2004 23:52:52 +0900 (JST) Date: Thu, 09 Sep 2004 23:52:52 +0900 Message-ID: <7mfz5rsddn.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current In-Reply-To: <7mhdq7sdvn.wl@black.imgsrc.co.jp> References: <7mhdq7sdvn.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: Re: panic: mutex Giant not owned 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, 09 Sep 2004 14:52:55 -0000 At Thu, 09 Sep 2004 23:42:04 +0900, kuriyama wrote: > This is current as of 2004.09.08.20.00.00+00. After this message, I tried to take a dump. ----- db> panic panic: from debugger cpuid = 1 boot() called on cpu#1 Uptime: 6h15m31s Dumping 2047 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584 1600 1616 1632 1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808 1824 1840 1856 1872 1888 1904 1920 1936 1952 1968 1984 2000 2016 2032 Dump complete Shutting down ACPI ACPI-0265: *** Error: Hardware never changed modes panic: pmap_invalidate_page: interrupts disabled cpuid = 1 KDB: enter: panic [thread 100305] Stopped at kdb_enter+0x2b: nop db> trace kdb_enter(c068845a) at kdb_enter+0x2b panic(c06a2f43,c066bcdb,0,c0744e40,ed1397bc) at panic+0x127 pmap_invalidate_page(c0744e40,c4624000) at pmap_invalidate_page+0x2a pmap_enter(c0744e40,c4624000,c1109778,7,1,c072bba0,4725,0) at pmap_enter+0x21c kmem_malloc(c103a0c0,1000,101,ed139844,c0614aa5) at kmem_malloc+0x367 page_alloc(c1044840,1000,ed139837,101,40) at page_alloc+0x1a slab_zalloc(c1044840,101,c1044840,c06da764,c1045460) at slab_zalloc+0xa1 uma_zone_slab(c1044840,1,c1045468,0,c069deed,856) at uma_zone_slab+0xd0 uma_zalloc_internal(c1044840,0,1,0,c1033468) at uma_zalloc_internal+0x29 bucket_alloc(80,1,1,1,c1045960) at bucket_alloc+0x4c uma_zfree_arg(c1033420,c34a9540,c34a9e20) at uma_zfree_arg+0x22c free(c34a9540,c0838660,ed139918,c081312a,c34a9540) at free+0xd1 AcpiOsFree(c34a9540,0,c34a9580,3,ed139930) at AcpiOsFree+0x10 AcpiNsDeleteChildren(c34a9580,c3537a80,c344d000,c344d00c,ed13993c) at AcpiNsDeleteChildren+0x6e AcpiNsDeleteNamespaceSubtree(c0838e14,ed139944,c081ca65,ed13994c,c081d970) at AcpiNsDeleteNamespaceSubtree+0x53 AcpiNsTerminate(ed13994c,c081d970,ed139958,c081f6af,c08337ca) at AcpiNsTerminate+0xe AcpiUtSubsystemShutdown(ed139958,c081f6af,c08337ca,ed139998,c04fe29b) at AcpiUtSubsystemShutdown+0x1d AcpiTerminate(c08337ca,ed139998,c04fe29b,c34d3400,104) at AcpiTerminate+0x8 acpi_shutdown_final(c34d3400,104,c344d00c,0,c068847e) at acpi_shutdown_final+0x8f boot(104,104,c43d27d0,0,c06a8964) at boot+0x61f panic(c067141e,ed139a78,c0444898,c051411f,0) at panic+0x175 db_panic(c051411f,0,ffffffff,ed1399ec,0) at db_panic+0xd db_command(c06e7424,c06ae180,c06a8964,c06a8968,c067142c) at db_command+0x264 db_command_loop(0,0,ed139aa4,ed139a90,ed139ad8) at db_command_loop+0x5c db_trap(3,0,3,c43d27d0,ed139b24) at db_trap+0xdd kdb_trap(3,0,ed139b2c) at kdb_trap+0x8b trap(ed130018,c0510010,c0680010,c0687917,1) at trap+0x480 calltrap() at calltrap+0x5 --- trap 0x3, eip = 0xc051411f, esp = 0xed139b6c, ebp = 0xed139b6c --- kdb_enter(c068845a) at kdb_enter+0x2b panic(c0687917,c0698812,c06857cf,536,c4262bf4) at panic+0x127 _mtx_assert(c06f2280,1,c06857cf,536,c4262bf4) at _mtx_assert+0x5c kqueue_close(c4262bf4,c43d27d0) at kqueue_close+0x28 fdrop_locked(c4262bf4,c43d27d0,c344bd24,0,c06853b7) at fdrop_locked+0x84 fdrop(c4262bf4,c43d27d0) at fdrop+0x24 kevent(c43d27d0,ed139d14,6,7,282) at kevent+0x1d6 syscall(2f,2f,2f,bfaedb80,1) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (363, FreeBSD ELF32, kevent), eip = 0x281e5c4b, esp = 0xbfaedb54, ebp = 0xbfaedfc0 --- ----- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 14:54: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 E20A416A4CE for ; Thu, 9 Sep 2004 14:54:51 +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 4808D43D41 for ; Thu, 9 Sep 2004 14:54:51 +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 i89Esoir038020; Thu, 9 Sep 2004 16:54:50 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41406E8D.9040801@DeepCore.dk> Date: Thu, 09 Sep 2004 16:54:05 +0200 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: Mark Daniel Reidel References: <413FE07E.2070302@mark.reidel.info> In-Reply-To: <413FE07E.2070302@mark.reidel.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: DMA-aware drive runs at PIO since upgrading to 5.3beta 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, 09 Sep 2004 14:54:52 -0000 Mark Daniel Reidel wrote: > Hi there! >=20 > Since I upgraded from a current as of end of July to 5.3 beta2, I=20 > noticed, that by CDRW now runs on PIO4 which is quite annoying, since i= t=20 > was running on WDMA perfectly well before :o( My other drive, a DVD is = > detected fine, here's the dmesg snip: > Any idea why it's doing this? My other PC at work has a CDROM which is = > also now run on PIO4 instead of DMA since the upgrade, so I guess it's = > nothing specific to my hardware since I have an Athlon and a P4 at work= =2E > Any help would be appreciated, because burning at PIO4 is not what I'd = > like to to from now on as you can imagine ;o) We have changed the default to be DMA enabled on ATAPI devices. However=20 for that to have a chance to work I changed the logic so we only enable=20 DMA on UDMA33 capable ATAPI devices. This is because *lots* of old ATAPI = device claim DMA but cant, only ollowing UDMA33 sorts out most if not=20 all those buggy devices. Now if you want DMA on your drive, just use atacontrol to set the mode=20 you want. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 15:07: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 2B4DE16A4CE; Thu, 9 Sep 2004 15:07:29 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAEFC43D41; Thu, 9 Sep 2004 15:07:28 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id i89F7LCQ034580; Thu, 9 Sep 2004 11:07:23 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <200409090855.i898t1R8072488@apollo.backplane.com> References: <200409090855.i898t1R8072488@apollo.backplane.com> Date: Thu, 9 Sep 2004 16:36:40 +0200 To: Matthew Dillon From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: Gerrit Nagelhout cc: scottl@freebsd.org cc: Robert Watson cc: current@freebsd.org Subject: Re: FreeBSD 5.3 Bridge performance take II 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, 09 Sep 2004 15:07:29 -0000 At 1:55 AM -0700 2004-09-09, Matthew Dillon wrote: > If you don't believe that the slab allocator has severe performance > issues then the slab allocator (aka malloc()) should simply be used > directly. If you do believe that the slab allocator has severe > performance issues then the correct solution is to FIRST FIX THE > SLAB ALLOCATOR. I think Robert's point was that we don't know for sure how badly this part of the system may be broken, or what the best fix is to apply. My understanding is that he's trying to instrument the thing so that he can simulate various different alternatives and see which appears to be the best solution (if anything actually needs to be done). Once that decision has been made, then you can start work on implementing the real solution. You also get a nice prototype/second system effect as a result. The alternative which you seem to be advocating seems to me to be a classic case of "READY, FIRE, AIM!" > It seems clear to me that it makes little sense to spend time > on a per-thread memory cache when a per-cpu memory cache is, just from > an algorithmic point of view, going to be far more effective, far > easier to manage, possible to have larger (deterministic) hysteresis > without creating too much non-deterministic slop, and so on and so forth. You may believe that to be true, but I think Robert is saying that he wants to try to gather some hard evidence before he tries to implement any given solution. > If this is just an experiment, and therefore something that will never > be committed, then I still don't understand why you are even wasting time > working on it when you could be fixing the slab allocator instead. This seems to me to be a case of making some assumptions about where the cart may be and instead focusing exclusively on trying to first optimize the horse location. I don't know what Robert's ultimately going to do, but I appreciate the fact that he's taking time to try to measure various different options for the subsystem he's considering, before he starts slashing and burning in the codebase. More importantly, he's communicating with a relatively large group of important members of the user base as to what he's got cooking in his testbed, and telling us something of the methods he intends to use to measure the performance of the different options. This speaks volumes to me, and seems to be a wonderful change from the behaviour that we in this community have occasionally seen apparently coming from other people. Those other people may very well have been doing their own scientific measurement process before they started making changes. However, regardless of whatever they were doing behind closed doors, and whatever select members of core@ that they may have been talking to about these issues, I certainly don't recall seeing them talking to the current@ community about what they had going on before we had and announcement of a large-scale change sprung on us. Good communications with the user base is key. Robert seems to me to be making a big improvement in this area, and I hope this is a trend that will continue. > Well, I guess identifying the problem areas is good, but it isn't > rocket science. It should be glaringly obvious without requiring > all that much actual testing. I'm not convinced of that, at least not in this case. Certainly, there are situations where a casual inspection of the code will identify glaring issues that need to be resolved. However, this is one of the most critical parts of the entire OS, and I think Robert is being very intelligent by deciding that he's going to try to avoid making any assumptions going in and will instead try all the various different options and see what works best. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 15:12: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 64FB416A4CE; Thu, 9 Sep 2004 15:12:11 +0000 (GMT) Received: from smtp-bedford-dr.mitre.org (smtpproxy2.mitre.org [192.160.51.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B50FD43D2D; Thu, 9 Sep 2004 15:12:10 +0000 (GMT) (envelope-from jandrese@mitre.org) Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) i89FCAT08492; Thu, 9 Sep 2004 11:12:10 -0400 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 09FD54F8DE; Thu, 9 Sep 2004 11:12:10 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) i89FC2D07788; Thu, 9 Sep 2004 11:12:02 -0400 Received: from mm112324-2k.mitre.org (128.29.24.43) by mailhub2.mitre.org with SMTP id 4569056; Thu, 09 Sep 2004 11:11:54 -0400 Message-ID: <414072B9.1030703@mitre.org> Date: Thu, 09 Sep 2004 11:11:53 -0400 From: Jason Andresen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jason References: <20040908084352.GB69729@nevermind.kiev.ua> <413FADB9.401@ec.rr.com> In-Reply-To: <413FADB9.401@ec.rr.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-x11@freebsd.org Subject: Re: X11 driver not configured with OpenGL 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, 09 Sep 2004 15:12:11 -0000 jason wrote: >> I'm trying to run neverball (ports/games/neverball), which is OpenGL 3D >> game. But it fails to start with error message: >> >> $ neverball neverball: X11 driver not configured with OpenGL >> >> I'm using 5.2.1-RELEASE with nVidia binary drivers >> nvidia-driver-1.0.6113, but the same effect was with older drivers. >> >> Please, help me to undertand what direction should I dig to? >> I think there was a version of the nvidia driver in the ports tree that didn't install the glx module correctly. I ran into the same problem earlier and a portupgrade -f nvidia-driver fixed the problem. You can also check your X log to see if the glx module failed to load (mine had old symbols in it). From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 16:10: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 9EB3D16A4CE for ; Thu, 9 Sep 2004 16:10:30 +0000 (GMT) Received: from www.cyclades.de (mail.cyclades.de [62.225.173.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A45A43D5A for ; Thu, 9 Sep 2004 16:10:30 +0000 (GMT) (envelope-from mh@kernel32.de) Received: from pd9e0e04b.dip.t-dialin.net ([217.224.224.75] helo=[192.168.100.104]) by www.cyclades.de with asmtp (Exim 3.35 #1 (Debian)) id 1C5RV0-0000wj-00; Thu, 09 Sep 2004 18:10:14 +0200 Message-ID: <41408070.4060107@kernel32.de> Date: Thu, 09 Sep 2004 18:10:24 +0200 From: Marian Hettwer User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hunter References: <413EB55D.4060307@kernel32.de> <20040908162133.GA17274@ack.Berkeley.EDU> In-Reply-To: <20040908162133.GA17274@ack.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-MailScanner-SpamCheck: cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA3 serial console 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, 09 Sep 2004 16:10:30 -0000 Hi Mike, Mike Hunter wrote: > On Sep 08, "Marian Hettwer" wrote: > > > > Sorry this doesn't answer the question, but what's the status of using > "-h" in /boot.config instead of mucking with the /etc files? Is that The /boot.config is toggling around with the serial console for the boot loader and the bootup process. /etc/ttys is needed to enable a serial console after the bootprocess is finished. Thing of something like a getty in Linux running on ttyS0 ... at least this is how I understood serial consoles in FreeBSD-4 ... If I was wrong, I'm sure somebody on this list would correct me ;) best regards, Marian From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 16:30: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 446CB16A4D8 for ; Thu, 9 Sep 2004 16:30:59 +0000 (GMT) Received: from www.cyclades.de (mail.linux-router.org [62.225.173.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D146343D3F for ; Thu, 9 Sep 2004 16:30:58 +0000 (GMT) (envelope-from mh@kernel32.de) Received: from pd9e0e04b.dip.t-dialin.net ([217.224.224.75] helo=[192.168.100.104]) by www.cyclades.de with asmtp (Exim 3.35 #1 (Debian)) id 1C5Rox-00018Z-00; Thu, 09 Sep 2004 18:30:51 +0200 Message-ID: <41408544.7010303@kernel32.de> Date: Thu, 09 Sep 2004 18:31:00 +0200 From: Marian Hettwer User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Chadwick References: <20040908143213.97046.qmail@web50707.mail.yahoo.com> <413F2361.7040904@kernel32.de> <20040908155158.GA1507@parodius.com> In-Reply-To: <20040908155158.GA1507@parodius.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-MailScanner-SpamCheck: cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA3 serial console 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, 09 Sep 2004 16:30:59 -0000 Hej Jeremy, Jeremy Chadwick wrote: > This could possibly be an issue with your BIOS; "COM1" disabled in the > BIOS could caus what you're seeing (especially the initial line, "sio0: > configured irq 4 not in bitmap of probed irqs 0"). > D'oh! The serial port was disabled in BIOS ... bloody hell! Shame on me, or the Linux-using Co-Worker of mine who used this Laptop before me ... Well... sorry for the noise :-/ Now it's working (obviously) ... However... come to think of it, a deadlock because there is no serial port doesn't sound good to me anyway. If there's no serial port, why not giving out an error message like "no sio[0,1] available, cannot start getty on ttyd0" ? well, thanks anyway for pointing my head into the right direction. best regards, Marian From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 17:14: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 E3F6216A4CE; Thu, 9 Sep 2004 17:14:07 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3DBC43D2D; Thu, 9 Sep 2004 17:14:05 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Thu, 09 Sep 2004 10:14:04 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CAC5B5D04; Thu, 9 Sep 2004 10:14:04 -0700 (PDT) To: "Bjoern Koenig" In-reply-to: Your message of "Wed, 08 Sep 2004 12:29:03 +0200." <20040908102753.6B6A862D7@hoppel.local> Date: Thu, 09 Sep 2004 10:14:04 -0700 From: "Kevin Oberman" Message-Id: <20040909171404.CAC5B5D04@ptavv.es.net> cc: freebsd-current@freebsd.org cc: sos@freebsd.org Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 17:14:08 -0000 > From: "Bjoern Koenig" > Date: Wed, 8 Sep 2004 12:29:03 +0200 > Sender: owner-freebsd-current@freebsd.org > > Hello, > > first time I installed a beta of FreeBSD 5.3 I noticed very poor disk = > speed. > I built a kernel without this whole debugging stuff; but it remains bad. = > I > supposed that this issue depends on further debugging features which I > didn't know. So I waited until UPDATING told that debugging options are > removed from kernel and userland. Now I built a new kernel again and the > disk speed is still unacceptable. Is there any further debugging option? > > Some facts: > > FreeBSD 5.3-BETA3 without any debugging: > per char write: 13.78 MB/s (32.7% CPU usage) > block write: 13.97 MB/s (12.8%) > per char read: 22.31 MB/s (45.2%) > block read: 37.44 MB/s (14.8%) > > FreeBSD 4.10-STABLE: > per char write: 37.29 MB/s (75.7%) > block write: 36.91 MB/s (28.7%) > per char read: 38.53 MB/s (80.4%) > block read: 37.45 MB/s (10.9%) > > (tested with bonnie, atacontrol shows UDMA100 both) > > Controller: Intel 82801BA (ICH2) > Hard disk: Seagate ST380021A I had previously reported this. I did some testing with the assistance of Robert Watson and it appears that the issue is ATA. The thread had a subject of "Disk performance under CURRENT" and was back in May. I plotted out the times for various sizes of I/O and the only real issue was with write. The per character speed should increase fairly quickly with increased I/O size and did for V4 and for reads. For writes, it started the same for short writes as these tend to be CPU bound. But, for longer writes, the increase in speed is MUCH less than it was with V4 write or for reads and throughput tops out at between 16 and 32KB transfers at something far below what I saw in V4. I was also hearing a LOT of disk seek operations that did not seem appropriate to me. (I did the testing with dd(1) in single-user mode.) FWIW, I did my tests on an IBM T30 which is a P4@1.8 GHz with ICH3 support chips. Looking back at the history in my e-mail archive, I'm not certain that sos@ was copied. Ouch! Mea culpa! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 17:17: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 83E9F16A4CE; Thu, 9 Sep 2004 17:17:58 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3C1743D5F; Thu, 9 Sep 2004 17:17:57 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id i89HHsiI025222; Fri, 10 Sep 2004 02:17:54 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id i89HHsJ9025221; Fri, 10 Sep 2004 02:17:54 +0900 (KST) (envelope-from ssw) Date: Fri, 10 Sep 2004 02:17:54 +0900 From: Sangwoo Shim To: Robert Watson Message-ID: <20040909171754.GA25172@neo.redjade.org> References: <20040905053005.GA80420@neo.redjade.org> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: mlaier@freebsd.org cc: current@freebsd.org Subject: Re: syscons problem in ddb, if_afdata initialization (was: Re: 5.3-BETA3 , panic, probably IPv6+SMP+mpsafenet related) 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, 09 Sep 2004 17:17:58 -0000 FYI, I've got exactly same panic even after your patch committed. (and debug.mpsafenet=0) This box runs stock -CURRENT of some days ago. And I don't much care about panicing this system. Please feel free to ask to do tests. :-) ssw:~ $ uname -a FreeBSD ssw.dyndns.org 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Wed Sep 8 09:05:24 KST 2004 root@ssw.dyndns.org:/usr/obj/usr/src/sys/SSW-SMP i386 ssw:~ $ sysctl debug.mpsafenet debug.mpsafenet: 0 ssw:~ $ ident /usr/src/sys/netinet6/nd6.c /usr/src/sys/netinet6/nd6.c: $FreeBSD: src/sys/netinet6/nd6.c,v 1.45 2004/09/05 17:27:54 rwatson Exp $ $KAME: nd6.c,v 1.144 2001/05/24 07:44:00 itojun Exp $ ssw:~ $ Regards, Sangwoo On Sun, Sep 05, 2004 at 01:52:32AM -0400, Robert Watson wrote: > > This patch may only fix the problem if running with debug.mpsafenet=0; I'm > currently exploring the more general if_afdata issues, and will look at > Max's patch (etc) in the report. I hope to have a patch that solves it in > the non-mpsafenet case in a day or two. > > Thanks! > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > > > > Regards, > > Sangwoo > > > > On Sat, Sep 04, 2004 at 03:33:28PM -0400, Robert Watson wrote: > > > > > > On Sat, 4 Sep 2004, Jan Srzednicki wrote: > > > > > > > OK. I'm not sure if I'm doing that the right way, but here it is: > > > > > > Yes, this was exactly what I was looking for. Thanks! > > > > > > > > > > > > > Hope this helps. > > > > > > > > It's also worth noting that on the previous kernel (that is: FreeBSD > > > > 5.3-BETA2 (SIN) #9: Sun Aug 29 14:24:19 CEST 2004) nothing like that > > > > happened, so it appears to be somehow related to (or uncovered by) some > > > > very recent commit. > > > > > > Could you try this patch: > > > > > > Index: nd6.c > > > =================================================================== > > > RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v > > > retrieving revision 1.44 > > > diff -u -r1.44 nd6.c > > > --- nd6.c 23 Aug 2004 03:00:27 -0000 1.44 > > > +++ nd6.c 4 Sep 2004 19:34:39 -0000 > > > @@ -134,6 +134,7 @@ > > > nd6_init_done = 1; > > > > > > /* start timer */ > > > + callout_init(&nd6_slowtimo_ch, 0); > > > callout_reset(&nd6_slowtimo_ch, ND6_SLOWTIMER_INTERVAL * hz, > > > nd6_slowtimo, NULL); > > > } > > > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > > > > _______________________________________________ > > > 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 Sep 9 17:49: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 BDB2216A4CE; Thu, 9 Sep 2004 17:49:15 +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 E8D9743D58; Thu, 9 Sep 2004 17:49:14 +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 i89Hn2iD039496; Thu, 9 Sep 2004 19:49:02 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41409764.4040708@DeepCore.dk> Date: Thu, 09 Sep 2004 19:48:20 +0200 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: Kevin Oberman References: <20040909171404.CAC5B5D04@ptavv.es.net> In-Reply-To: <20040909171404.CAC5B5D04@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 17:49:15 -0000 Kevin Oberman wrote: >>From: "Bjoern Koenig" >>Date: Wed, 8 Sep 2004 12:29:03 +0200 >>Sender: owner-freebsd-current@freebsd.org >> >>Hello, >> >>first time I installed a beta of FreeBSD 5.3 I noticed very poor disk =3D= >>speed. >>I built a kernel without this whole debugging stuff; but it remains bad= =2E =3D >>I >>supposed that this issue depends on further debugging features which I >>didn't know. So I waited until UPDATING told that debugging options are= >>removed from kernel and userland. Now I built a new kernel again and th= e >>disk speed is still unacceptable. Is there any further debugging option= ? >> >>Some facts: >> >>FreeBSD 5.3-BETA3 without any debugging: >> per char write: 13.78 MB/s (32.7% CPU usage) >> block write: 13.97 MB/s (12.8%) >> per char read: 22.31 MB/s (45.2%) >> block read: 37.44 MB/s (14.8%) >> >>FreeBSD 4.10-STABLE: >> per char write: 37.29 MB/s (75.7%) >> block write: 36.91 MB/s (28.7%) >> per char read: 38.53 MB/s (80.4%) >> block read: 37.45 MB/s (10.9%) >> >>(tested with bonnie, atacontrol shows UDMA100 both) >> >>Controller: Intel 82801BA (ICH2) >>Hard disk: Seagate ST380021A >=20 >=20 > I had previously reported this. I did some testing with the assistance > of Robert Watson and it appears that the issue is ATA. The thread had a= > subject of "Disk performance under CURRENT" and was back in May. >=20 > I plotted out the times for various sizes of I/O and > the only real issue was with write. The per character speed should > increase fairly quickly with increased I/O size and did for V4 and for > reads. For writes, it started the same for short writes as these tend t= o > be CPU bound. But, for longer writes, the increase in speed is MUCH les= s > than it was with V4 write or for reads and throughput tops out at > between 16 and 32KB transfers at something far below what I saw in V4. >=20 > I was also hearing a LOT of disk seek operations that did not seem > appropriate to me. (I did the testing with dd(1) in single-user mode.) >=20 > FWIW, I did my tests on an IBM T30 which is a P4@1.8 GHz with ICH3 > support chips. >=20 > Looking back at the history in my e-mail archive, I'm not certain that > sos@ was copied. Ouch! Mea culpa! I fixed a chip setup problem on the ICH* chips some days ago, its has=20 been committed to RELENG_5 as well. However it would normally be=20 harmless if the BIOS has set the mode (which it normally does). Besides that, I know of no problems performance wise. Disk seek=20 operations during sequential access suggests that there is something=20 else going on simultanious to the test as the driver doesn't issue seeks = without being asked to from the system. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 18:06: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 3FD5116A4CE for ; Thu, 9 Sep 2004 18:06:00 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C3D43D1D for ; Thu, 9 Sep 2004 18:06:00 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 17177 invoked from network); 9 Sep 2004 18:05:59 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 18:05:59 -0000 Received: from hydrogen.funkthat.com (jylqnu@localhost.funkthat.com [127.0.0.1])i89I5xuU085347; Thu, 9 Sep 2004 11:05:59 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i89I5w7M085346; Thu, 9 Sep 2004 11:05:58 -0700 (PDT) Date: Thu, 9 Sep 2004 11:05:57 -0700 From: John-Mark Gurney To: Jun Kuriyama Message-ID: <20040909180557.GM72089@funkthat.com> Mail-Followup-To: Jun Kuriyama , Current References: <7mhdq7sdvn.wl@black.imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7mhdq7sdvn.wl@black.imgsrc.co.jp> 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: Current Subject: Re: panic: mutex Giant not owned 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, 09 Sep 2004 18:06:00 -0000 Jun Kuriyama wrote this message on Thu, Sep 09, 2004 at 23:42 +0900: > This is current as of 2004.09.08.20.00.00+00. > > This panic is happened during test for kqueue-using application. > > ----- > panic: mutex Giant not owned at /usr/src/sys/kern/kern_event.c:1334 Just remove the GIANT_REQUIRED; line on 1334, and try again... If this works for you, I'll commit the fix... -- 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 Sep 9 18:38: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 6215C16A4D1 for ; Thu, 9 Sep 2004 18:38:28 +0000 (GMT) Received: from gate.multicom.lv (gate.multicom.lv [159.148.36.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 150D343D49 for ; Thu, 9 Sep 2004 18:38:27 +0000 (GMT) (envelope-from andris@multicom.lv) Received: from dove (ip-181-135.i-net.lv [159.148.181.135] (may be forged)) by gate.multicom.lv (8.13.1/8.13.1) with ESMTP id i89IcNIQ028812 for ; Thu, 9 Sep 2004 21:38:23 +0300 (EEST) (envelope-from andris@multicom.lv) Message-Id: <200409091838.i89IcNIQ028812@gate.multicom.lv> X-AntiVirus: Checked by Dr.Web [version: 4.32a, engine: 4.32a, virus records: 54365, updated: 9.09.2004] From: "Andris" To: Date: Thu, 9 Sep 2004 21:38:17 +0300 Organization: JSC MultiCOm MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSWnCvzp+n0cFtZQKe2sZo+og14EA== X-Virus-Scanned: clamd / ClamAV version devel-20040905, clamav-milter version 0.75l on gate.multicom.lv X-Virus-Status: Clean X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gate.multicom.lv Subject: Sil0680 + Maxtor 300Gb drives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andris@multicom.lv List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 18:38:28 -0000 Hi! I have problem with Sil0680 based ATA RAID controller + Maxtor 300Gb HDDs (I use it as ATA controller). On booth channels slave drives work without any problems. But when I try to do something with master drives I see something like this: ad4: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63 ad4: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63 ad4: FAILURE - WRITE_DMA status=51 error=84 LBA=63 ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63 ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63 ad6: FAILURE - WRITE_DMA status=51 error=84 LBA=63 ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63 ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=63 The system is 5.3-BETA3. Andris From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:10: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 25C2316A4CE for ; Thu, 9 Sep 2004 19:10:13 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDDE643D5D for ; Thu, 9 Sep 2004 19:10:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4896 invoked from network); 9 Sep 2004 19:10:12 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Sep 2004 19:10:12 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i89J9xOj009185; Thu, 9 Sep 2004 15:09:59 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 9 Sep 2004 13:00:17 -0400 User-Agent: KMail/1.6.2 References: <20040908164444.GA65512@peter.osted.lan> <413F5DC1.7060504@elischer.org> In-Reply-To: <413F5DC1.7060504@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409091300.17226.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: current@FreeBSD.org Subject: Re: panic: deadlock in setrunqueue 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, 09 Sep 2004 19:10:13 -0000 On Wednesday 08 September 2004 03:30 pm, Julian Elischer wrote: > wow that's a lot of threaded processes :-) > > is this with SCHED_4BSD? (looks like it). > > interestigly the thread that is being originally put on the run queueu > (0xc1536320) doesn't appear in teh ps at all! ps doesn't print thread pointers for non-threaded apps, so that's not all that surprising actually. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:10: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 352C616A4CF for ; Thu, 9 Sep 2004 19:10:13 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED87243D45 for ; Thu, 9 Sep 2004 19:10:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4896 invoked from network); 9 Sep 2004 19:10:12 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Sep 2004 19:10:12 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i89J9xOj009185; Thu, 9 Sep 2004 15:09:59 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 9 Sep 2004 13:00:17 -0400 User-Agent: KMail/1.6.2 References: <20040908164444.GA65512@peter.osted.lan> <413F5DC1.7060504@elischer.org> In-Reply-To: <413F5DC1.7060504@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409091300.17226.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: current@FreeBSD.org Subject: Re: panic: deadlock in setrunqueue 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, 09 Sep 2004 19:10:13 -0000 On Wednesday 08 September 2004 03:30 pm, Julian Elischer wrote: > wow that's a lot of threaded processes :-) > > is this with SCHED_4BSD? (looks like it). > > interestigly the thread that is being originally put on the run queueu > (0xc1536320) doesn't appear in teh ps at all! ps doesn't print thread pointers for non-threaded apps, so that's not all that surprising actually. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:10: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 AC2DB16A4CF for ; Thu, 9 Sep 2004 19:10:23 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B74D43D1F for ; Thu, 9 Sep 2004 19:10:23 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26390 invoked from network); 9 Sep 2004 19:10:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Sep 2004 19:10:22 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i89J9xOk009185; Thu, 9 Sep 2004 15:10:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 9 Sep 2004 13:22:19 -0400 User-Agent: KMail/1.6.2 References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> In-Reply-To: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409091322.19501.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Mike Tancsa Subject: Re: SIO Interrupt storms and unhanded interrupts 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, 09 Sep 2004 19:10:24 -0000 On Wednesday 08 September 2004 07:25 pm, Mike Tancsa wrote: > I think we have been bouncing around this issue for the past few months > both on RELENG_4 and now RELENG_5. In the past it has been somewhat > difficult to reproduce, but now we can do it reliably. I dont think its > a hardware issue as I can take the exact same 2 boxes with the exact same > IRQ assignments and boot with OpenBSD and not run into an interrupt storm > or freeze up the box. Swap back the RELENG_4 or RELENG_5 HD and again, I > can produce an interrupt storm at will. > > I can also reproduce it on 2 different chipsets as well (VIA and > Intel). The problem seems to be around how a PUC device (either a PCI > modem or a PCI serial card) and the sharing of an interrupt (usually an USB > controller, but not always). > > On RELENG_4, the box just locks up in a race trying to service an interrupt > on IRQ 12 but remains unhandled. > > On RELENG_5, I actually catch an interrupt storm. e.g. I attach to sio4 > (PUC modem) and > > Interrupt storm detected on "irq12: uhci1"; throttling interrupt source > > Looking at vmstat -i does indeed show a the rate getting throttled > > releng-5-pioneer# vmstat -i > interrupt total rate > irq0: clk 596719 99 > irq1: atkbd0 2 0 > irq4: sio0 1079 0 > irq6: fdc0 1 0 > irq8: rtc 763812 127 > irq12: uhci1 5825 0 > irq13: npx0 1 0 > irq14: ata0 38727 6 > irq15: vr0 ata1 1984 0 > Total 1408150 235 > releng-5-pioneer# > > where irq12 is the IRQ shared by the modem and the USB port. However, > because all IRQ 12s get throttled, the modem is unusable. e.g. trying to cu > -l /dev/cuaa4 and typing atz takes about 5 seconds. > > > Is there some way to safely tell the kernel that the PUC device that its > shareable ? We did this perhaps very ugly hack on RELENG_4 > > > @@ -1431,15 +1431,19 @@ > > rid = 0; > com->irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0ul, > ~0ul, 1, - RF_ACTIVE); > +/* RF_ACTIVE); */ > + RF_SHAREABLE); > > to /usr/src/sys/isa/sio.c > > and at least we can talk to the sio device. However, on RELENG_5 there > does not seem to be the same fix. > > My question is this-- Is the root cause the same issue on RELENG_4 and > RELENG_5 ? Are we going about it the best way to fix the problem ? Or is > the underlying problem something else ? > > Attached is a dmesg and acpidump You can do a similar hack to puc/sio in 5.x, but you also need to remove the 'INTR_FAST' flag to bus_setup_intr() for it to work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:10: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 5B31A16A4E7 for ; Thu, 9 Sep 2004 19:10:45 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1713543D46 for ; Thu, 9 Sep 2004 19:10:45 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5886 invoked from network); 9 Sep 2004 19:10:44 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Sep 2004 19:10:44 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i89J9xOm009185; Thu, 9 Sep 2004 15:10:32 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 9 Sep 2004 13:47:19 -0400 User-Agent: KMail/1.6.2 References: <20040909023413.T14321@bpgate.speednet.com.au> In-Reply-To: <20040909023413.T14321@bpgate.speednet.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409091347.19431.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Andy Farkas Subject: Re: panic: APIC: Previous IPI is stuck 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, 09 Sep 2004 19:10:45 -0000 On Wednesday 08 September 2004 12:39 pm, Andy Farkas wrote: > My box is still crashing with above APIC panic when I do a > make -j4 buildworld. > > In file src/sys/i386/i386/local_apic.c I tried increasing > BEFORE_SPIN to 100000000 but it still panics. > > Any suggestions on why this is happenning? Try changing the consant to -1. Note that I apparently just managed to trigger a hard lockup on my test machine here with that change, but it had managed to run for about 20 hours under heavy load that panic'd in a few hours on a stock kernel. > FreeBSD 5.3-BETA3 #1: Wed Sep 8 00:37:07 EST 2004 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium Pro (198.95-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x619 Stepping = 9 > Features=0xfbffOV> real memory = 536870912 (512 MB) > avail memory = 519897088 (495 MB) > MPTable: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 4 > ioapic0: Assuming intbase of 0 > ioapic1: Assuming intbase of 16 > ioapic1 irqs 16-31 on motherboard > ioapic0 irqs 0-15 on motherboard > .. > > > -andyf > > _______________________________________________ > 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" -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:29: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 2697716A4CE for ; Thu, 9 Sep 2004 19:29:31 +0000 (GMT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F27543D31 for ; Thu, 9 Sep 2004 19:29:30 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from frederic (linux-win.com [62.212.121.38]) by kraid.nerim.net (Postfix) with SMTP id C07A9418F3 for ; Thu, 9 Sep 2004 21:29:27 +0200 (CEST) Message-ID: <001501c496a3$4db06ce0$0401a8c0@frederic> From: "cell" To: Date: Thu, 9 Sep 2004 21:29:19 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: netgear wg311 v2 and project evil 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, 09 Sep 2004 19:29:31 -0000 hello , i have problem when i configure my wep key.I use the access = point linksys wap54g and and i have decided a wep key in my access point = but freebsd can't connect to the access point.I use passphrase for = create my wep key but i don't know how to use passphrase with = freebsd.Anyone have an idea ? From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:30: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 D353516A4CE for ; Thu, 9 Sep 2004 19:30:58 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 769BF43D5C for ; Thu, 9 Sep 2004 19:30:58 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from pythonemproject.com (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (sccrmhc12) with ESMTP id <2004090919305701200ihs3qe> (Authid: europax); Thu, 9 Sep 2004 19:30:57 +0000 Message-ID: <4140AFB0.6020002@pythonemproject.com> Date: Thu, 09 Sep 2004 12:32:00 -0700 From: Rob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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: Still getting warning messages for rc.conf & default/rc.conf entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rob@pythonemproject.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 19:30:59 -0000 I have yet to find the source of this problem. Basically from the end of the boot sequence until I log in, I get a warning message for every rc.conf and defaults/config entry saying each are misconfigued. After I log in, the computer works fine. This 5.3beta2 on a Dell 8600 laptop 1.7Ghz and 1G of memory. As I understand it rc controls the .config process.. Maybe it needs to recompiled. I haven't tried that as this was a binary install from an iso.. Will cvsup. Rob From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:32: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 AC74116A4CF for ; Thu, 9 Sep 2004 19:32:24 +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 053F343D62 for ; Thu, 9 Sep 2004 19:32:24 +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 i89JWMeM040381; Thu, 9 Sep 2004 21:32:22 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4140AF9D.7060008@DeepCore.dk> Date: Thu, 09 Sep 2004 21:31:41 +0200 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: andris@multicom.lv References: <200409091838.i89IcNIQ028812@gate.multicom.lv> In-Reply-To: <200409091838.i89IcNIQ028812@gate.multicom.lv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: Sil0680 + Maxtor 300Gb drives 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, 09 Sep 2004 19:32:24 -0000 Andris wrote: > Hi! >=20 > I have problem with Sil0680 based ATA RAID controller + Maxtor 300Gb HD= Ds (I > use it as ATA controller). > On booth channels slave drives work without any problems. > But when I try to do something with master drives I see something like = this: >=20 > ad4: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3D63 > ad4: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3D63 > ad4: FAILURE - WRITE_DMA status=3D51 error=3D84 > LBA=3D63 > ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3D63 > ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3D63 > ad6: FAILURE - WRITE_DMA status=3D51 error=3D84 > LBA=3D63 > ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3D63 > ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=3D63 Are you sure that your cables are capable of the speed you use ? Are you sure that the cables are the right way around ? (blue connector=20 at controller grey/black for drives) A dmesg would be nice so we would know what kind of system we are=20 talking about... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:52: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 7BFF616A4CE for ; Thu, 9 Sep 2004 19:52:30 +0000 (GMT) Received: from shrike.submonkey.net (cpc2-cdif3-6-0-cust204.cdif.cable.ntl.com [81.103.67.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 344EB43D46 for ; Thu, 9 Sep 2004 19:52:30 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.42 (FreeBSD)) id 1C5Uy4-0006Qb-Sx; Thu, 09 Sep 2004 20:52:28 +0100 Date: Thu, 9 Sep 2004 20:52:28 +0100 From: Ceri Davies To: Rob Message-ID: <20040909195228.GM44674@submonkey.net> Mail-Followup-To: Ceri Davies , Rob , freebsd-current@freebsd.org References: <4140AFB0.6020002@pythonemproject.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="utPK4TBebyzZxMrE" Content-Disposition: inline In-Reply-To: <4140AFB0.6020002@pythonemproject.com> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.6i Sender: Ceri Davies cc: freebsd-current@freebsd.org Subject: Re: Still getting warning messages for rc.conf & default/rc.conf entries 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, 09 Sep 2004 19:52:30 -0000 --utPK4TBebyzZxMrE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2004 at 12:32:00PM -0700, Rob wrote: > I have yet to find the source of this problem. Basically from the end= =20 > of the boot sequence until I log in, I get a warning message for every=20 > rc.conf and defaults/config entry saying each are misconfigued. After I= =20 > log in, the computer works fine. This 5.3beta2 on a Dell 8600 laptop=20 > 1.7Ghz and 1G of memory. As I understand it rc controls the .config=20 > process.. Maybe it needs to recompiled. I haven't tried that as this=20 > was a binary install from an iso.. Will cvsup. May I suggest posting the messages that you get, along with a copy of your /etc/rc.conf file? Ceri --=20 It is not tinfoil, it is my new skin. I am a robot. --utPK4TBebyzZxMrE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBQLR8ocfcwTS3JF8RAqkqAKDF2TtpozsuzRspkwwgjUYf9sEcxgCfeRhd as5smvpXzoIVzeI9Lljenqw= =Dzwi -----END PGP SIGNATURE----- --utPK4TBebyzZxMrE-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:58: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 3FBBA16A4CE for ; Thu, 9 Sep 2004 19:58:26 +0000 (GMT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D3FC43D45 for ; Thu, 9 Sep 2004 19:58:25 +0000 (GMT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.1/8.13.1) with ESMTP id i89JwOuV018389; Thu, 9 Sep 2004 15:58:24 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.1/8.13.1/Submit) id i89JwOcC018388; Thu, 9 Sep 2004 15:58:24 -0400 (EDT) (envelope-from barney) Date: Thu, 9 Sep 2004 15:58:24 -0400 From: Barney Wolff To: cell Message-ID: <20040909195824.GA17676@pit.databus.com> References: <001501c496a3$4db06ce0$0401a8c0@frederic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c496a3$4db06ce0$0401a8c0@frederic> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org Subject: Re: netgear wg311 v2 and project evil 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, 09 Sep 2004 19:58:26 -0000 On Thu, Sep 09, 2004 at 09:29:19PM +0200, cell wrote: > hello , i have problem when i configure my wep key.I use the access point linksys wap54g and and i have decided a wep key in my access point but freebsd can't connect to the access point.I use passphrase for create my wep key but i don't know how to use passphrase with freebsd.Anyone have an idea ? The process of configuring the AP should have told you one or more WEP keys in hex. That's what you use to configure your NIC. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:02: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 467FC16A4CE; Thu, 9 Sep 2004 20:02:39 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D319B43D4C; Thu, 9 Sep 2004 20:02:38 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i89K2cfR050814; Thu, 9 Sep 2004 16:02:38 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 50609-03; Thu, 9 Sep 2004 16:02:38 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i89K2ciH050776; Thu, 9 Sep 2004 16:02:38 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i89K2TIB001886; Thu, 9 Sep 2004 16:02:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 09 Sep 2004 16:07:29 -0400 To: John Baldwin , freebsd-current@FreeBSD.org From: Mike Tancsa In-Reply-To: <200409091322.19501.jhb@FreeBSD.org> References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <200409091322.19501.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b Subject: Re: SIO Interrupt storms and unhandled interrupts 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, 09 Sep 2004 20:02:39 -0000 At 01:22 PM 09/09/2004, John Baldwin wrote: > > > > My question is this-- Is the root cause the same issue on RELENG_4 and > > RELENG_5 ? Are we going about it the best way to fix the problem ? Or is > > the underlying problem something else ? > > > > Attached is a dmesg and acpidump > >You can do a similar hack to puc/sio in 5.x, but you also need to remove the >'INTR_FAST' flag to bus_setup_intr() for it to work. Hi, Thanks for the response! We found a different solution / approach which seems to work on both RELENG_4 and RELENG_5. The problem is that the modem is not being seen as a PCI / PUC device and instead is being seen as an ISA SIO device ?? The following RELENG_5 and RELENG_4 patches seem to fix the problem. I wonder if the other modems listed in sio.c suffer the same fate ? Also fixed in this are those "cant re-use leafs" at bootup time. The modem is seen as a PUC device now.... At the bottom is a diff between the boot -v (Patches are done by keith@sentex.ca) --- orig/sio_pci.c Thu Sep 9 15:44:19 2004 +++ sio_pci.c Thu Sep 9 14:51:16 2004 @@ -76,7 +76,9 @@ { 0x048011c1, "Lucent kermit based PCI Modem", 0x14 }, { 0x95211415, "Oxford Semiconductor PCI Dual Port Serial", 0x10 }, { 0x7101135e, "SeaLevel Ultra 530.PCI Single Port Serial", 0x18 }, - { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, +/* Removed 2004/09/09 - KDW + { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, +*/ { 0x0103115d, "Xircom Cardbus modem", 0x10 }, { 0x98459710, "Netmos Nm9845 PCI Bridge with Dual UART", 0x10 }, { 0x432214e4, "Broadcom 802.11g/GPRS CardBus (Serial)", 0x10 }, releng-5-pioneer# diff -u orig/pucdata.c pucdata.c --- orig/pucdata.c Thu Sep 9 15:45:33 2004 +++ pucdata.c Thu Sep 9 15:00:43 2004 @@ -818,6 +818,17 @@ }, }, +/* ADDED 2004/09/09 - KDW - { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, */ + /* "SmartLink 5634PCV SurfRider */ + { "SmartLink 5634PCV SurfRider", + { 0x151f, 0x0000, 0, 0 }, + { 0xffff, 0xffff, 0, 0 }, + { + { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, + }, + }, +/* END KDW */ + /* US Robotics (3Com) PCI Modems */ { "US Robotics (3Com) 3CP5609 PCI 16550 Modem", { 0x12b9, 0x1008, 0, 0 }, releng-5-pioneer# vmstat now sees that the PUC device shares the interrupt and all seems well! releng-5-pioneer# vmstat -i interrupt total rate irq0: clk 205278 99 irq1: atkbd0 2 0 irq4: sio0 188 0 irq6: fdc0 1 0 irq7: uhci2 1 0 irq8: rtc 262759 127 irq12: uhci1 puc0 1194 0 irq13: npx0 1 0 irq14: ata0 1724 0 irq15: vr0 ata1 4274 2 Total 475422 231 releng-5-pioneer# and on RELENG_4 # diff -u pucdata.c orig/pucdata.c --- /usr/src/sys/dev/puc/pucdata.c Thu Sep 9 14:18:56 2004 +++ /usr/src/sys/dev/puc/orig/pucdata.c Thu Sep 9 15:50:14 2004 @@ -803,16 +803,6 @@ { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, }, }, - -/* { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, */ - /* KDW/GE SurfRider */ - { "SmartLink 5634PCV SurfRider", - { 0x151f, 0x0000, 0, 0 }, - { 0xffff, 0xffff, 0, 0 }, - { - { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, - }, - }, /* Actiontec 56K PCI Master */ { "Actiontec 56K PCI Master", --- /usr/src/sys/isa/orig/sio.c Thu Sep 9 15:51:47 2004 +++ /usr/src/sys/isa/sio.c Thu Sep 9 14:19:27 2004 @@ -602,7 +602,8 @@ { 0x048011c1, "Lucent kermit based PCI Modem", 0x14 }, { 0x95211415, "Oxford Semiconductor PCI Dual Port Serial", 0x10 }, { 0x7101135e, "SeaLevel Ultra 530.PCI Single Port Serial", 0x18 }, - { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, +/* next line removed 2004/09/08 by KDW */ +/* { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, */ { 0x98459710, "Netmos Nm9845 PCI Bridge with Dual UART", 0x10 }, { 0x00000000, NULL, 0 } }; And the boot -v diffs. 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-BETA3 #1: Wed Sep 8 18:54:01 EDT 2004 - mdtancsa@releng-5-pioneer.sentex.ca:/usr/obj/usr/src/sys/pioneer +FreeBSD 5.3-BETA3 #2: Thu Sep 9 15:09:52 EDT 2004 + keith@releng-5-pioneer.sentex.ca:/usr/obj/usr/src/sys/pioneer Preloaded elf kernel "/boot/kernel/kernel" at 0xc082c000. Preloaded elf module "/boot/modules/acpi.ko" at 0xc082c1d8. -Calibrating clock(s) ... i8254 clock: 1193179 Hz +Calibrating clock(s) ... i8254 clock: 1193185 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 -Calibrating TSC clock ... TSC clock: 1002280114 Hz +Calibrating TSC clock ... TSC clock: 1002279822 Hz CPU: VIA C3 Nehemiah (1002.28-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x691 Stepping = 1 Features=0x380b035 @@ -330,18 +330,13 @@ vr1: bpf attached vr1: Ethernet address: 00:40:63:c9:fa:98 vr1: [MPSAFE] -sio0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xe800 -sio0: irq maps: 0x1 0x1001 0x1 0x1 -sio0: port 0xe800-0xe807 irq 12 at device 20.0 on pci0 -sio0: moving to sio4 +puc0: port 0xe800-0xe807 irq 12 at device 20.0 on pci0 +puc0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xe800 +sio4: on puc0 sio4: type 16550A +sio4: unable to activate interrupt in fast mode - using normal mode fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0: irq maps: 0x1 0x11 0x1 0x1 -can't re-use a leaf (%desc)! -can't re-use a leaf (%driver)! -can't re-use a leaf (%location)! -can't re-use a leaf (%pnpinfo)! -can't re-use a leaf (%parent)! sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 @@ -431,7 +426,7 @@ isa_probe_children: probing PnP devices Device configuration finished. procfs registered -Timecounter "TSC" frequency 1002280114 Hz quality 800 +Timecounter "TSC" frequency 1002279822 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to accept, logging limited to 2100 packets/entry by default lo0: bpf attached ---Mike From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:10: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 90D7D16A4CF for ; Thu, 9 Sep 2004 20:10:22 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46EB743D3F for ; Thu, 9 Sep 2004 20:10:22 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from pythonemproject.com (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (sccrmhc12) with ESMTP id <2004090920102101200ik9ple> (Authid: europax); Thu, 9 Sep 2004 20:10:21 +0000 Message-ID: <4140B8EC.1090701@pythonemproject.com> Date: Thu, 09 Sep 2004 13:11:24 -0700 From: Rob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ceri Davies , freebsd-current@freebsd.org References: <4140AFB0.6020002@pythonemproject.com> <20040909195228.GM44674@submonkey.net> In-Reply-To: <20040909195228.GM44674@submonkey.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Still getting warning messages for rc.conf & default/rc.conf entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rob@pythonemproject.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 20:10:22 -0000 Ceri Davies wrote: >On Thu, Sep 09, 2004 at 12:32:00PM -0700, Rob wrote: > > >>I have yet to find the source of this problem. Basically from the end >>of the boot sequence until I log in, I get a warning message for every >>rc.conf and defaults/config entry saying each are misconfigued. After I >>log in, the computer works fine. This 5.3beta2 on a Dell 8600 laptop >>1.7Ghz and 1G of memory. As I understand it rc controls the .config >>process.. Maybe it needs to recompiled. I haven't tried that as this >>was a binary install from an iso.. Will cvsup. >> >> > >May I suggest posting the messages that you get, along with a copy of >your /etc/rc.conf file? > >Ceri > > I will try as they show up in //var//log/messages. Will take a few minutes and will be a vey large email.. Rob From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:27: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 65C6B16A4CE for ; Thu, 9 Sep 2004 20:27:38 +0000 (GMT) Received: from flb.schmalzbauer.de (flb.schmalzbauer.de [62.245.232.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 195AA43D39 for ; Thu, 9 Sep 2004 20:27:37 +0000 (GMT) (envelope-from harry@schmalzbauer.de) Received: from korso.flintsbach.schmalzbauer.de (korso.flintsbach.schmalzbauer.de [172.21.2.3])i89KRXZm023739; Thu, 9 Sep 2004 22:27:33 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from cale.flintsbach.schmalzbauer.de (cale.flintsbach.schmalzbauer.de [172.21.1.253]) by korso.flintsbach.schmalzbauer.de (Postfix) with ESMTP id 0D309D5; Thu, 9 Sep 2004 22:27:33 +0200 (CEST) Received: from cale.flintsbach.schmalzbauer.de (localhost [127.0.0.1]) i89KRWOk001811; Thu, 9 Sep 2004 22:27:32 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from localhost (localhost [[UNIX: localhost]]) i89KRW47001810; Thu, 9 Sep 2004 22:27:32 +0200 (CEST) (envelope-from harry) From: Harald Schmalzbauer To: freebsd-current@freebsd.org Date: Thu, 9 Sep 2004 22:27:26 +0200 User-Agent: KMail/1.6.2 References: <20040831214945.47235.qmail@web50602.mail.yahoo.com> <20040908190119.V81868@carver.gumbysoft.com> In-Reply-To: <20040908190119.V81868@carver.gumbysoft.com> X-OS: FreeBSD 5.3 X-Country: Germany X-Address: Munich, 80686 X-Phone2: +49 (0) 89 18947781 X-Name: Harald Schmalzbauer X-Birthday: 06 Oktober 1972 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_0yLQBFc7FRaLN8r"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409092227.32060@harryhomeworkstation> X-Spam-Status: No, hits=0.2 required=3.5 tests=SUBJ_HAS_UNIQ_ID autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailjail.dmz.flintsbach.schmalzbauer.de cc: Kenneth Stailey Subject: Re: Problem with SiI3114 SATA RAID using 5.3-BETA1-20040823 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, 09 Sep 2004 20:27:38 -0000 --Boundary-02=_0yLQBFc7FRaLN8r Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag, 9. September 2004 04:03 schrieb Doug White: > On Tue, 31 Aug 2004, Kenneth Stailey wrote: > > I'm trying to upgrade a TYAN Tiger K8WS S2875S from FreeBSD-5.2.1-p8 to > > 5.3-BETA1-20040823. > > > > It fails because instead of seeing the SiI3114 as ar0 (RAID-1) it sees > > two separate disks: > > [...] > > Can you post the output of boot -v, or at least the part where its trying > to detect the metadata type? If you're interested in the result for the sil0649(0680) chipset you can fi= nd=20 them here (RELENG_5 from today compared to 5.2.1-RELEASE): http://www.schmalzbauer.de/statics/sil0680-v-boot-5.2.1-live.txt http://www.schmalzbauer.de/statics/sil0680-v-boot-5.3BETA3-09.09.04.txt Note the "ar: LSI check1 failed" line It's broken since June the 25th when rev. 1.27 for ata-raid.h was commited.= =20 Reverting to sources before that date at least atacontrol created arrays we= re=20 detected, even nor rebuild was possible, but that's another story. For now,= =20 upgrading to 5.3 is not possible if you have a system installed on ar0 with= =20 the sil chips. =2DHarry > > Just keeping this data along: > > atapci0: port > > 0x9400-0x940f,0x9480-0x9483,0x9800-0x9807,0x9880-0x9883,0x9c00-0x9c07 m= em > > 0xff4ffc00-0xff4fffff irq 19 at device 5.0 on pci1 > > ata2: channel #0 on atapci0 > > ata3: channel #1 on atapci0 > > ata4: channel #2 on atapci0 > > ata5: channel #3 on atapci0 > > acd0: CDRW at ata0-master UDMA33 > > ad4: 194481MB [395136/16/63] at ata2-master > > SATA150 ad6: 194481MB [395136/16/63] at > > ata3-master SATA150 > > -- > Doug White | FreeBSD: The Power to Serve > dwhite@gumbysoft.com | www.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" --Boundary-02=_0yLQBFc7FRaLN8r Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBQLy0Bylq0S4AzzwRAmqRAJ4sPDEt3VL3u2/U45avJnrHtWDX4wCePyiP C+nhBu1Ka3rLGI7tdn+so1g= =aPJC -----END PGP SIGNATURE----- --Boundary-02=_0yLQBFc7FRaLN8r-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:27: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 59C2F16A4CE for ; Thu, 9 Sep 2004 20:27:39 +0000 (GMT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED8BE43D49 for ; Thu, 9 Sep 2004 20:27:38 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from frederic (linux-win.com [62.212.121.38]) by kraid.nerim.net (Postfix) with SMTP id 5480F41916; Thu, 9 Sep 2004 22:27:36 +0200 (CEST) Message-ID: <006801c496ab$6d14cbf0$0401a8c0@frederic> From: "cell" To: "Barney Wolff" References: <001501c496a3$4db06ce0$0401a8c0@frederic> <20040909195824.GA17676@pit.databus.com> Date: Thu, 9 Sep 2004 22:27:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-current@freebsd.org Subject: Re: netgear wg311 v2 and project evil 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, 09 Sep 2004 20:27:39 -0000 My wep key is : 0A98E3552A47D0847E536B52ED When i do ifconfig ndis0 inet 192.168.1.x netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x0A98E3552A47D0847E536B52ED , freebsd says : ifconfig: odd count hexadecimal digits set wepkey failed:19 and when i do ifconfig ndis0 inet 192.168.1.x netmask 255.255.255.0 ssid my_net wepmode on wepkey 0A98E3552A47D0847E536B52ED , freebsd says : ifconfig: string too long set wepkey failed:19 ----- Original Message ----- From: "Barney Wolff" To: "cell" Cc: Sent: Thursday, September 09, 2004 9:58 PM Subject: Re: netgear wg311 v2 and project evil > On Thu, Sep 09, 2004 at 09:29:19PM +0200, cell wrote: > > hello , i have problem when i configure my wep key.I use the access point linksys wap54g and and i have decided a wep key in my access point but freebsd can't connect to the access point.I use passphrase for create my wep key but i don't know how to use passphrase with freebsd.Anyone have an idea ? > > The process of configuring the AP should have told you one or more WEP > keys in hex. That's what you use to configure your NIC. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:28: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 27C8516A4CE; Thu, 9 Sep 2004 20:28:08 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0086C43D48; Thu, 9 Sep 2004 20:28:08 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Thu, 09 Sep 2004 13:28:07 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1F5295D09; Thu, 9 Sep 2004 13:28:07 -0700 (PDT) To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-reply-to: Your message of "Thu, 09 Sep 2004 19:48:20 +0200." <41409764.4040708@DeepCore.dk> Date: Thu, 09 Sep 2004 13:28:07 -0700 From: "Kevin Oberman" Message-Id: <20040909202807.1F5295D09@ptavv.es.net> cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 20:28:08 -0000 > Date: Thu, 09 Sep 2004 19:48:20 +0200 > From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= > > Kevin Oberman wrote: > >>From: "Bjoern Koenig" > >>Date: Wed, 8 Sep 2004 12:29:03 +0200 > >>Sender: owner-freebsd-current@freebsd.org > >> > >>Hello, > >> > >>first time I installed a beta of FreeBSD 5.3 I noticed very poor disk > >>speed. > >>I built a kernel without this whole debugging stuff; but it remains bad I > >>supposed that this issue depends on further debugging features which I > >>didn't know. So I waited until UPDATING told that debugging options are > >>removed from kernel and userland. Now I built a new kernel again and the > >>disk speed is still unacceptable. Is there any further debugging option? > >> > >>Some facts: > >> > >>FreeBSD 5.3-BETA3 without any debugging: > >> per char write: 13.78 MB/s (32.7% CPU usage) > >> block write: 13.97 MB/s (12.8%) > >> per char read: 22.31 MB/s (45.2%) > >> block read: 37.44 MB/s (14.8%) > >> > >>FreeBSD 4.10-STABLE: > >> per char write: 37.29 MB/s (75.7%) > >> block write: 36.91 MB/s (28.7%) > >> per char read: 38.53 MB/s (80.4%) > >> block read: 37.45 MB/s (10.9%) > >> > >>(tested with bonnie, atacontrol shows UDMA100 both) > >> > >>Controller: Intel 82801BA (ICH2) > >>Hard disk: Seagate ST380021A > > > > > > I had previously reported this. I did some testing with the assistance > > of Robert Watson and it appears that the issue is ATA. The thread had a > > subject of "Disk performance under CURRENT" and was back in May. > > > > I plotted out the times for various sizes of I/O and > > the only real issue was with write. The per character speed should > > increase fairly quickly with increased I/O size and did for V4 and for > > reads. For writes, it started the same for short writes as these tend to > > be CPU bound. But, for longer writes, the increase in speed is MUCH less > > than it was with V4 write or for reads and throughput tops out at > > between 16 and 32KB transfers at something far below what I saw in V4. > > > > I was also hearing a LOT of disk seek operations that did not seem > > appropriate to me. (I did the testing with dd(1) in single-user mode.) > > > > FWIW, I did my tests on an IBM T30 which is a P4@1.8 GHz with ICH3 > > support chips. > > > > Looking back at the history in my e-mail archive, I'm not certain that > > sos@ was copied. Ouch! Mea culpa! > > I fixed a chip setup problem on the ICH* chips some days ago, its has > been committed to RELENG_5 as well. However it would normally b0 > harmless if the BIOS has set the mode (which it normally does). > > Besides that, I know of no problems performance wise. Disk seek > operations during sequential access suggests that there is something > else going on simultanious to the test as the driver doesn't issue seeks > without being asked to from the system. Søren, Here are the results of my last test back in May plus tests done on a kernel built from sources downloaded on Sep. 6. Is that going to catch your fix? I don't see much difference. Do you have version number I can check? Buffer V4 Read V4 Write V5 Read V5 Write 512 8385790 8111781 6921714 5115853 7130873 5261294 1k 15457027 14865113 12330562 7811422 12494677 7952281 2k 25677856 25273251 19939822 10572186 20137339 10708676 4k 27083255 25897711 27096896 12860586 27064850 12982472 8k 27079563 26033768 27097726 14416520 27017494 14497783 16k 27082575 Oops! 27082273 15316924 26936316 15374888 32k 27080720 25908336 27100118 15816203 26977041 15853140 64k 27079904 26008387 27096093 16073422 26939153 15938326 128k 27055901 25928520 27095673 16073422 256k 27076467 25918950 27090967 16118789 512k 27045087 25987266 27077925 16006708 1m 27026694 25738575 27060626 15879266 Read: dd if=/dev/ad2 of=/dev/null bs=nnn Write:dd if=/dev/zero of=/dev/ad2 bs=nnn All tests run for about 30 seconds. All tests in single-user mode. Nothing on ad2 is mounted. Debug (WITNESS, INVARIANTS, malloc checking) disabled. While the test is running, the disk being written to "sings" with the frequency somewhat dependent on the size of the write. On read, I get silence. When I copy my full disk (if=ad0 of=ad2), I can clearly hear the sound of the actuator moving the heads constantly toward the end of the backup. I assume that they are being returned to track 0 on a repeated basis. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:29: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 B51D816A4CE for ; Thu, 9 Sep 2004 20:29:57 +0000 (GMT) Received: from portalis.it (mail1.portalis.it [213.199.4.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4A1543D46 for ; Thu, 9 Sep 2004 20:29:55 +0000 (GMT) (envelope-from esaltato@tele2.it) Received: from [62.123.50.14] ([62.123.50.14]) by portalis.it with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 9 Sep 2004 22:50:34 +0200 Message-ID: <4140BD41.2080103@tele2.it> Date: Thu, 09 Sep 2004 22:29:53 +0200 From: Esaltato User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <41383F2B.5040201@tele2.it> In-Reply-To: <41383F2B.5040201@tele2.it> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: No keyboard with Gnome and X.org (and gnome loaded behind KDE) 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, 09 Sep 2004 20:29:57 -0000 Esaltato wrote: > I got a problem with GNOME since switching to xorg. On KDE everything > is fine, but on Gnome 2.6 (all my system has been portupgraded > yesterday) my keystrokes are blocked; as I type the text cursor stops > blinking and nothing gets written. If I press ctrl, shift and some > letters a lot of times it may happen that I can write sometimes, but > only as long as I hold shift down and I don't change the writing > focus. It seems like if my keys command are getting intercepted. This > only happens as root. > I want to point out that I've been throughly searching for solutions, > and that not a solution proposed on the net has solved this. > It may be related to the problem of this message popping up on Gnome > (which I don't have, let's clarify it now, more on this later): > > :::::::start message > Error activating XKB configuration. > Probably internal X server problem. > > X server version data: > The X.Org Foundation > 60700000 > > If you report this situation as a bug, please include: > - The result of xprop -root | grep XKB > - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb > :::::::end message > > These are the results: > > localhost# xprop -root | grep XKB > _XKB_RULES_NAMES(STRING) = "xorg", "logiik", "it", "basic", "" > localhost# gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb > layouts = [it] > model = logiik > overrideSettings = false > options = [] > > No help in changing the keyboard values... > > People report that this error message usually comes on start after the > xorg update, but I _did not_ have this problem. I only get that pop up > message (twice) if I go to the gnome keyboard panel and remove my > italian keymap (I tried switching to no keymap and US). > I followed the UPDATING hints related to gnome and xorg, so I rebuilt > the 2 needed libraries x11-toolkits/libwnck and x11/libxklavier. > I _haven't_ got the line > > Option "XkbRules" "xfree86" > > in my xorg file, which I let xorg itself build, and then I modified > accordingly to my needs. I tried everything, and everything seems OK: > Section "InputDevice" > > Identifier "Keyboard1" > Driver "Keyboard" > > Option "AutoRepeat" "500 30" > > Option "XkbRules" "xorg" > Option "XkbModel" "logiik" > Option "XkbLayout" "it" > > EndSection > (.....) > InputDevice "Keyboard1" "CoreKeyboard" > > Oh, and I upgraded like the HEADSUP said. I use kdm now, but I used > xdm when the problem surfaced. > > Any idea? I seem the only one with this problem. As for now, I'm > sticking with KDE, but I need/want GNOME. I hope this is gonna be useful to others. The problem was the %gconf.xml placed in /root/.gconf/apps/Esaltato/gnome_settings_daemon/keybindings. Once deleted (I deleted the whole gnome_settins_daemon dir) the problem was solved. This file has inside the global shortcuts I had set for my logitech keyboard. Somehow, after the big X.org update it wasn't welcome. Bye, Esaltato From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:38: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 B804C16A4CE; Thu, 9 Sep 2004 20:38: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 D501D43D5E; Thu, 9 Sep 2004 20:38: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 i89KcCTb040919; Thu, 9 Sep 2004 22:38:12 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4140BF0B.6090308@DeepCore.dk> Date: Thu, 09 Sep 2004 22:37:31 +0200 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: Kevin Oberman References: <20040909202807.1F5295D09@ptavv.es.net> In-Reply-To: <20040909202807.1F5295D09@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 20:38:20 -0000 Kevin Oberman wrote: > Here are the results of my last test back in May plus tests done on a > kernel built from sources downloaded on Sep. 6. Is that going to catch > your fix? I don't see much difference. Do you have version number I can= > check? Sep 6 should be fine if we are talking -current, on RELENG_5 it=20 "depends" since the MFC was done on the 6'th.. >=20 > Buffer V4 Read V4 Write V5 Read V5 Write =20 > 512 8385790 8111781 6921714 5115853 7130873 5261294 > 1k 15457027 14865113 12330562 7811422 12494677 7952281 > 2k 25677856 25273251 19939822 10572186 20137339 10708676 > 4k 27083255 25897711 27096896 12860586 27064850 12982472 > 8k 27079563 26033768 27097726 14416520 27017494 14497783 > 16k 27082575 Oops! 27082273 15316924 26936316 15374888 > 32k 27080720 25908336 27100118 15816203 26977041 15853140 > 64k 27079904 26008387 27096093 16073422 26939153 15938326 > 128k 27055901 25928520 27095673 16073422 > 256k 27076467 25918950 27090967 16118789 > 512k 27045087 25987266 27077925 16006708 > 1m 27026694 25738575 27060626 15879266 >=20 > Read: dd if=3D/dev/ad2 of=3D/dev/null bs=3Dnnn > Write:dd if=3D/dev/zero of=3D/dev/ad2 bs=3Dnnn > All tests run for about 30 seconds. > All tests in single-user mode. Nothing on ad2 is mounted. > Debug (WITNESS, INVARIANTS, malloc checking) disabled. > While the test is running, the disk being written to "sings" with the > frequency somewhat dependent on the size of the write. On read, I get > silence. When I copy my full disk (if=3Dad0 of=3Dad2), I can clearly he= ar > the sound of the actuator moving the heads constantly toward the end of= > the backup. I assume that they are being returned to track 0 on a > repeated basis. There should be no seeks on a lone write to the raw disk, if there is=20 you have HW problems as the driver doesn't issue any seeks at all then. What disks are this BTW ? -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:46: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 4F43E16A4CE for ; Thu, 9 Sep 2004 20:46:16 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32EF443D53 for ; Thu, 9 Sep 2004 20:46:16 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Thu, 09 Sep 2004 13:46:15 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 724045D04; Thu, 9 Sep 2004 13:46:15 -0700 (PDT) To: Patrick Guelat In-reply-to: Your message of "Wed, 08 Sep 2004 21:22:26 -0000." <20040908212140.O79062@murphy.imp.ch> Date: Thu, 09 Sep 2004 13:46:15 -0700 From: "Kevin Oberman" Message-Id: <20040909204615.724045D04@ptavv.es.net> cc: freebsd-current@freebsd.org cc: "Alexandre \"Sunny\" Kovalenko" Subject: Re: BETA3 showstoppers (read: critical bugs) 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, 09 Sep 2004 20:46:16 -0000 > Date: Wed, 8 Sep 2004 21:22:26 +0000 (UTC) > From: Patrick Guelat > Sender: owner-freebsd-current@freebsd.org > > On Tue, 7 Sep 2004, Alexandre "Sunny" Kovalenko wrote: > > > FWIW: I have autonegotiation problems between Cisco switches and way too > > many pieces of equipment to list here (including, but not limited to: > > several models of IBM RS/6000, couple of Sun boxes, fxp & bge under > > Windows/Linux/FreeBSD, etc.). Forcing speed to 100-FDX solves the > > problem for good. > > Ever thought about about upgrading those cisco switches ? There were > a lot of bugs readrding autonegotation in early catalyst ios releases. > Most of them are fixed since years. Auto-negotiation is and will probably remain a major pain. I work in network operations at a large, high-end computer show every year. We typically have over 100 network drops, most at 1 Gb/s or higher and multiple OC-192s (10 Bb/s SONET) to the outside world. Every year when the drops are connected, a number don't work. The problems are ALMOST always auto-negotiation. This is new, state-of-the-art equipment from major vendors of both switches and routers. The problem does not seem to be getting worse, but it is not really improving, either. The problems are NOT close to the majority, but they are far from rare. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:53: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 09D1816A4CE for ; Thu, 9 Sep 2004 20:53:51 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B110843D31 for ; Thu, 9 Sep 2004 20:53:50 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from [192.168.1.101] (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (rwcrmhc13) with ESMTP id <2004090920534901500oh02ie> (Authid: europax); Thu, 9 Sep 2004 20:53:49 +0000 Message-ID: <4140C31C.8020801@pythonemproject.com> Date: Thu, 09 Sep 2004 13:54:52 -0700 From: Rob User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current Content-Type: multipart/mixed; boundary="------------010508040100050605030000" Subject: warning messages from root mount until login, also my rc.conf file 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, 09 Sep 2004 20:53:51 -0000 This is a multi-part message in MIME format. --------------010508040100050605030000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry about attaching files but can't seem to put them inline with mozilla. Perhaps Sylpheed would work better. I can actually get even more warning messages if I delay logging in. For example, sendmail claims it can't find a socket and comes back with a multitude of warnings. In this particular case, just wanted to show a few examples. Rob --------------010508040100050605030000 Content-Type: text/plain; name="rc.conf1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.conf1" #!/bin/sh # # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. You should # not edit this file! Put any overrides into one of the ${rc_conf_files} # instead and you will be able to update these defaults later without # spamming your local configuration information. # # The ${rc_conf_files} files should only contain values which override # values set in this file. This eases the upgrade path when defaults # are changed and new features are added. # # All arguments must be in double or single quotes. # # $FreeBSD: src/etc/defaults/rc.conf,v 1.212 2004/07/27 00:28:16 mlaier Exp $ ############################################################## ### Important initial Boot-time options #################### ############################################################## apm_enable="YES" # Set to YES to enable APM BIOS functions (or NO). apmd_enable="YES" # Run apmd to handle APM event from userland. apmd_flags="" # Flags to apmd (if enabled). pccard_enable="NO" # Set to YES if you want to configure PCCARD devices. pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address. pccard_beep="2" # pccard beep type. pccard_ifconfig="NO" # Specialized pccard ethernet configuration (or NO). pccardd_flags="-z" # Additional flags for pccardd. pccard_conf="/etc/defaults/pccard.conf" # pccardd(8) config file pccard_ether_delay="5" # Delay before trying to start dhclient in pccard_ether removable_interfaces="" # Removable network interfaces for /etc/pccard_ether. tmpmfs="AUTO" # Set to YES to always create an mfs /tmp, NO to never tmpsize="20m" # Size of mfs /tmp if created varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never varsize="32m" # Size of mfs /var if created populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # startup script dirs. rc_conf_files="/etc/rc.conf /etc/rc.conf.local" background_fsck="YES" # Attempt to run fsck in the background where possible. background_fsck_delay="60" # Time to wait (seconds) before starting the fsck. # mount at startup (or NO). ############################################################## ### Network configuration sub-section ###################### ############################################################## ### Basic network and firewall/security options: ### firewall_enable="NO" # Set to YES to enable firewall functionality firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall) firewall_quiet="NO" # Set to YES to suppress rule display firewall_logging="NO" # Set to YES to enable events logging firewall_flags="" # Flags passed to ipfw when type is a file ip_portrange_first="NO" # Set first dynamically allocated port ip_portrange_last="NO" # Set last dynamically allocated port ipfilter_enable="YES" # Set to YES to enable ipfilter functionality ipfilter_program="/sbin/ipf" # where the ipfilter program lives ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see # /usr/src/contrib/ipfilter/rules for examples ipfilter_flags="" # additional flags for ipfilter ipmon_enable="YES" # Set to YES for ipmon; needs ipfilter or ipnat ipmon_program="/sbin/ipmon" # where the ipfilter monitor program lives ipmon_flags="-Ds" # typically "-Ds" or "-D /var/log/ipflog" tcp_keepalive="YES" # Enable stale TCP connection timeout (or NO). # For the following option you need to have TCP_DROP_SYNFIN set in your # kernel. Please refer to LINT and NOTES for details. tcp_drop_synfin="YES" # Set to YES to drop TCP packets with SYN+FIN # NOTE: this violates the TCP specification icmp_drop_redirect="YES" # Set to YES to ignore ICMP REDIRECT packet icmp_log_redirect="YES" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a different one. syslogd_flags="-s" # Flags to syslogd (if enabled). #syslogd_flags="-ss" # Syslogd flags to not bind an inet socket inetd_enable="YES" # Run the network daemon dispatcher (YES/NO). inetd_program="/usr/sbin/inetd" # path to inetd, if you want a different one. inetd_flags="-wW -C 60" # Optional flags to inetd # sshd_enable="YES" # Enable sshd sshd_program="/usr/sbin/sshd" # path to sshd, if you want a different one. sshd_flags="" # Additional flags for sshd. ############################################################## ### System console options ################################# ############################################################## moused_enable="YES" # Run the mouse daemon. moused_type="auto" # See man page for rc.conf(5) for available settings. moused_port="/dev/psm0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. mousechar_start="NO" # if 0xd0-0xd3 default range is occupied in your # language code table, specify alternative range # start like mousechar_start=3, see vidcontrol(1) ############################################################## ### Mail Transfer Agent (MTA) options ###################### ############################################################## mta_start_script="/etc/rc.sendmail" # Script to start your chosen MTA, called by /etc/rc. # Settings for /etc/rc.sendmail and /etc/rc.d/sendmail: sendmail_enable="NO" # Run the sendmail inbound daemon (YES/NO). sendmail_pidfile="/var/run/sendmail.pid" # sendmail pid file sendmail_procname="/usr/sbin/sendmail" # sendmail process name sendmail_flags="-L sm-mta -bd -q30m" # Flags to sendmail (as a server) sendmail_submit_enable="YES" # Start a localhost-only MTA for mail submission sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost" # Flags for localhost-only MTA sendmail_outbound_enable="YES" # Dequeue stuck mail (YES/NO). sendmail_outbound_flags="-L sm-queue -q30m" # Flags to sendmail (outbound only) sendmail_msp_queue_enable="YES" # Dequeue stuck clientmqueue mail (YES/NO). sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m" # Flags for sendmail_msp_queue daemon. ############################################################## ### Miscellaneous administrative options ################### ############################################################## cron_enable="YES" # Run the periodic job daemon. cron_program="/usr/sbin/cron" # Which cron executable to run (if enabled). cron_dst="YES" # Handle DST transitions intelligently (YES/NO) cron_flags="" # Which options to pass to the cron daemon. lpd_enable="YES" # Run the line printer daemon. lpd_program="/usr/sbin/lpd" # path to lpd, if you want a different one. lpd_flags="" # Flags to lpd (if enabled). usbd_enable="YES" # Run the usbd daemon. usbd_flags="" # Flags to usbd (if enabled). linux_enable="YES" # Linux binary compatibility loaded at startup (or NO). ldconfig_insecure="YES" # Set to YES to disable ldconfig security checks ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib" # shared library search paths ldconfig_paths_aout="/usr/lib/compat/aout /usr/X11R6/lib/aout /usr/local/lib/aout" # a.out shared library search paths kern_securelevel_enable="NO" # kernel security level (see init(8)), kern_securelevel="-1" # range: -1..3 ; `-1' is the most insecure dmesg_enable="YES" # Save dmesg(8) to /var/run/dmesg.boot performance_throttle_state="HIGH" # Online throttling state # Enable network daemons for user convenience. # Created: Tue Sep 7 03:09:30 2004 # -- sysinstall generated deltas -- # Tue Sep 7 03:09:30 2004 ifconfig_bfe0="inet 192.168.1.101 netmask 255.255.255.0" defaultrouter="192.168.1.1" hostname="lm741n.comcast.net" # This file now contains just the overrides from /etc/defaults/rc.conf. # Please make all changes to this file, not to /etc/defaults/rc.conf. --------------010508040100050605030000 Content-Type: text/plain; name="messages1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages1" Sep 7 20:07:41 lm741n kernel: Mounting root from ufs:/dev/ad0s3a Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $named_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $enable_quotas is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pflog_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pf_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $virecover_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $timed_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) Sep 7 20:07:42 lm741n apmd[385]: start Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $bootparamd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n lpd[397]: lpd startup: logging=0 Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $update_motd is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $ntpd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $rarpd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $rtadvd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $rwhod_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $ibcs2_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $sysvipc_enable is not set properly - see rc.conf(5). Sep 7 20:07:44 lm741n root: /etc/rc: WARNING: $svr4_enable is not set properly - see rc.conf(5). Sep 7 20:07:44 lm741n root: /etc/rc: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 20:07:44 lm741n root: /etc/rc: WARNING: $ntpdate_enable is not set properly - see rc.conf(5). Sep 7 20:19:05 lm741n kernel: ugen1: NEC NEC USB UF000x, rev 1.10/1.50, addr 2 Sep 7 20:20:27 lm741n kernel: ugen1: at uhub0 port 1 (addr 2) disconnected Sep 7 20:20:27 lm741n kernel: ugen1: detached Sep 7 21:51:38 lm741n login: ROOT LOGIN (root) ON ttyv1 Sep 7 21:56:09 lm741n su: rob to root on /dev/ttyv0 Sep 7 22:00:56 lm741n shutdown: shutdown by rob: Sep 7 22:00:59 lm741n root: /etc/rc.shutdown: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 22:00:59 lm741n root: /etc/rc.shutdown: WARNING: $ipfs_enable is not set properly - see rc.conf(5). Sep 7 22:00:59 lm741n syslogd: exiting on signal 15 Sep 7 22:01:10 lm741n syslogd: kernel boot file is /boot/kernel/kernel Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $named_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $enable_quotas is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $pflog_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $pf_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $virecover_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $timed_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) Sep 7 22:01:11 lm741n apmd[1212]: start Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $bootparamd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n lpd[1224]: lpd startup: logging=0 Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $update_motd is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $ntpd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $rarpd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $rtadvd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $rwhod_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $ibcs2_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $sysvipc_enable is not set properly - see rc.conf(5). Sep 7 22:01:13 lm741n root: /etc/rc: WARNING: $svr4_enable is not set properly - see rc.conf(5). Sep 7 22:01:13 lm741n root: /etc/rc: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 22:01:13 lm741n root: /etc/rc: WARNING: $ntpdate_enable is not set properly - see rc.conf(5). Sep 7 22:03:04 lm741n su: rob to root on /dev/ttyv0 Sep 7 23:21:48 lm741n shutdown: power-down by rob: Sep 7 23:21:50 lm741n root: /etc/rc.shutdown: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 23:21:50 lm741n root: /etc/rc.shutdown: WARNING: $ipfs_enable is not set properly - see rc.conf(5). Sep 7 23:21:50 lm741n syslogd: exiting on signal 15 Sep 9 13:14:01 lm741n syslogd: kernel boot file is /boot/kernel/kernel Sep 9 13:14:01 lm741n kernel: Copyright (c) 1992-2004 The FreeBSD Project. Sep 9 13:14:01 lm741n kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Sep 9 13:14:01 lm741n kernel: The Regents of the University of California. All rights reserved. Sep 9 13:14:01 lm741n kernel: FreeBSD 5.3-BETA2 #0: Mon Sep 6 22:22:52 PDT 2004 Sep 9 13:14:01 lm741n kernel: root@:/usr/src/sys/i386/compile/ROBKERN Sep 9 13:14:01 lm741n kernel: WARNING: WITNESS option enabled, expect reduced performance. Sep 9 13:14:01 lm741n kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Sep 9 13:14:01 lm741n kernel: CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.57-MHz 686-class CPU) Sep 9 13:14:01 lm741n kernel: Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Sep 9 13:14:01 lm741n kernel: Features=0xa7e9f9bf Sep 9 13:14:01 lm741n kernel: real memory = 1073405952 (1023 MB) Sep 9 13:14:01 lm741n kernel: avail memory = 1040867328 (992 MB) Sep 9 13:14:01 lm741n kernel: npx0: [FAST] Sep 9 13:14:01 lm741n kernel: npx0: on motherboard Sep 9 13:14:01 lm741n kernel: npx0: INT 16 interface Sep 9 13:14:01 lm741n kernel: pcib0: pcibus 0 on motherboard Sep 9 13:14:01 lm741n kernel: pir0: on motherboard Sep 9 13:14:01 lm741n kernel: $PIR: BIOS IRQ 11 for 0.29.INTB is not valid for link 0x63 Sep 9 13:14:01 lm741n kernel: $PIR: BIOS IRQ 11 for 2.1.INTA is not valid for link 0x63 Sep 9 13:14:01 lm741n kernel: pci0: on pcib0 Sep 9 13:14:01 lm741n kernel: agp0: mem 0xe0000000-0xe7ffffff at device 0.0 on pci0 Sep 9 13:14:01 lm741n kernel: pcib1: at device 1.0 on pci0 Sep 9 13:14:01 lm741n kernel: pci1: on pcib1 Sep 9 13:14:01 lm741n kernel: pci1: at device 0.0 (no driver attached) Sep 9 13:14:01 lm741n kernel: uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 Sep 9 13:14:01 lm741n kernel: uhci0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb0: on uhci0 Sep 9 13:14:01 lm741n kernel: usb0: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub0: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: uhci1: port 0xbf40-0xbf5f irq 11 at device 29.1 on pci0 Sep 9 13:14:01 lm741n kernel: uhci1: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb1: on uhci1 Sep 9 13:14:01 lm741n kernel: usb1: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub1: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: uhci2: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 Sep 9 13:14:01 lm741n kernel: uhci2: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb2: on uhci2 Sep 9 13:14:01 lm741n kernel: usb2: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub2: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: pci0: at device 29.7 (no driver attached) Sep 9 13:14:01 lm741n kernel: pcib2: at device 30.0 on pci0 Sep 9 13:14:01 lm741n kernel: pci2: on pcib2 Sep 9 13:14:01 lm741n kernel: bfe0: mem 0xfaffe000-0xfaffffff irq 11 at device 0.0 on pci2 Sep 9 13:14:01 lm741n kernel: miibus0: on bfe0 Sep 9 13:14:01 lm741n kernel: bmtphy0: on miibus0 Sep 9 13:14:01 lm741n kernel: bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Sep 9 13:14:01 lm741n kernel: bfe0: Ethernet address: 00:0d:56:38:b8:a0 Sep 9 13:14:01 lm741n kernel: bfe0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: cbb0: irq 11 at device 1.0 on pci2 Sep 9 13:14:01 lm741n kernel: cardbus0: on cbb0 Sep 9 13:14:01 lm741n kernel: pccard0: <16-bit PCCard bus> on cbb0 Sep 9 13:14:01 lm741n kernel: fwohci0: <1394 Open Host Controller Interface> mem 0xfaff8000-0xfaffbfff,0xfaffd800-0xfaffdfff irq 11 at device 1.1 on pci2 Sep 9 13:14:01 lm741n kernel: fwohci0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: fwohci0: OHCI version 1.10 (ROM=0) Sep 9 13:14:01 lm741n kernel: fwohci0: No. of Isochronous channels is 4. Sep 9 13:14:01 lm741n kernel: fwohci0: EUI64 5b:4f:c0:00:3f:ff:ff:ff Sep 9 13:14:01 lm741n kernel: fwohci0: Phy 1394a available S400, 2 ports. Sep 9 13:14:01 lm741n kernel: fwohci0: Link S400, max_rec 2048 bytes. Sep 9 13:14:01 lm741n kernel: firewire0: on fwohci0 Sep 9 13:14:01 lm741n kernel: sbp0: on firewire0 Sep 9 13:14:01 lm741n kernel: fwe0: on firewire0 Sep 9 13:14:01 lm741n kernel: if_fwe0: Fake Ethernet address: 5a:4f:c0:ff:ff:ff Sep 9 13:14:01 lm741n kernel: fwe0: Ethernet address: 5a:4f:c0:ff:ff:ff Sep 9 13:14:01 lm741n kernel: fwohci0: Initiate bus reset Sep 9 13:14:01 lm741n kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Sep 9 13:14:01 lm741n kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Sep 9 13:14:01 lm741n kernel: firewire0: bus manager 0 (me) Sep 9 13:14:01 lm741n kernel: pci2: at device 3.0 (no driver attached) Sep 9 13:14:01 lm741n kernel: isab0: at device 31.0 on pci0 Sep 9 13:14:01 lm741n kernel: isa0: on isab0 Sep 9 13:14:01 lm741n kernel: atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 Sep 9 13:14:01 lm741n kernel: ata0: channel #0 on atapci0 Sep 9 13:14:01 lm741n kernel: ata1: channel #1 on atapci0 Sep 9 13:14:01 lm741n kernel: pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff400-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 11 at device 31.5 on pci0 Sep 9 13:14:01 lm741n kernel: pcm0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: pcm0: Sep 9 13:14:01 lm741n kernel: pci0: at device 31.6 (no driver attached) Sep 9 13:14:01 lm741n kernel: cpu0 on motherboard Sep 9 13:14:01 lm741n kernel: orm0: at iomem 0xcf800-0xcffff,0xc0000-0xcf7ff on isa0 Sep 9 13:14:01 lm741n kernel: pmtimer0 on isa0 Sep 9 13:14:01 lm741n kernel: atkbdc0: at port 0x64,0x60 on isa0 Sep 9 13:14:01 lm741n kernel: atkbd0: irq 1 on atkbdc0 Sep 9 13:14:01 lm741n kernel: kbd0 at atkbd0 Sep 9 13:14:01 lm741n kernel: atkbd0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: psm0: irq 12 on atkbdc0 Sep 9 13:14:01 lm741n kernel: psm0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: psm0: model GlidePoint, device ID 0 Sep 9 13:14:01 lm741n kernel: fdc0: ready for input in output Sep 9 13:14:01 lm741n kernel: fdc0: cmd 3 failed at out byte 1 of 3 Sep 9 13:14:01 lm741n kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Sep 9 13:14:01 lm741n kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Sep 9 13:14:01 lm741n kernel: ppc0: FIFO with 16/16/8 bytes threshold Sep 9 13:14:01 lm741n kernel: ppbus0: on ppc0 Sep 9 13:14:01 lm741n kernel: plip0: on ppbus0 Sep 9 13:14:01 lm741n kernel: lpt0: on ppbus0 Sep 9 13:14:01 lm741n kernel: lpt0: Interrupt-driven port Sep 9 13:14:01 lm741n kernel: ppi0: on ppbus0 Sep 9 13:14:01 lm741n kernel: sc0: at flags 0x100 on isa0 Sep 9 13:14:01 lm741n kernel: sc0: VGA <16 virtual consoles, flags=0x300> Sep 9 13:14:01 lm741n kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Sep 9 13:14:01 lm741n kernel: sio0: type 16550A Sep 9 13:14:01 lm741n kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Sep 9 13:14:01 lm741n kernel: sio1: port may not be enabled Sep 9 13:14:01 lm741n kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (port) Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (irq) Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (port) Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (port) Sep 9 13:14:01 lm741n kernel: Timecounter "TSC" frequency 1698567438 Hz quality 800 Sep 9 13:14:01 lm741n kernel: Timecounters tick every 10.000 msec Sep 9 13:14:01 lm741n kernel: IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled Sep 9 13:14:01 lm741n kernel: cardbus0: Resource not specified in CIS: id=10, size=1000 Sep 9 13:14:01 lm741n kernel: ohci0: mem 0xf6001000-0xf6001fff irq 11 at device 0.0 on cardbus0 Sep 9 13:14:01 lm741n kernel: ohci0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb3: OHCI version 1.0 Sep 9 13:14:01 lm741n kernel: ad0: 57231MB [116280/16/63] at ata0-master PIO4 Sep 9 13:14:01 lm741n kernel: ATAPI_RESET time = 30us Sep 9 13:14:01 lm741n kernel: acd0: CDRW <_NEC DVD+RW ND-5100A/10AC> at ata1-master PIO4 Sep 9 13:14:01 lm741n kernel: usb3: on ohci0 Sep 9 13:14:01 lm741n kernel: usb3: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub3: 3 ports with 3 removable, self powered Sep 9 13:14:01 lm741n kernel: cardbus0: Resource not specified in CIS: id=10, size=1000 Sep 9 13:14:01 lm741n kernel: ohci1: mem 0xf6002000-0xf6002fff irq 11 at device 0.1 on cardbus0 Sep 9 13:14:01 lm741n kernel: ohci1: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb4: OHCI version 1.0 Sep 9 13:14:01 lm741n kernel: usb4: on ohci1 Sep 9 13:14:01 lm741n kernel: usb4: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub4: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub4: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: cardbus0: Resource not specified in CIS: id=10, size=100 Sep 9 13:14:01 lm741n kernel: cardbus0: at device 0.2 (no driver attached) Sep 9 13:14:01 lm741n kernel: ugen0: Orange Micro iBOT2 Camera, rev 2.00/1.00, addr 2 Sep 9 13:14:01 lm741n kernel: Mounting root from ufs:/dev/ad0s3a Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $named_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $enable_quotas is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $pflog_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $pf_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $virecover_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $timed_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) Sep 9 13:14:02 lm741n apmd[385]: start Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $bootparamd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n lpd[397]: lpd startup: logging=0 Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $update_motd is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $ntpd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $rarpd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $rtadvd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $rwhod_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $ibcs2_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $sysvipc_enable is not set properly - see rc.conf(5). Sep 9 13:14:04 lm741n root: /etc/rc: WARNING: $svr4_enable is not set properly - see rc.conf(5). Sep 9 13:14:04 lm741n root: /etc/rc: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 9 13:14:04 lm741n root: /etc/rc: WARNING: $ntpdate_enable is not set properly - see rc.conf(5). Sep 9 13:14:34 lm741n login: ROOT LOGIN (root) ON ttyv0 --------------010508040100050605030000-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:01: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 153A716A4CE for ; Thu, 9 Sep 2004 21:01:54 +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 605C143D46 for ; Thu, 9 Sep 2004 21:01:53 +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 i89L1qBT041173; Thu, 9 Sep 2004 23:01:52 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4140C496.30803@DeepCore.dk> Date: Thu, 09 Sep 2004 23:01:10 +0200 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: Harald Schmalzbauer References: <20040831214945.47235.qmail@web50602.mail.yahoo.com> <20040908190119.V81868@carver.gumbysoft.com> <200409092227.32060@harryhomeworkstation> In-Reply-To: <200409092227.32060@harryhomeworkstation> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: Kenneth Stailey cc: freebsd-current@freebsd.org Subject: Re: Problem with SiI3114 SATA RAID using 5.3-BETA1-20040823 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, 09 Sep 2004 21:01:54 -0000 Harald Schmalzbauer wrote: > Am Donnerstag, 9. September 2004 04:03 schrieb Doug White: >=20 >>On Tue, 31 Aug 2004, Kenneth Stailey wrote: >> >>>I'm trying to upgrade a TYAN Tiger K8WS S2875S from FreeBSD-5.2.1-p8 t= o >>>5.3-BETA1-20040823. >>> >>>It fails because instead of seeing the SiI3114 as ar0 (RAID-1) it sees= >>>two separate disks: >> >>[...] >> >>Can you post the output of boot -v, or at least the part where its tryi= ng >>to detect the metadata type? >=20 >=20 > If you're interested in the result for the sil0649(0680) chipset you ca= n find=20 > them here (RELENG_5 from today compared to 5.2.1-RELEASE): >=20 > http://www.schmalzbauer.de/statics/sil0680-v-boot-5.2.1-live.txt > http://www.schmalzbauer.de/statics/sil0680-v-boot-5.3BETA3-09.09.04.txt= >=20 >=20 > Note the "ar: LSI check1 failed" line > It's broken since June the 25th when rev. 1.27 for ata-raid.h was commi= ted.=20 > Reverting to sources before that date at least atacontrol created array= s were=20 > detected, even nor rebuild was possible, but that's another story. For = now,=20 > upgrading to 5.3 is not possible if you have a system installed on ar0 = with=20 > the sil chips. Depends on what BIOS and metadata you have on there, simple as that. Now, maybe we should make ata-raid go through all the types it knows on=20 all controllers, but that could really mess up things when disks are=20 moved around between controllers. I'll think about a workable solution but its fairly long down the TODO=20 list.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:03: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 2F12216A4CE for ; Thu, 9 Sep 2004 21:03:34 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB71643D2D for ; Thu, 9 Sep 2004 21:03:33 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from [192.168.1.101] (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (sccrmhc13) with ESMTP id <2004090921033201600hi5qle> (Authid: europax); Thu, 9 Sep 2004 21:03:33 +0000 Message-ID: <4140C563.8060605@pythonemproject.com> Date: Thu, 09 Sep 2004 14:04:35 -0700 From: Rob User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current References: <4140C31C.8020801@pythonemproject.com> In-Reply-To: <4140C31C.8020801@pythonemproject.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: warning messages from root mount until login, also my rc.conf file 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, 09 Sep 2004 21:03:34 -0000 Actually the messages file has 2 or more boots listed in it. Missed that in the midst of all the warnings. Rob From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:05: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 DCA8B16A4CF; Thu, 9 Sep 2004 21:05:41 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B853743D1F; Thu, 9 Sep 2004 21:05:41 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 09 Sep 2004 14:05:41 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 16C925D09; Thu, 9 Sep 2004 14:05:41 -0700 (PDT) To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-reply-to: Your message of "Thu, 09 Sep 2004 22:37:31 +0200." <4140BF0B.6090308@DeepCore.dk> Date: Thu, 09 Sep 2004 14:05:41 -0700 From: "Kevin Oberman" Message-Id: <20040909210541.16C925D09@ptavv.es.net> cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 21:05:42 -0000 > Date: Thu, 09 Sep 2004 22:37:31 +0200 > From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= > > Kevin Oberman wrote: > > > Here are the results of my last test back in May plus tests done on a > > kernel built from sources downloaded on Sep. 6. Is that going to catch > > your fix? I don't see much difference. Do you have version number I can= > > > check? > > Sep 6 should be fine if we are talking -current, on RELENG_5 it=20 > "depends" since the MFC was done on the 6'th.. > >=20 > > Buffer V4 Read V4 Write V5 Read V5 Write =20 > > 512 8385790 8111781 6921714 5115853 7130873 5261294 > > 1k 15457027 14865113 12330562 7811422 12494677 7952281 > > 2k 25677856 25273251 19939822 10572186 20137339 10708676 > > 4k 27083255 25897711 27096896 12860586 27064850 12982472 > > 8k 27079563 26033768 27097726 14416520 27017494 14497783 > > 16k 27082575 Oops! 27082273 15316924 26936316 15374888 > > 32k 27080720 25908336 27100118 15816203 26977041 15853140 > > 64k 27079904 26008387 27096093 16073422 26939153 15938326 > > 128k 27055901 25928520 27095673 16073422 > > 256k 27076467 25918950 27090967 16118789 > > 512k 27045087 25987266 27077925 16006708 > > 1m 27026694 25738575 27060626 15879266 > >=20 > > Read: dd if=3D/dev/ad2 of=3D/dev/null bs=3Dnnn > > Write:dd if=3D/dev/zero of=3D/dev/ad2 bs=3Dnnn > > All tests run for about 30 seconds. > > All tests in single-user mode. Nothing on ad2 is mounted. > > Debug (WITNESS, INVARIANTS, malloc checking) disabled. > > > While the test is running, the disk being written to "sings" with the > > frequency somewhat dependent on the size of the write. On read, I get > > silence. When I copy my full disk (if=3Dad0 of=3Dad2), I can clearly he= > ar > > the sound of the actuator moving the heads constantly toward the end of= > > > the backup. I assume that they are being returned to track 0 on a > > repeated basis. > > There should be no seeks on a lone write to the raw disk, if there is=20 > you have HW problems as the driver doesn't issue any seeks at all then. > > What disks are this BTW ? This was RELENG_5 on the 6th at 22:55 UTC. cvsup from my local mirror, so it may have been up to about 70 minutes old. The "singing" only happens when running V5. I have no such sound when I do the same thing with V4. The disk is an Toshiba MK4019GAX. 40 GB ATA100 5400RPM. I get the same performance, though, when using an IBM (now Hitachi) 40GB, ATA100 5400RPM drive. What I am seeing looks a lot like what Bjoern was seeing, so it's not unique to this system. Once again, it's fine on V4. And, it works on Windows. (I just had to say that. I have not actually tested under Windows.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:14: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 281E716A4CE for ; Thu, 9 Sep 2004 21:14:02 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 937A743D39 for ; Thu, 9 Sep 2004 21:14:01 +0000 (GMT) (envelope-from A.J.Caines@halplant.com) Received: from mail.halplant.com ([68.100.60.113]) by lakermmtao01.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040909211359.SAJF25113.lakermmtao01.cox.net@mail.halplant.com> for ; Thu, 9 Sep 2004 17:13:59 -0400 Received: by mail.halplant.com (Postfix, from userid 1001) id C1B3D550D; Thu, 9 Sep 2004 17:14:00 -0400 (EDT) Date: Thu, 9 Sep 2004 17:14:00 -0400 From: Andrew J Caines To: freebsd-current@freebsd.org Message-ID: <20040909211400.GG23872@hal9000.halplant.com> Mail-Followup-To: freebsd-current@freebsd.org References: <4140AFB0.6020002@pythonemproject.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140AFB0.6020002@pythonemproject.com> Organization: H.A.L. Plant X-PGP-Fingerprint: C59A 2F74 1139 9432 B457 0B61 DDF2 AA61 67C3 18A1 X-Powered-by: FreeBSD 4.10-STABLE X-URL: http://halplant.com:88/ X-Yahoo-Profile: AJ_Z0 X-ICQ: 283813972 Importance: Normal User-Agent: Mutt/1.5.6i Subject: Re: Still getting warning messages for rc.conf & default/rc.conf entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew J Caines List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 21:14:02 -0000 Rob, > I have yet to find the source of this problem. Basically from the end > of the boot sequence until I log in, I get a warning message for every > rc.conf and defaults/config entry saying each are misconfigued. I got the same thing after going from RELENG_5_2 to RELENG_5, even though I am sure I ran mergemaster -p before and mergemaster after. Copy src/etc/defaults/rc.conf to /etc/defaults/ and see if this fixes it. -Andrew- -- _______________________________________________________________________ | -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:21: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 CF14E16A4CE for ; Thu, 9 Sep 2004 21:21:44 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9EB843D49 for ; Thu, 9 Sep 2004 21:21:44 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from [192.168.1.101] (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (rwcrmhc11) with ESMTP id <20040909212144013004vdrve> (Authid: europax); Thu, 9 Sep 2004 21:21:44 +0000 Message-ID: <4140C9A7.9020407@pythonemproject.com> Date: Thu, 09 Sep 2004 14:22:47 -0700 From: Rob User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current References: <4140AFB0.6020002@pythonemproject.com> <4140C687.3080406@linuxpowered.com> In-Reply-To: <4140C687.3080406@linuxpowered.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Still getting warning messages for rc.conf & default/rc.conf entries 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, 09 Sep 2004 21:21:44 -0000 Jon Disnard wrote: > Rob wrote: > >> As I understand it rc controls the .config process.. Maybe it needs >> to recompiled. I haven't tried that as this was a binary install from >> an iso.. Will cvsup. > > > hehe... > Good luck recompiling /etc/rc! > > You might investigate using the mergemaster tool. > > -Jon > I will probably recompile the whole system. Have only used mergemaser once, and somehow everything became a mess. Now I just compare timestamps and do it manually. You can actually do this fast with the right technique. Rob From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:24: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 DD4A016A4CE; Thu, 9 Sep 2004 21:24:54 +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 1C05343D49; Thu, 9 Sep 2004 21:24:54 +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 i89LOjJA041353; Thu, 9 Sep 2004 23:24:46 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4140C9F5.5090404@DeepCore.dk> Date: Thu, 09 Sep 2004 23:24:05 +0200 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: Kevin Oberman References: <20040909210541.16C925D09@ptavv.es.net> In-Reply-To: <20040909210541.16C925D09@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 21:24:55 -0000 Kevin Oberman wrote: >>>While the test is running, the disk being written to "sings" with the >>>frequency somewhat dependent on the size of the write. On read, I get >>>silence. When I copy my full disk (if=3D3Dad0 of=3D3Dad2), I can clear= ly he=3D >> >>ar >> >>>the sound of the actuator moving the heads constantly toward the end o= f=3D >> >>>the backup. I assume that they are being returned to track 0 on a >>>repeated basis. >> >>There should be no seeks on a lone write to the raw disk, if there is=3D= 20 >>you have HW problems as the driver doesn't issue any seeks at all then.= >> >>What disks are this BTW ? >=20 >=20 > This was RELENG_5 on the 6th at 22:55 UTC. cvsup from my local mirror, > so it may have been up to about 70 minutes old. >=20 > The "singing" only happens when running V5. I have no such sound when I= > do the same thing with V4.=20 I have no idea, there is nothing in the ATA driver that does extra=20 seeking, so the seek behavior must originate somewhere else, ie=20 something else issues disk requests besides your dd. You could=20 instrument the code and have it write out all LBA's it writes to on ad2=20 to see what gets sent to the disk. > The disk is an Toshiba MK4019GAX. 40 GB ATA100 5400RPM. I get the same > performance, though, when using an IBM (now Hitachi) 40GB, ATA100 > 5400RPM drive. What I am seeing looks a lot like what Bjoern was seeing= , > so it's not unique to this system. Hmm, do you have write cache en/dis-abled ? Just for the fun of it I dd'ed to from my laptop disk through the fs=20 though as I want to keep my data, but that shoudl only make performance=20 worse. Its an ich4 but that uses the same code as the ich2. atapci0: port=20 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ad0: 76319MB [155061/16/63] at ata0-master=20 UDMA100 dd if=3D/dev/zero of=3Dfil bs=3D512 (24474468 bytes/sec) dd if=3D/dev/zero of=3Dfil bs=3D1m (25091961 bytes/sec) thats copying for ~30s as well (reading doesn't make sense here). Both are close to what that disk can do, so there is nothing in the=20 driver thats prohibiting reaching the disks performance... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:32: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 0953616A4CF for ; Thu, 9 Sep 2004 21:32:07 +0000 (GMT) Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id C033043D58 for ; Thu, 9 Sep 2004 21:32:06 +0000 (GMT) (envelope-from nakal@web.de) Received: from [217.225.225.210] (helo=[217.225.225.210]) by smtp06.web.de with esmtp (TLSv1:DES-CBC3-SHA:168) (WEB.DE 4.101 #44) id 1C5WWT-0006dR-00 for freebsd-current@freebsd.org; Thu, 09 Sep 2004 23:32:05 +0200 From: Martin To: FreeBSD Current Content-Type: text/plain Message-Id: <1094765463.754.1.camel@klotz.local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 23:32:02 +0200 Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de Subject: Interrupt storm detected on "irq7: lpt0" 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, 09 Sep 2004 21:32:07 -0000 Hi, I have this problem already for a longer time. After I've sent a print-job to lpr, the system says: Interrupt storm detected on "irq7: lpt0"; throttling interrupt source The worst about it is that the printer is very slow. It needs an hour to print a page of paper. It prints one single line in usual speed and then stops for about a minute. The hardware is OK. I've checked it. I'm using 5.3-BETA3 FreeBSD 5.3-BETA3 #0: Wed Sep 8 18:33:17 CEST 2004 ghostscript-afpl-8.14_6,1 Epson Stylus COLOR a piece of dmesg: ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 Is printing on lpt working at all on -CURRENT? Martin From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21: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 3138416A4CE for ; Thu, 9 Sep 2004 21:35:24 +0000 (GMT) Received: from kestrel.alerce.com (kestrel.alerce.com [209.182.219.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC63D43D62 for ; Thu, 9 Sep 2004 21:35:21 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from rosebud.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (authenticated bits=128) by kestrel.alerce.com (8.12.10/8.12.10) with ESMTP id i89LZJkk015380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Sep 2004 14:35:20 -0700 (PDT) (envelope-from hartzell@kestrel.alerce.com) Received: from rosebud.alerce.com (localhost [127.0.0.1]) by rosebud.alerce.com (8.12.9p2/8.12.9) with ESMTP id i89La0wg006330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 14:36:00 -0700 (PDT) (envelope-from hartzell@rosebud.alerce.com) Received: (from hartzell@localhost) by rosebud.alerce.com (8.12.9p2/8.12.9/Submit) id i89LZxjQ006327; Thu, 9 Sep 2004 14:35:59 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16704.52415.291907.332939@rosebud.alerce.com> Date: Thu, 9 Sep 2004 14:35:59 -0700 To: Randy Bush In-Reply-To: <16701.23928.267840.215410@roam.psg.com> References: <16701.23928.267840.215410@roam.psg.com> X-Mailer: VM 7.14 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-current@freebsd.org Subject: Re: t40 hints, ctls, and loads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@kestrel.alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 21:35:24 -0000 Randy Bush writes: > on my -current t40, i was wondering the best recipies for > sysctls, hints, and loads. what i have now is I just got a t42p and am frantically researching it to decide whether to keep it. Your info was useful, although I think you're missing a 0 in your psm hint (see below). I'm saddened that my t42p doesn't seem to support s4bios suspend (although it will hibernate w/out acpi). I've put notes around some of your settings based on my thinkpad research, could you confirm that I understand the how's and why's? > kernel > > options COMPAT_LINUX > options LINPROCFS [support linux-y stuff (not thinkpad specific)] > > /boot/loader.conf.local > > hw.pci.allow_unsupported_io_range="1" [handle a problem w/ em0, I don't seem to need this...] > hw.ata.atapi_dma="1" [make the dvd drive go faster] > hw.acpi.disable_on_poweroff="1" [keep the machine from randomly reawakening after shutdown] > # > acpi_video_load=YES [support various acpi-based video ops (e.g. setting brightness)] > ipfw_load="YES" [firewall (not thinkpad specific)] > ng_ubt_load=YES [load the netgraph bluetooth stuff (not really thinkpad specific)] > ntfs_load=YES [ntfs support (not thinkpad specific)] > snd_ich_load="YES" > sound_load="YES" [turn on sound support. I think that the second is redundant, it loads *all* of the modules, after the first one loads (presumably) the correct one. What's up?] > # > beastie_disable=NO [do the beastie menu] > > > added to /boot/device.hints > > hint.psm.0.flags="0x200" [tweak the mouse. I *think* you mean "0x2000", which sets the HOOKRESUME bit (see the psm manpage). 0x200 sets the noidprobe, which oughtn't help much.] > can i do better? Anything interesting to say about suspend/hibernate/acpi etc? Did you see my call for Thinkpad stories? Care to contribute? g. From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:41: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 11A0616A4CE; Thu, 9 Sep 2004 21:41:24 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4FFD43D60; Thu, 9 Sep 2004 21:41:23 +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 i89LeqHb067596; Thu, 9 Sep 2004 15:40:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 09 Sep 2004 15:41:23 -0600 (MDT) Message-Id: <20040909.154123.106438047.imp@bsdimp.com> To: mike@sentex.net From: "M. Warner Losh" In-Reply-To: <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <200409091322.19501.jhb@FreeBSD.org> <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: SIO Interrupt storms and unhandled interrupts 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, 09 Sep 2004 21:41:24 -0000 In message: <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> Mike Tancsa writes: : Thanks for the response! We found a different solution / approach : which seems to work on both RELENG_4 and RELENG_5. The problem is that the : modem is not being seen as a PCI / PUC device and instead is being seen as : an ISA SIO device ?? The following RELENG_5 and RELENG_4 patches seem to : fix the problem. I wonder if the other modems listed in sio.c suffer the : same fate ? : : Also fixed in this are those "cant re-use leafs" at bootup time. The modem : is seen as a PUC device now.... At the bottom is a diff between the boot -v I like this fix! I'll see if I can find to commit it. Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:05: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 E571916A4CE for ; Thu, 9 Sep 2004 22:05:08 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAF2843D48 for ; Thu, 9 Sep 2004 22:05:08 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Thu, 09 Sep 2004 15:05:08 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0D27B5D09; Thu, 9 Sep 2004 15:05:08 -0700 (PDT) To: Aurelien NEPHTALI In-reply-to: Your message of "Thu, 09 Sep 2004 07:32:55 +0200." <20040909053255.GA1041@nebula.wanadoo.fr> Date: Thu, 09 Sep 2004 15:05:08 -0700 From: "Kevin Oberman" Message-Id: <20040909220508.0D27B5D09@ptavv.es.net> cc: Chris Laverdure cc: freebsd-current@freebsd.org cc: Grover Lines Subject: Re: X.org 6.8 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, 09 Sep 2004 22:05:09 -0000 > Date: Thu, 9 Sep 2004 07:32:55 +0200 > From: Aurelien NEPHTALI > Sender: owner-freebsd-current@freebsd.org > > Yep! It could be great if someone posts a patch set to apply to the x.org port > to update it to 6.8! > Thanks in advance :) Wow! This is NOT rocket science, but I know I get nervous dealing with part of the system I don't know. If the only change is to pull down the 6.8 sources and build (and I have not tried, so this may not work), replace the PORTVERSION in each xorg Makefile with 6.8.0. Remove the PORTREVISION line (if any),and update the names of the DISTFILES (if any) by changing 6.7.0 to 6.8.0. Remove all of the patches in the files directory. Finally, fetch the distributions and put them in /usr/ports/x11. Get their md5 checksums and add them and the file sizes to distinfo. (Optionally, do a make fetch to fetch the files.) Then do a "portupgrade -R xorg" and you have it. Save your old ports files in case it does not work and you have to back it out. Let us know how it works, I'm sure Eric would appreciate the reports. Please understand that, as much as many of us would like the latest and greatest of things, that is NOT how release engineering works. To get a stable release, you need to have a pretty hard cut-off on changes that are not bug fixes. And that date has passed for both ports and V5.3. There are VERY good reasons for not making exceptions and the FreeBSD REs have learned that they have to take a hard line if they ever hope to get a really solid release out the door. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:07: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 EB44316A4CE; Thu, 9 Sep 2004 22:07:42 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8612043D46; Thu, 9 Sep 2004 22:07:42 +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 i89M7gok009222; Thu, 9 Sep 2004 18:07:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i89M7fnC002449; Thu, 9 Sep 2004 18:07:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D550D7303F; Thu, 9 Sep 2004 18:07:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040909220741.D550D7303F@freebsd-current.sentex.ca> Date: Thu, 9 Sep 2004 18:07:41 -0400 (EDT) Subject: [current tinderbox] failure on powerpc/powerpc 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: Thu, 09 Sep 2004 22:07:43 -0000 TB --- 2004-09-09 21:52:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-09 21:52:11 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2004-09-09 21:52:11 - checking out the source tree TB --- 2004-09-09 21:52:11 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2004-09-09 21:52:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-09 21:57:18 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-09 21:57:18 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2004-09-09 21:57:18 - /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 [...] cc: /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/config/rs6000/crtsavres.asm: linker input file unused because linking not done In file included from ./tm.h:10, from /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:64: /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/config/rs6000/sysv4.h:24:1: warning: "NO_IMPLICIT_EXTERN_C" redefined In file included from ./tm.h:9, from /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:64: /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/config/freebsd.h:69:1: warning: this is the location of the previous definition /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/config/rs6000/crtsavres.asm:40: error: syntax error before '.' token *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2004-09-09 22:07:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-09 22:07:41 - ERROR: failed to build world TB --- 2004-09-09 22:07:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:14: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 38D1116A4CE for ; Thu, 9 Sep 2004 22:14:34 +0000 (GMT) Received: from portalis.it (mail2.portalis.it [213.199.4.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id F39FF43D39 for ; Thu, 9 Sep 2004 22:14:32 +0000 (GMT) (envelope-from esaltato@tele2.it) Received: from [62.123.50.14] ([62.123.50.14]) by portalis.it with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 10 Sep 2004 00:34:35 +0200 Message-ID: <4140D5C6.20905@tele2.it> Date: Fri, 10 Sep 2004 00:14:30 +0200 From: Esaltato User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <41383F2B.5040201@tele2.it> <4140BD41.2080103@tele2.it> In-Reply-To: <4140BD41.2080103@tele2.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: No keyboard with Gnome and X.org (and gnome loaded behind KDE) 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, 09 Sep 2004 22:14:34 -0000 Esaltato wrote: > I hope this is gonna be useful to others. The problem was the > %gconf.xml placed in > /root/.gconf/apps/Esaltato/gnome_settings_daemon/keybindings. The right path was: /root/.gconf/apps/gnome_settings_daemon/keybindings/ Bye, Esaltato From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:17: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 E614D16A4CE for ; Thu, 9 Sep 2004 22:17:17 +0000 (GMT) Received: from flb.schmalzbauer.de (flb.schmalzbauer.de [62.245.232.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC6FF43D54 for ; Thu, 9 Sep 2004 22:17:16 +0000 (GMT) (envelope-from harry@schmalzbauer.de) Received: from korso.flintsbach.schmalzbauer.de (korso.flintsbach.schmalzbauer.de [172.21.2.3]) by flb.schmalzbauer.de (8.12.11/8.12.11) with ESMTP id i89MHDlv025141 for ; Fri, 10 Sep 2004 00:17:13 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from cale.flintsbach.schmalzbauer.de (cale.flintsbach.schmalzbauer.de [172.21.1.253]) by korso.flintsbach.schmalzbauer.de (Postfix) with ESMTP id C2C70D5 for ; Fri, 10 Sep 2004 00:17:13 +0200 (CEST) Received: from cale.flintsbach.schmalzbauer.de (localhost [127.0.0.1]) i89MHDRA000741 for ; Fri, 10 Sep 2004 00:17:13 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from localhost (localhost [[UNIX: localhost]]) i89MHCvh000740 for freebsd-current@freebsd.org; Fri, 10 Sep 2004 00:17:13 +0200 (CEST) (envelope-from harry) From: Harald Schmalzbauer To: freebsd-current@freebsd.org Date: Fri, 10 Sep 2004 00:17:07 +0200 User-Agent: KMail/1.6.2 X-OS: FreeBSD 5.3 X-Country: Germany X-Address: Munich, 80686 X-Phone2: +49 (0) 89 18947781 X-Name: Harald Schmalzbauer X-Birthday: 06 Oktober 1972 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_oZNQBhMzqAevbqn"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200409100017.12733@harryhomeworkstation> X-Spam-Status: No, hits=0.0 required=3.5 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailjail.dmz.flintsbach.schmalzbauer.de Subject: GEOM_GPT on 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: Thu, 09 Sep 2004 22:17:18 -0000 --Boundary-02=_oZNQBhMzqAevbqn Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear GEOM coders, I saw that some time ago GPT was enabled in GENERIC. Is it possible to create GPT labels on i386 and if so, how do I do that? The GPT man page tells about ia64 (only?) Thanks, -Harry --Boundary-02=_oZNQBhMzqAevbqn Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBQNZoBylq0S4AzzwRAvcfAJ91iXW7+yxtzirgDZblyqOMOsPhCQCdEXag Xe9+yDOtIt6oq0QcWCDXZWE= =PXIC -----END PGP SIGNATURE----- --Boundary-02=_oZNQBhMzqAevbqn-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:21: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 8AF7F16A4CE for ; Thu, 9 Sep 2004 22:21:33 +0000 (GMT) Received: from ack.Berkeley.EDU (ack.berkeley.edu [128.32.206.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7442443D69 for ; Thu, 9 Sep 2004 22:21:33 +0000 (GMT) (envelope-from mhunter@ack.Berkeley.EDU) Received: (from mhunter@localhost) by ack.Berkeley.EDU (8.11.3/8.11.3) id i89MLVt29614; Thu, 9 Sep 2004 15:21:31 -0700 (PDT) Date: Thu, 9 Sep 2004 15:21:31 -0700 From: Mike Hunter To: Marian Hettwer Message-ID: <20040909222130.GA29369@ack.Berkeley.EDU> References: <413EB55D.4060307@kernel32.de> <20040908162133.GA17274@ack.Berkeley.EDU> <41408070.4060107@kernel32.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41408070.4060107@kernel32.de> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA3 serial console 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, 09 Sep 2004 22:21:33 -0000 On Sep 09, "Marian Hettwer" wrote: > Mike Hunter wrote: > >On Sep 08, "Marian Hettwer" wrote: > > > >Sorry this doesn't answer the question, but what's the status of using > >"-h" in /boot.config instead of mucking with the /etc files? Is that The > /boot.config is toggling around with the serial console for the boot > loader and the bootup process. > /etc/ttys is needed to enable a serial console after the bootprocess is > finished. Thing of something like a getty in Linux running on ttyS0 ... > > at least this is how I understood serial consoles in FreeBSD-4 ... > > If I was wrong, I'm sure somebody on this list would correct me ;) You're right. The quick config section of the handbook reads: 1. Connect the serial port. The serial console will be on COM1. 2. echo -h > /boot.config to enable the serial console for the boot loader and kernel. 3. Edit /etc/ttys and change off to on for the ttyd0 entry. This enables a login prompt on the serial console, which mirrors how video consoles are typically setup. 4. shutdown -r now will reboot the system with the serial console. I just don't remember doing step 3 for the life of me, but I see that either I or the hacker who 0wns all my boxes did :) Mike From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:26: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 8FE7916A4CE for ; Thu, 9 Sep 2004 22:26:52 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5991B43D54 for ; Thu, 9 Sep 2004 22:26:52 +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 i89MSoX0001716; Thu, 9 Sep 2004 15:28:50 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i89MSo31001715; Thu, 9 Sep 2004 15:28:50 -0700 Date: Thu, 9 Sep 2004 15:28:50 -0700 From: Brooks Davis To: Harald Schmalzbauer Message-ID: <20040909222850.GA29917@odin.ac.hmc.edu> References: <200409100017.12733@harryhomeworkstation> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <200409100017.12733@harryhomeworkstation> 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: GEOM_GPT on 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: Thu, 09 Sep 2004 22:26:52 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2004 at 12:17:07AM +0200, Harald Schmalzbauer wrote: > Dear GEOM coders, >=20 > I saw that some time ago GPT was enabled in GENERIC. > Is it possible to create GPT labels on i386 and if so, how do I do that? > The GPT man page tells about ia64 (only?) The gpt(8) command should work on any architecture it is installed on (!sparc64). -- 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 --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQNkhXY6L6fI4GtQRAiD+AKCPk3LMHH9VoHJjuRGfpOPWFXNADACgxExa AuzfVFsOjnWJ3RBH3vsBnNY= =TTtc -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:27: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 8668316A4CE for ; Thu, 9 Sep 2004 22:27:50 +0000 (GMT) Received: from picard.newmillennium.net.au (dsl-114.250.240.220.dsl.comindico.com.au [220.240.250.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53E1543D1D for ; Thu, 9 Sep 2004 22:27:47 +0000 (GMT) (envelope-from freebsd@newmillennium.net.au) Received: from [172.16.0.67] (crusher.nmn.cafn [172.16.0.67]) i89MRjjq000926 for ; Fri, 10 Sep 2004 08:27:45 +1000 (EST) (envelope-from freebsd@newmillennium.net.au) From: "Alastair D'Silva" To: freebsd-current@freebsd.org Content-Type: text/plain Organization: New Millennium Networking Message-Id: <1094768862.1380.10.camel@crusher.laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 08:27:42 +1000 Content-Transfer-Encoding: 7bit Subject: Transparent proxying broken? 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, 09 Sep 2004 22:27:50 -0000 It seems that transparent proxying has been broken with all the changes to the networking stack. These are the relevant rules (where nmn_wireless and internet are #defines) add 3501 fwd 127.0.0.1,3128 tcp from nmn_wireless to internet 80 keep-state add 3502 fwd 127.0.0.1,25 tcp from nmn_wireless to internet 25 keep-state Uname output: FreeBSD picard.newmillennium.net.au 6.0-CURRENT FreeBSD 6.0-CURRENT #20: Thu Sep 9 20:48:35 EST 2004 root@picard.newmillennium.net.au:/usr/obj/usr/src/sys/PICARD i386 Trying to connect from the nmn_wireless network: bash-2.05b$ telnet www.freebsd.org 80 Trying 216.136.204.117... telnet: connect to address 216.136.204.117: Operation timed out telnet: Unable to connect to remote host Tcpdump output of the above session: picard# tcpdump -i ath0 not port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes 08:22:28.451296 IP crusher.nmn.cafn.57238 > gateway.fedpark.cafn.domain: 34209+ [1au] AAAA? ns1.downloadtech.com. (49) 08:22:28.451438 IP crusher.nmn.cafn.57238 > gateway.fedpark.cafn.domain: 9384+ [1au] AAAA? ns2.downloadtech.com. (49) 08:22:28.451916 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4 239655572(0) win 65535 08:22:28.652615 IP gateway.fedpark.cafn.domain > crusher.nmn.cafn.57238: 34209 0/1/1 (96) 08:22:28.654474 IP gateway.fedpark.cafn.domain > crusher.nmn.cafn.57238: 9384 0 /1/1 (96) 08:22:31.448320 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4 239655572(0) win 65535 08:22:34.648455 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4 239655572(0) win 65535 08:22:37.848571 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4239655572(0) win 65535 08:22:41.048682 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4239655572(0) win 65535 08:22:44.248793 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4239655572(0) win 65535 08:22:50.449890 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4239655572(0) win 65535 08:22:59.826015 IP crusher.nmn.cafn.57065 > picard.imap: P 1133767632:1133767689(57) ack 2198428885 win 33304 08:22:59.856870 IP picard.imap > crusher.nmn.cafn.57065: P 1:29(28) ack 57 win 33304 08:22:59.958772 IP crusher.nmn.cafn.57065 > picard.imap: . ack 29 win 33304 08:23:02.661828 IP crusher.nmn.cafn.52164 > www.freebsd.org.http: S 4239655572:4239655572(0) win 65535 Connecting to the Squid port that was forwarded to for transparent proxying: bash-2.05b$ telnet picard.nmn.cafn 3128 Trying 10.0.1.1... Connected to picard.nmn.cafn. Escape character is '^]'. After deleting rule 3501, everything works (the connection also works from picard) . . . bash-2.05b$ telnet www.freebsd.org 80 Trying 216.136.204.117... Connected to www.freebsd.org. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 06 Sep 2004 22:25:43 GMT Server: Apache/1.3.x LaHonda (Unix) Last-Modified: Mon, 30 Aug 2004 21:24:54 GMT ETag: "26fc4c-8b7c-41339b26" Accept-Ranges: bytes Content-Length: 35708 Connection: close Content-Type: text/html X-Pad: avoid browser bug Connection closed by foreign host. -- Alastair D'Silva mob: 0423 762 819 Networking Consultant fax: 0413 181 661 New Millennium Networking web: http://www.newmillennium.net.au From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:31: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 39F3216A4D0 for ; Thu, 9 Sep 2004 22:31:25 +0000 (GMT) Received: from linwhf.opal.com (99.79.171.66.subscriber.vzavenue.net [66.171.79.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E87643D45 for ; Thu, 9 Sep 2004 22:31:24 +0000 (GMT) (envelope-from jr@linwhf.opal.com) Received: from linwhf.opal.com (localhost [127.0.0.1]) by linwhf.opal.com (8.13.1/8.13.1) with ESMTP id i89MV6TH000896; Thu, 9 Sep 2004 18:31:06 -0400 (EDT) (envelope-from jr@linwhf.opal.com) Received: (from jr@localhost) by linwhf.opal.com (8.13.1/8.13.1/Submit) id i89MV53P000895; Thu, 9 Sep 2004 18:31:05 -0400 (EDT) (envelope-from jr) Date: Thu, 9 Sep 2004 18:31:05 -0400 From: "J.R. Oldroyd" To: =?iso-8859-1?Q?S=F8ren?= Schmidt , current@freebsd.org Message-ID: <20040909223105.GA779@linwhf.opal.com> References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> <20040830192224.GB809@linwhf.opal.com> <413390B9.5050705@DeepCore.dk> <20040831144205.GA817@linwhf.opal.com> <4134DE3C.7080303@DeepCore.dk> <20040831233543.GA836@linwhf.opal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040831233543.GA836@linwhf.opal.com> User-Agent: Mutt/1.4.2.1i Subject: Re: Current 9/10/2004, DVD 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: Thu, 09 Sep 2004 22:31:25 -0000 Following up on this, I now have the -current of 9/10/2004 at about 18:00 GMT, but it still doesn't boot in normal mode. Still hangs at the DVD probe. Does still boot OK in verbose mode. -jr On Aug 31, 19:35, J.R. Oldroyd wrote: > Afraid not. > > Just to confirm since my line numbers seem to be a few off yours... > > I have: > __FBSDID("$FreeBSD: src/sys/dev/ata/ata-lowlevel.c,v 1.46 2004/08/27 22:14:45 sos Exp $"); > > And after adding the extra call to ata_wait() there are now TWO ata_wait()s: > > int > ata_generic_command(struct ata_device *atadev, u_int8_t command, > u_int64_t lba, u_int16_t count, u_int16_t feature) > { > if (atadebug) > ata_prtdev(atadev, "ata_command: addr=%04lx, command=%02x, " > "lba=%jd, count=%d, feature=%d\n", > rman_get_start(atadev->channel->r_io[ATA_DATA].res), > command, (intmax_t)lba, count, feature); > > /* ready to issue command ? */ > if (ata_wait(atadev, 0) < 0) { > ata_prtdev(atadev, "timeout waiting for ready command=%02x\n", command); > return -1; > } > > /* select device */ > ATA_IDX_OUTB(atadev->channel, ATA_DRIVE, ATA_D_IBM | atadev->unit); > > /* ready to issue command ? */ > if (ata_wait(atadev, 0) < 0) { > ata_prtdev(atadev, "timeout sending command=%02x\n", command); > return -1; > } > > /* enable interrupt */ > ATA_IDX_OUTB(atadev->channel, ATA_ALTSTAT, ATA_A_4BIT); > > Same result. Hangs at the CD probe with a normal boot. Hangs also > in verbose mode with a disc in. Does boot in verbose mode with no > disc in. > > -jr > > > > On Aug 31, 22:23, Søren Schmidt wrote: > > J.R. Oldroyd wrote: > > >Some follow-up. > > > > > >Similar to other folks with this problem, the system will boot in > > >verbose mode. However, ONLY with no medium. If medium is present, > > >it still hangs. If the tray is empty, it will boot in either DMA or > > >PIO mode. And if I then insert a disc, I can read it OK. > > > > Hmm does the attached patch change behavior in any way ? > > > > -Søren > > > Index: ata-lowlevel.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v > > retrieving revision 1.44 > > diff -u -r1.44 ata-lowlevel.c > > --- ata-lowlevel.c 16 Aug 2004 09:32:35 -0000 1.44 > > +++ ata-lowlevel.c 24 Aug 2004 07:25:32 -0000 > > @@ -721,6 +721,12 @@ > > rman_get_start(atadev->channel->r_io[ATA_DATA].res), > > command, (intmax_t)lba, count, feature); > > > > + /* ready to issue command ? */ > > + if (ata_wait(atadev, 0) < 0) { > > + ata_prtdev(atadev, "timeout waiting for ready command=%02x\n", command); > > + return -1; > > + } > > + > > /* select device */ > > ATA_IDX_OUTB(atadev->channel, ATA_DRIVE, ATA_D_IBM | atadev->unit); > > > > _______________________________________________ > 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 Sep 9 22:31: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 2044B16A4CF for ; Thu, 9 Sep 2004 22:31:40 +0000 (GMT) Received: from flb.schmalzbauer.de (flb.schmalzbauer.de [62.245.232.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F31443D49 for ; Thu, 9 Sep 2004 22:31:39 +0000 (GMT) (envelope-from harry@schmalzbauer.de) Received: from korso.flintsbach.schmalzbauer.de (korso.flintsbach.schmalzbauer.de [172.21.2.3])i89MVZ7E025311; Fri, 10 Sep 2004 00:31:35 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from cale.flintsbach.schmalzbauer.de (cale.flintsbach.schmalzbauer.de [172.21.1.253]) by korso.flintsbach.schmalzbauer.de (Postfix) with ESMTP id C604813D; Fri, 10 Sep 2004 00:31:35 +0200 (CEST) Received: from cale.flintsbach.schmalzbauer.de (localhost [127.0.0.1]) i89MVaMw000863; Fri, 10 Sep 2004 00:31:36 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from localhost (localhost [[UNIX: localhost]]) i89MVZIY000862; Fri, 10 Sep 2004 00:31:35 +0200 (CEST) (envelope-from harry) From: Harald Schmalzbauer To: freebsd-current@freebsd.org Date: Fri, 10 Sep 2004 00:31:35 +0200 User-Agent: KMail/1.6.2 References: <200409100017.12733@harryhomeworkstation> <20040909222850.GA29917@odin.ac.hmc.edu> In-Reply-To: <20040909222850.GA29917@odin.ac.hmc.edu> X-OS: FreeBSD 5.3 X-Country: Germany X-Address: Munich, 80686 X-Phone2: +49 (0) 89 18947781 X-Name: Harald Schmalzbauer X-Birthday: 06 Oktober 1972 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_HnNQBpAi4ZFEXrM"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409100031.35536@harryhomeworkstation> X-Spam-Status: No, hits=0.0 required=3.5 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailjail.dmz.flintsbach.schmalzbauer.de Subject: Re: GEOM_GPT on 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: Thu, 09 Sep 2004 22:31:40 -0000 --Boundary-02=_HnNQBpAi4ZFEXrM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 10. September 2004 00:28 schrieb Brooks Davis: > On Fri, Sep 10, 2004 at 12:17:07AM +0200, Harald Schmalzbauer wrote: > > Dear GEOM coders, > > > > I saw that some time ago GPT was enabled in GENERIC. > > Is it possible to create GPT labels on i386 and if so, how do I do that? > > The GPT man page tells about ia64 (only?) > > The gpt(8) command should work on any architecture it is installed on > (!sparc64). Thank you, but this doesn't neccessarily mean that I can use GPT to boot my= =20 i386 5.3 box to get rid of the 8-label Limit, does it? Has anybody succesfully changed to GPT on i386 (by `gpt migrate /dev/ad0`)? Thanks, =2DHarry > > -- Brooks --Boundary-02=_HnNQBpAi4ZFEXrM Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBQNnHBylq0S4AzzwRAoCPAJwOk5b2EK5b8fly1HkqqcCT7OuZbwCfSg/J /5jcVahS3sjmpzUuTcJpcsE= =9TLg -----END PGP SIGNATURE----- --Boundary-02=_HnNQBpAi4ZFEXrM-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:35: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 952E016A4CE for ; Thu, 9 Sep 2004 22:35:57 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B10343D58 for ; Thu, 9 Sep 2004 22:35:57 +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 i89Mbtsc003312; Thu, 9 Sep 2004 15:37:55 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i89Mbte3003311; Thu, 9 Sep 2004 15:37:55 -0700 Date: Thu, 9 Sep 2004 15:37:55 -0700 From: Brooks Davis To: Harald Schmalzbauer Message-ID: <20040909223755.GA3143@odin.ac.hmc.edu> References: <200409100017.12733@harryhomeworkstation> <20040909222850.GA29917@odin.ac.hmc.edu> <200409100031.35536@harryhomeworkstation> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <200409100031.35536@harryhomeworkstation> 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: GEOM_GPT on 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: Thu, 09 Sep 2004 22:35:57 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2004 at 12:31:35AM +0200, Harald Schmalzbauer wrote: > Am Freitag, 10. September 2004 00:28 schrieb Brooks Davis: > > On Fri, Sep 10, 2004 at 12:17:07AM +0200, Harald Schmalzbauer wrote: > > > Dear GEOM coders, > > > > > > I saw that some time ago GPT was enabled in GENERIC. > > > Is it possible to create GPT labels on i386 and if so, how do I do th= at? > > > The GPT man page tells about ia64 (only?) > > > > The gpt(8) command should work on any architecture it is installed on > > (!sparc64). >=20 > Thank you, but this doesn't neccessarily mean that I can use GPT to boot = my=20 > i386 5.3 box to get rid of the 8-label Limit, does it? > Has anybody succesfully changed to GPT on i386 (by `gpt migrate /dev/ad0`= )? As far as I know, there is no boot support for GPT yet. That's something I would like to see, but it's not there yet. Which feature(s) of GPT do you need? -- 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 --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQNtCXY6L6fI4GtQRAt6WAJ4q4nKdhjawixslaDfI30JcEIRIfQCfct3a VoOoKz1Vf9qDyJXy5jNtRyQ= =bhq9 -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:38: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 0D1C716A4CE; Thu, 9 Sep 2004 22:38:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F71F43D2D; Thu, 9 Sep 2004 22:38:20 +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 i89MaKoj068255; Thu, 9 Sep 2004 16:36:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 09 Sep 2004 16:36:53 -0600 (MDT) Message-Id: <20040909.163653.88001573.imp@bsdimp.com> To: roam@ringlet.net From: "M. Warner Losh" In-Reply-To: <20040908150943.GA1924@straylight.m.ringlet.net> References: <20040908150943.GA1924@straylight.m.ringlet.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Fix USB panics 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, 09 Sep 2004 22:38:21 -0000 Hopefully the recently committed changes will fix this problem. Thanks again for your testing, your useful analysis and preliminary patches. Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:42: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 35D8516A4CE for ; Thu, 9 Sep 2004 22:42:32 +0000 (GMT) Received: from flb.schmalzbauer.de (flb.schmalzbauer.de [62.245.232.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 634C443D3F for ; Thu, 9 Sep 2004 22:42:31 +0000 (GMT) (envelope-from harry@schmalzbauer.de) Received: from korso.flintsbach.schmalzbauer.de (korso.flintsbach.schmalzbauer.de [172.21.2.3])i89MgSOq025441; Fri, 10 Sep 2004 00:42:28 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from cale.flintsbach.schmalzbauer.de (cale.flintsbach.schmalzbauer.de [172.21.1.253]) by korso.flintsbach.schmalzbauer.de (Postfix) with ESMTP id 0E40BD5; Fri, 10 Sep 2004 00:42:28 +0200 (CEST) Received: from cale.flintsbach.schmalzbauer.de (localhost [127.0.0.1]) i89MgSIh000941; Fri, 10 Sep 2004 00:42:28 +0200 (CEST) (envelope-from harry@cale.flintsbach.schmalzbauer.de) Received: from localhost (localhost [[UNIX: localhost]]) i89MgSvX000940; Fri, 10 Sep 2004 00:42:28 +0200 (CEST) (envelope-from harry) From: Harald Schmalzbauer To: freebsd-current@freebsd.org Date: Fri, 10 Sep 2004 00:42:27 +0200 User-Agent: KMail/1.6.2 References: <200409100017.12733@harryhomeworkstation> <200409100031.35536@harryhomeworkstation> <20040909223755.GA3143@odin.ac.hmc.edu> In-Reply-To: <20040909223755.GA3143@odin.ac.hmc.edu> X-OS: FreeBSD 5.3 X-Country: Germany X-Address: Munich, 80686 X-Phone2: +49 (0) 89 18947781 X-Name: Harald Schmalzbauer X-Birthday: 06 Oktober 1972 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_TxNQBw+ep64q0Gk"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409100042.27877@harryhomeworkstation> X-Spam-Status: No, hits=0.0 required=3.5 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailjail.dmz.flintsbach.schmalzbauer.de Subject: Re: GEOM_GPT on 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: Thu, 09 Sep 2004 22:42:32 -0000 --Boundary-02=_TxNQBw+ep64q0Gk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 10. September 2004 00:37 schrieb Brooks Davis: > On Fri, Sep 10, 2004 at 12:31:35AM +0200, Harald Schmalzbauer wrote: > > Am Freitag, 10. September 2004 00:28 schrieb Brooks Davis: > > > On Fri, Sep 10, 2004 at 12:17:07AM +0200, Harald Schmalzbauer wrote: > > > > Dear GEOM coders, > > > > > > > > I saw that some time ago GPT was enabled in GENERIC. > > > > Is it possible to create GPT labels on i386 and if so, how do I do > > > > that? The GPT man page tells about ia64 (only?) > > > > > > The gpt(8) command should work on any architecture it is installed on > > > (!sparc64). > > > > Thank you, but this doesn't neccessarily mean that I can use GPT to boot > > my i386 5.3 box to get rid of the 8-label Limit, does it? > > Has anybody succesfully changed to GPT on i386 (by `gpt migrate > > /dev/ad0`)? > > As far as I know, there is no boot support for GPT yet. That's > something I would like to see, but it's not there yet. Which feature(s) > of GPT do you need? Hmm, can I make use of GPT without having boot support? Perhaps you have a= =20 link handy which illustrates the GPT on disk and the BIOS interactivity. Is= =20 it possible to have both, MBR and GPT? I can't imagine. My particular problem is that I want to have every jail in it's own label, = but=20 then I have to slice my disk (array), because I have roundabout 20 jails,=20 which makes it impossible to rearrange label-sizes. =2DHarry > -- Brooks --Boundary-02=_TxNQBw+ep64q0Gk Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBQNxTBylq0S4AzzwRAgV1AJ95iBVtXcTyE+o5IRAYRjNkTXYp2gCfSOO9 uUDS5U/jDWvAlDSdFUZ+aLw= =ogKn -----END PGP SIGNATURE----- --Boundary-02=_TxNQBw+ep64q0Gk-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 22:49: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 78A3F16A4CE for ; Thu, 9 Sep 2004 22:49:24 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D4D43D2D for ; Thu, 9 Sep 2004 22:49:24 +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 i89MpMUU005205; Thu, 9 Sep 2004 15:51:22 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i89MpMrg005204; Thu, 9 Sep 2004 15:51:22 -0700 Date: Thu, 9 Sep 2004 15:51:22 -0700 From: Brooks Davis To: Harald Schmalzbauer Message-ID: <20040909225122.GA4335@odin.ac.hmc.edu> References: <200409100017.12733@harryhomeworkstation> <200409100031.35536@harryhomeworkstation> <20040909223755.GA3143@odin.ac.hmc.edu> <200409100042.27877@harryhomeworkstation> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <200409100042.27877@harryhomeworkstation> 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: GEOM_GPT on 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: Thu, 09 Sep 2004 22:49:24 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2004 at 12:42:27AM +0200, Harald Schmalzbauer wrote: > Am Freitag, 10. September 2004 00:37 schrieb Brooks Davis: > > On Fri, Sep 10, 2004 at 12:31:35AM +0200, Harald Schmalzbauer wrote: > > > Am Freitag, 10. September 2004 00:28 schrieb Brooks Davis: > > > > On Fri, Sep 10, 2004 at 12:17:07AM +0200, Harald Schmalzbauer wrote: > > > > > Dear GEOM coders, > > > > > > > > > > I saw that some time ago GPT was enabled in GENERIC. > > > > > Is it possible to create GPT labels on i386 and if so, how do I do > > > > > that? The GPT man page tells about ia64 (only?) > > > > > > > > The gpt(8) command should work on any architecture it is installed = on > > > > (!sparc64). > > > > > > Thank you, but this doesn't neccessarily mean that I can use GPT to b= oot > > > my i386 5.3 box to get rid of the 8-label Limit, does it? > > > Has anybody succesfully changed to GPT on i386 (by `gpt migrate > > > /dev/ad0`)? > > > > As far as I know, there is no boot support for GPT yet. That's > > something I would like to see, but it's not there yet. Which feature(s) > > of GPT do you need? >=20 > Hmm, can I make use of GPT without having boot support? Perhaps you > have a link handy which illustrates the GPT on disk and the BIOS > interactivity. Is it possible to have both, MBR and GPT? I can't > imagine. My particular problem is that I want to have every jail in > it's own label, but then I have to slice my disk (array), because > I have roundabout 20 jails, which makes it impossible to rearrange > label-sizes. While GPT was intended to be the only label on the disk, GEOM does not have any such restrictions. You can place any label on any geom. My suggestion would be to allocation a slice or bsdlabel partition for the GPT. Then use GPT to chop that up to meet the demands of the jails. For example, you could have: da0s1a / da0s1b swap da0s1d /var da0s1e /tmp da0s1f /usr da0s2 da0s2 could also be da0s1g. -- 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 --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQN5pXY6L6fI4GtQRAjwmAJ4o2uGjLtWox4mVSm4wr45p12NehgCg44T3 8ZNHXdc/fAoIQExsgXG86vo= =GroB -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 23:14: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 76E0C16A4CE; Thu, 9 Sep 2004 23:14:09 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F4C43D31; Thu, 9 Sep 2004 23:14:09 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 09 Sep 2004 16:14:08 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 62F895D04; Thu, 9 Sep 2004 16:14:08 -0700 (PDT) To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-reply-to: Your message of "Thu, 09 Sep 2004 23:24:05 +0200." <4140C9F5.5090404@DeepCore.dk> Date: Thu, 09 Sep 2004 16:14:08 -0700 From: "Kevin Oberman" Message-Id: <20040909231408.62F895D04@ptavv.es.net> cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig Subject: Re: poor ATA disk speed with ICH2 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, 09 Sep 2004 23:14:09 -0000 > Date: Thu, 09 Sep 2004 23:24:05 +0200 > From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= > > Kevin Oberman wrote: > > >>>While the test is running, the disk being written to "sings" with the > >>>frequency somewhat dependent on the size of the write. On read, I get > >>>silence. When I copy my full disk (if=3D3Dad0 of=3D3Dad2), I can clear= > ly he=3D > >> > >>ar > >> > >>>the sound of the actuator moving the heads constantly toward the end o= > f=3D > >> > >>>the backup. I assume that they are being returned to track 0 on a > >>>repeated basis. > >> > >>There should be no seeks on a lone write to the raw disk, if there is=3D= > 20 > >>you have HW problems as the driver doesn't issue any seeks at all then.= > > >> > >>What disks are this BTW ? > >=20 > >=20 > > This was RELENG_5 on the 6th at 22:55 UTC. cvsup from my local mirror, > > so it may have been up to about 70 minutes old. > >=20 > > The "singing" only happens when running V5. I have no such sound when I= > > > do the same thing with V4.=20 > > I have no idea, there is nothing in the ATA driver that does extra=20 > seeking, so the seek behavior must originate somewhere else, ie=20 > something else issues disk requests besides your dd. You could=20 > instrument the code and have it write out all LBA's it writes to on ad2=20 > to see what gets sent to the disk. > > > The disk is an Toshiba MK4019GAX. 40 GB ATA100 5400RPM. I get the same > > performance, though, when using an IBM (now Hitachi) 40GB, ATA100 > > 5400RPM drive. What I am seeing looks a lot like what Bjoern was seeing= > , > > so it's not unique to this system. > > Hmm, do you have write cache en/dis-abled ? > > Just for the fun of it I dd'ed to from my laptop disk through the fs=20 > though as I want to keep my data, but that shoudl only make performance=20 > worse. Its an ich4 but that uses the same code as the ich2. > > atapci0: port=20 > 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 > ad0: 76319MB [155061/16/63] at ata0-master=20 > UDMA100 > > dd if=3D/dev/zero of=3Dfil bs=3D512 (24474468 bytes/sec) > dd if=3D/dev/zero of=3Dfil bs=3D1m (25091961 bytes/sec) > > thats copying for ~30s as well (reading doesn't make sense here). > > Both are close to what that disk can do, so there is nothing in the > driver thats prohibiting reaching the disks performance... Weird. So what changes between V4 and V5 to cause this? (Actually, I am unsure when it "slowed sown". I suspect it was with ATAng, but I just don't remember any more and I don't have time right now to roll my system back to pre-5.1 to see. Maybe this weekend. I DO have disk cache enabled. I figured that the chance of a sudden power failure happening on my laptop are very slim. (That was before the preemption problem interacted with ACPI and killed the power to my system.) Clearly, if the heads are moving, it is not after every write. The times would be MUCH worse than they are. Also, when I copy my full disk, the throughput increases fairly dramatically toward the end of the copy. I'll admit that I'm baffled at this point. I will do more testing, probably with ktr, but it will have to wait until I have a bit more time. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 00:06: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 58E3E16A4CE for ; Fri, 10 Sep 2004 00:06:47 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B4C43D46 for ; Fri, 10 Sep 2004 00:06:46 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 6497450BA6; Fri, 10 Sep 2004 09:06:45 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id D7EB750B8C; Fri, 10 Sep 2004 09:06:43 +0900 (JST) Date: Fri, 10 Sep 2004 09:06:43 +0900 Message-ID: <7msm9roulo.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current In-Reply-To: <20040909180557.GM72089@funkthat.com> References: <7mhdq7sdvn.wl@black.imgsrc.co.jp> <20040909180557.GM72089@funkthat.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: John-Mark Gurney Subject: Re: panic: mutex Giant not owned 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, 10 Sep 2004 00:06:47 -0000 At Thu, 9 Sep 2004 11:05:57 -0700, John-Mark Gurney wrote: > > panic: mutex Giant not owned at /usr/src/sys/kern/kern_event.c:1334 > > Just remove the GIANT_REQUIRED; line on 1334, and try again... If this > works for you, I'll commit the fix... I tested without this line, and it seems fine! Thanks! -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 00:17: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 842D916A4CE for ; Fri, 10 Sep 2004 00:17:13 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1B9843D5A for ; Fri, 10 Sep 2004 00:17:12 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C5Z6F-000Ki0-BK for freebsd-current@freebsd.org; Fri, 10 Sep 2004 02:17:11 +0200 Date: Fri, 10 Sep 2004 02:17:11 +0200 From: Oliver Brandmueller To: freebsd-current@freebsd.org Message-ID: <20040910001711.GA79295@e-Gitt.NET> Mail-Followup-To: freebsd-current@freebsd.org References: <1094768862.1380.10.camel@crusher.laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094768862.1380.10.camel@crusher.laptop> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller Subject: Re: Transparent proxying broken? 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, 10 Sep 2004 00:17:13 -0000 Hi. On Fri, Sep 10, 2004 at 08:27:42AM +1000, Alastair D'Silva wrote: > It seems that transparent proxying has been broken with all the changes > to the networking stack. Have a look at the thread "RELENG_5 ipfw problem" starting Aug 27 in this mailing list. There are hints about using a special kernel option and also me with a forwarding problem even with this kernel option. Please give your comments to this thread then also. - 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 Fri Sep 10 00:41: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 458F316A4CE; Fri, 10 Sep 2004 00:41:08 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E873543D5F; Fri, 10 Sep 2004 00:41:07 +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 i8A0f7Cw028987; Thu, 9 Sep 2004 20:41:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8A0f77h046888; Thu, 9 Sep 2004 20:41:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5DB387303F; Thu, 9 Sep 2004 20:41:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040910004107.5DB387303F@freebsd-current.sentex.ca> Date: Thu, 9 Sep 2004 20:41:07 -0400 (EDT) Subject: [releng_5 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, 10 Sep 2004 00:41:08 -0000 TB --- 2004-09-09 23:40:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-09 23:40:20 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2004-09-09 23:40:20 - checking out the source tree TB --- 2004-09-09 23:40:20 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2004-09-09 23:40:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-09 23:47:53 - building world (CFLAGS=-O -pipe) TB --- 2004-09-09 23:47:53 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-09 23:47:53 - /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-09-10 00:36:27 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-10 00:36:27 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-10 00:36:27 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 10 00:36:27 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 [...] : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x15a8): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x1668): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x16ec): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text3+0x0): additional relocation overflows omitted from the output *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/obj/alpha/tinderbox/RELENG_5/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. TB --- 2004-09-10 00:41:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-10 00:41:07 - ERROR: failed to build generic kernel TB --- 2004-09-10 00:41:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 01:11: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 4DD4116A4CF for ; Fri, 10 Sep 2004 01:11:08 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6786443D41 for ; Fri, 10 Sep 2004 01:11:07 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8A1AxVV077062; Thu, 9 Sep 2004 21:10:59 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 76463-06; Thu, 9 Sep 2004 21:10:59 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8A1AxJk077041; Thu, 9 Sep 2004 21:10:59 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8A1AqIW002489; Thu, 9 Sep 2004 21:10:52 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040909210420.0896df90@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 09 Sep 2004 21:16:47 -0400 To: "M. Warner Losh" From: Mike Tancsa In-Reply-To: <20040909.154123.106438047.imp@bsdimp.com> References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <200409091322.19501.jhb@FreeBSD.org> <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> <20040909.154123.106438047.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-current@freebsd.org Subject: Re: SIO Interrupt storms and unhandled interrupts 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, 10 Sep 2004 01:11:08 -0000 At 05:41 PM 09/09/2004, M. Warner Losh wrote: >I like this fix! I'll see if I can find time to commit it. I messed up the RELENG_4 patch when posting. Here it is again. If you could commit it (especially to RELENG_4) that would be really great! It would reduce the manual bug fixes we have to commit after each cvsup by one more! # diff -u sys/isa/sio.c.prev sys/isa/sio.c --- sys/isa/sio.c.prev Thu Sep 9 20:54:24 2004 +++ sys/isa/sio.c Thu Sep 9 20:54:38 2004 @@ -602,7 +602,6 @@ { 0x048011c1, "Lucent kermit based PCI Modem", 0x14 }, { 0x95211415, "Oxford Semiconductor PCI Dual Port Serial", 0x10 }, { 0x7101135e, "SeaLevel Ultra 530.PCI Single Port Serial", 0x18 }, - { 0x0000151f, "SmartLink 5634PCV SurfRider", 0x10 }, { 0x98459710, "Netmos Nm9845 PCI Bridge with Dual UART", 0x10 }, { 0x00000000, NULL, 0 } }; and # diff -u sys/dev/puc/pucdata.c.prev sys/dev/puc/pucdata.c --- sys/dev/puc/pucdata.c.prev Thu Sep 9 21:01:30 2004 +++ sys/dev/puc/pucdata.c Thu Sep 9 21:02:48 2004 @@ -804,6 +804,15 @@ }, }, + { "SmartLink 5634PCV SurfRider", + { 0x151f, 0x0000, 0, 0 }, + { 0xffff, 0xffff, 0, 0 }, + { + { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, + }, + }, + + /* Actiontec 56K PCI Master */ { "Actiontec 56K PCI Master", { 0x11c1, 0x0480, 0x0, 0x0 }, From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 01:28: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 E267316A4CE for ; Fri, 10 Sep 2004 01:28:21 +0000 (GMT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4193843D5F for ; Fri, 10 Sep 2004 01:28:21 +0000 (GMT) (envelope-from A.J.Caines@halplant.com) Received: from mail.halplant.com ([68.100.60.113]) by lakermmtao02.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040910012821.WWXF703.lakermmtao02.cox.net@mail.halplant.com> for ; Thu, 9 Sep 2004 21:28:21 -0400 Received: by mail.halplant.com (Postfix, from userid 1001) id 0B645550C; Thu, 9 Sep 2004 21:28:20 -0400 (EDT) Date: Thu, 9 Sep 2004 21:28:19 -0400 From: Andrew J Caines To: FreeBSD Current Message-ID: <20040910012819.GH23872@hal9000.halplant.com> Mail-Followup-To: FreeBSD Current References: <4140AFB0.6020002@pythonemproject.com> <4140C687.3080406@linuxpowered.com> <4140C9A7.9020407@pythonemproject.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4140C9A7.9020407@pythonemproject.com> Organization: H.A.L. Plant X-PGP-Fingerprint: C59A 2F74 1139 9432 B457 0B61 DDF2 AA61 67C3 18A1 X-Powered-by: FreeBSD 4.10-STABLE X-URL: http://halplant.com:88/ X-Yahoo-Profile: AJ_Z0 X-ICQ: 283813972 Importance: Normal User-Agent: Mutt/1.5.6i Subject: Re: Still getting warning messages for rc.conf & default/rc.conf entries X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew J Caines List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 01:28:22 -0000 Rob, > I will probably recompile the whole system. Waste of time and of no relevance to the problem. If you want to do something again to ensure currency, remove and cvsup your sources. > Have only used mergemaser once, and somehow everything became a mess. Having used it many times in many situations since before it was part of the system and given the lack of any avalanch of reports on the lists, I'm quite confident you messed it up and that mergmaster works very well. > Now I just compare timestamps and do it manually. You are certainly missing some steps which mergmaster handles. No comment on recompiling /etc/rc. I suggest following my earlier advice and running mergmaster. -Andrew- -- _______________________________________________________________________ | -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 01:28: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 6634B16A530; Fri, 10 Sep 2004 01:28:29 +0000 (GMT) Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id C09CE43D1F; Fri, 10 Sep 2004 01:28:28 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from [192.168.1.101] (cpe-065-184-172-100.ec.rr.com [65.184.172.100])i8A1SPSG007047; Thu, 9 Sep 2004 21:28:25 -0400 (EDT) Message-ID: <4141034C.1080700@ec.rr.com> Date: Thu, 09 Sep 2004 21:28:44 -0400 From: jason User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040808) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: 'Robert Watson' cc: current@freebsd.org Subject: Re: FreeBSD 5.3 Bridge performance take II 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, 10 Sep 2004 01:28:29 -0000 Daniel Eriksson wrote: >Robert Watson wrote: > > > >>If you're not already disabling harvesting of entropy on interrupts and >>in network processing, you really want to for performance purposes. >> >> > >How do I disable this without causing entropy starvation for "typical" use >cases (ssl? ssh?)? I googled a bit and found nothing at all about how to >disable excessive harvesting. > ># sysctl -a | grep harvest >kern.random.sys.harvest.ethernet: 1 >kern.random.sys.harvest.point_to_point: 1 >kern.random.sys.harvest.interrupt: 1 >kern.random.sys.harvest.swi: 0 > >These are the knobs I know about. Is it enough to turn >kern.random.sys.harvest.ethernet and kern.random.sys.harvest.interrupt to 0, >or are there other things I need to do too? > >/Daniel Eriksson > > That is what I did. I have not bench marked, but I did allot of searching on the web and reading man pages. I just can't make the changes permanent. When I put them in loader.conf they seem to be ignored. Any suggestions to make it stick? Jason From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 02:05: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 9C37A16A4CE for ; Fri, 10 Sep 2004 02:05:22 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A5E943D53 for ; Fri, 10 Sep 2004 02:05:22 +0000 (GMT) (envelope-from rob@pythonemproject.com) Received: from pythonemproject.com (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (rwcrmhc12) with ESMTP id <2004091002051901400mg212e> (Authid: europax); Fri, 10 Sep 2004 02:05:19 +0000 Message-ID: <41410C1E.1080204@pythonemproject.com> Date: Thu, 09 Sep 2004 19:06:22 -0700 From: Rob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------050303010106000409070301" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Mergemaster X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rob@pythonemproject.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, 10 Sep 2004 02:05:22 -0000 This is a multi-part message in MIME format. --------------050303010106000409070301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------050303010106000409070301 Content-Type: message/rfc822; name="(null).eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="(null).eml" Received: from pythonemproject.com (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (rwcrmhc11) with ESMTP id <200409100200370130056k3fe> (Authid: europax); Fri, 10 Sep 2004 02:00:37 +0000 Message-ID: <41410B03.6030908@pythonemproject.com> Date: Thu, 09 Sep 2004 19:01:39 -0700 From: Rob Reply-To: rob@pythonemproject.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew J Caines Subject: Re: Still getting warning messages for rc.conf & default/rc.conf entries References: <4140AFB0.6020002@pythonemproject.com> <4140C687.3080406@linuxpowered.com> <4140C9A7.9020407@pythonemproject.com> <20040910012819.GH23872@hal9000.halplant.com> In-Reply-To: <20040910012819.GH23872@hal9000.halplant.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew J Caines wrote: >Rob, > > > >>I will probably recompile the whole system. >> >> > >Waste of time and of no relevance to the problem. If you want to do >something again to ensure currency, remove and cvsup your sources. > > > >>Have only used mergemaser once, and somehow everything became a mess. >> >> > >Having used it many times in many situations since before it was part of >the system and given the lack of any avalanch of reports on the lists, I'm >quite confident you messed it up and that mergmaster works very well. > > > >>Now I just compare timestamps and do it manually. >> >> > >You are certainly missing some steps which mergmaster handles. > >No comment on recompiling /etc/rc. > >I suggest following my earlier advice and running mergmaster. > > >-Andrew- > > For now there's nothing to merge with.. First impressions are generally the most important. Would use it if I had some test bed to figure out what the hell I'm doing. I found the program unintuitive and cryptic. Maybe I need a manual next to me if I try it. Like i said, this was a binary iso build, so there was no possibility of merging anything. I just rely on the skill of the release people to do a good job on the iso. one thiing I found about burning iso's, you should do a complete erase of the CD,, a quick erase many times wont work. Thanks for the advice Rob --------------050303010106000409070301-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 03:02: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 9640516A4CE; Fri, 10 Sep 2004 03:02:06 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 872BC43D3F; Fri, 10 Sep 2004 03:02:02 +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 i8A2xeph032545; Thu, 9 Sep 2004 22:59:40 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8A2xdG2032542; Thu, 9 Sep 2004 22:59:40 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 9 Sep 2004 22:59:39 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: jason In-Reply-To: <4141034C.1080700@ec.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eriksson cc: current@freebsd.org Subject: Re: FreeBSD 5.3 Bridge performance take II 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, 10 Sep 2004 03:02:06 -0000 On Thu, 9 Sep 2004, jason wrote: > >>If you're not already disabling harvesting of entropy on interrupts and > >>in network processing, you really want to for performance purposes. > >> > > > >How do I disable this without causing entropy starvation for "typical" use > >cases (ssl? ssh?)? I googled a bit and found nothing at all about how to > >disable excessive harvesting. > > > ># sysctl -a | grep harvest > >kern.random.sys.harvest.ethernet: 1 > >kern.random.sys.harvest.point_to_point: 1 > >kern.random.sys.harvest.interrupt: 1 > >kern.random.sys.harvest.swi: 0 > > > >These are the knobs I know about. Is it enough to turn > >kern.random.sys.harvest.ethernet and kern.random.sys.harvest.interrupt to 0, > >or are there other things I need to do too? I'd set kern.random.sys.harvest.ethernet to 0 because the incremental benefits beyond harvesting the interrupt are pretty low. > That is what I did. I have not bench marked, but I did allot of > searching on the web and reading man pages. I just can't make the > changes permanent. When I put them in loader.conf they seem to be > ignored. Any suggestions to make it stick? I've CC'd markm because he's probably interested -- right now, you have to set it in /etc/sysctl.conf because a tunable is not defined. I think it would be a good idea to make them tunable, however, as well. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 03:02: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 557E516A4CE; Fri, 10 Sep 2004 03:02:30 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA8343D53; Fri, 10 Sep 2004 03:02:30 +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 i8A2sQT6007945; Thu, 9 Sep 2004 19:54:26 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8A2sQkB007944; Thu, 9 Sep 2004 19:54:26 -0700 Date: Thu, 9 Sep 2004 19:54:26 -0700 From: Brooks Davis To: jason Message-ID: <20040910025425.GA7425@odin.ac.hmc.edu> References: <4141034C.1080700@ec.rr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <4141034C.1080700@ec.rr.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: 'Robert Watson' cc: Daniel Eriksson cc: current@freebsd.org Subject: Re: FreeBSD 5.3 Bridge performance take II 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, 10 Sep 2004 03:02:30 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2004 at 09:28:44PM -0400, jason wrote: > Daniel Eriksson wrote: >=20 > >Robert Watson wrote: > > > >=20 > > > >>If you're not already disabling harvesting of entropy on interrupts and > >>in network processing, you really want to for performance purposes. > >> =20 > >> > > > >How do I disable this without causing entropy starvation for "typical" u= se > >cases (ssl? ssh?)? I googled a bit and found nothing at all about how to > >disable excessive harvesting. > > > ># sysctl -a | grep harvest > >kern.random.sys.harvest.ethernet: 1 > >kern.random.sys.harvest.point_to_point: 1 > >kern.random.sys.harvest.interrupt: 1 > >kern.random.sys.harvest.swi: 0 > > > >These are the knobs I know about. Is it enough to turn > >kern.random.sys.harvest.ethernet and kern.random.sys.harvest.interrupt t= o=20 > >0, > >or are there other things I need to do too? > > > >/Daniel Eriksson > >=20 > > > That is what I did. I have not bench marked, but I did allot of=20 > searching on the web and reading man pages. I just can't make the=20 > changes permanent. When I put them in loader.conf they seem to be=20 > ignored. Any suggestions to make it stick? The values are set in the /etc/rc.d/initrandom script. Add the following to your rc.conf to diable interrupt and ethernet entropy gathering: harvest_interrupt=3D"NO" harvest_ethernet=3D"NO" -- 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 --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQRdhXY6L6fI4GtQRAm/kAJ4/nv2oxYZ3fed5tBOSAQDUUuzMygCgmO6G 950y8iCJoQivbGYhFmRPIBA= =leDa -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 03:29: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 B299C16A4CF for ; Fri, 10 Sep 2004 03:29:51 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8462E43D45 for ; Fri, 10 Sep 2004 03:29:51 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 6209 invoked from network); 10 Sep 2004 03:29:50 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 03:29:50 -0000 Received: from hydrogen.funkthat.com (ixgpkd@localhost.funkthat.com [127.0.0.1])i8A3TouU095621; Thu, 9 Sep 2004 20:29:50 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8A3TnIj095620; Thu, 9 Sep 2004 20:29:49 -0700 (PDT) Date: Thu, 9 Sep 2004 20:29:49 -0700 From: John-Mark Gurney To: Jun Kuriyama Message-ID: <20040910032948.GO72089@funkthat.com> Mail-Followup-To: Jun Kuriyama , Current References: <7mhdq7sdvn.wl@black.imgsrc.co.jp> <20040909180557.GM72089@funkthat.com> <7msm9roulo.wl@black.imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7msm9roulo.wl@black.imgsrc.co.jp> 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: Current Subject: Re: panic: mutex Giant not owned 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: Fri, 10 Sep 2004 03:29:51 -0000 Jun Kuriyama wrote this message on Fri, Sep 10, 2004 at 09:06 +0900: > At Thu, 9 Sep 2004 11:05:57 -0700, > John-Mark Gurney wrote: > > > panic: mutex Giant not owned at /usr/src/sys/kern/kern_event.c:1334 > > > > Just remove the GIANT_REQUIRED; line on 1334, and try again... If this > > works for you, I'll commit the fix... > > I tested without this line, and it seems fine! Thanks! Thanks, patch committed. -- 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 Fri Sep 10 04:03: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 DF85716A4CE for ; Fri, 10 Sep 2004 04:03:07 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF8843D5C for ; Fri, 10 Sep 2004 04:03:07 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5cct-000BP6-3y; Fri, 10 Sep 2004 04:03:07 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.42 (FreeBSD)) id 1C5ccr-0000ss-Aj; Thu, 09 Sep 2004 18:03:05 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16705.10104.272584.474462@roam.psg.com> Date: Thu, 9 Sep 2004 18:03:04 -1000 To: George Hartzell References: <16701.23928.267840.215410@roam.psg.com> <16704.52415.291907.332939@rosebud.alerce.com> cc: freebsd-current@freebsd.org Subject: Re: t40 hints, ctls, and loads 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, 10 Sep 2004 04:03:08 -0000 > Anything interesting to say about suspend/hibernate/acpi etc? well, with the settings i posted, except mouse config corrected to 0x2200, o suspends and resumes pretty well, even multiple times, except o i need to restart moused manually randy From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 04:43: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 CB34E16A4CE for ; Fri, 10 Sep 2004 04:43:18 +0000 (GMT) Received: from mail.omut.org (mail.omut.org [216.218.215.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9956443D1F for ; Fri, 10 Sep 2004 04:43:18 +0000 (GMT) (envelope-from lxv@omut.org) Received: from tadpole.intranet (mix-anchor.intranet [10.10.10.251]) by mail.omut.org (8.13.1/8.13.1) with ESMTP id i8A4hG1K014353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Sep 2004 21:43:17 -0700 (PDT) (envelope-from lxv@omut.org) Received: from tadpole.intranet (localhost [127.0.0.1]) by tadpole.intranet (8.13.1/8.13.1) with ESMTP id i8A4hAjh000795 for ; Fri, 10 Sep 2004 00:43:10 -0400 (EDT) (envelope-from lxv@tadpole.intranet) Received: (from lxv@localhost) by tadpole.intranet (8.13.1/8.13.1/Submit) id i8A4h5TR000794 for current@freebsd.org; Fri, 10 Sep 2004 00:43:05 -0400 (EDT) (envelope-from lxv) Date: Fri, 10 Sep 2004 00:43:05 -0400 From: Alex Vasylenko To: current@freebsd.org Message-ID: <20040910044302.GA719@tadpole.intranet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.44 Subject: panic: deadlock in setrunqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alex Vasylenko List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 04:43:18 -0000 FreeBSD 5.3-BETA3 #15: Thu Sep 9 22:31:08 EDT 2004 scheduler: 4bsd+preemption on i386/smp invariants, witness: off # kgdb -c vmcore.2 /usr/obj/usr/src/sys/GENERIC-S/kernel.debug [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". doadump () at pcpu.h:159 (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc0529c51 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc052a073 in panic (fmt=0xc06d793e "deadlock in setrunqueue") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc053ed04 in setrunqueue (td=0xc19df4b0, flags=0) at kern_switch.c:386 #4 0xc053e3b7 in sched_wakeup (td=0xc19df4b0) at /usr/src/sys/kern/sched_4bsd.c:804 #5 0xc05325be in setrunnable (td=0x0) at /usr/src/sys/kern/kern_synch.c:402 #6 0xc054eec0 in sleepq_resume_thread (td=0xc19df4b0, pri=-1) at /usr/src/sys/kern/subr_sleepqueue.c:646 #7 0xc054f358 in sleepq_remove (td=0xc19df4b0, wchan=0xc173a270) at /usr/src/sys/kern/subr_sleepqueue.c:818 #8 0xc05129a5 in kse_wakeup (td=0xc25e8c80, uap=0xc19df4b0) at /usr/src/sys/kern/kern_kse.c:486 #9 0xc0698f80 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 135364608, tf_esi = 135431824, tf_ebp = -1079059232, tf_isp = -700572300, tf_ebx = 681208156, tf_edx = 135364608, tf_ecx = 135431824, tf_eax = 380, tf_trapno = 22, tf_err = 2, tf_eip = 681192475, tf_cs = 31, tf_eflags = 518, tf_esp = -1079059276, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1001 #10 0xc068399f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 more details in http://www.omut.org/~lxv/log4 From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 04:52: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 BE5C416A4CE for ; Fri, 10 Sep 2004 04:52:29 +0000 (GMT) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3EEA43D1F for ; Fri, 10 Sep 2004 04:52:28 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1C5dPG-0000H7-Dr; Fri, 10 Sep 2004 08:53:06 +0400 Date: Fri, 10 Sep 2004 08:53:06 +0400 From: "Boris B. Samorodov" To: Martin Message-ID: <20040910045306.GA1037@ipt.ru> References: <1094765463.754.1.camel@klotz.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094765463.754.1.camel@klotz.local> Sender: "Boris B. Samorodov" cc: FreeBSD Current Subject: Re: Interrupt storm detected on "irq7: lpt0" 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, 10 Sep 2004 04:52:29 -0000 Hi! On Thu, Sep 09, 2004 at 11:32:02PM +0200, Martin wrote: > > Hi, > > I have this problem already for a longer time. > > After I've sent a print-job to lpr, the system > says: > > Interrupt storm detected on "irq7: lpt0"; throttling interrupt source > > The worst about it is that the printer is very slow. > It needs an hour to print a page of paper. > It prints one single line in usual speed and then stops > for about a minute. > > The hardware is OK. I've checked it. > > I'm using > 5.3-BETA3 FreeBSD 5.3-BETA3 #0: Wed Sep 8 18:33:17 CEST 2004 > ghostscript-afpl-8.14_6,1 > Epson Stylus COLOR We had a similar problem with multiport network adapter. Adding SMP capabilities to the kernel (but we have only one processor) cured the problem. OS: FreeBSD-5.3-BETA3. > a piece of dmesg: > ppc0 port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > > > Is printing on lpt working at all on -CURRENT? > > Martin > > > _______________________________________________ > 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" WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 04:54: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 01FEE16A4CE for ; Fri, 10 Sep 2004 04:54:20 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D153843D1F for ; Fri, 10 Sep 2004 04:54:19 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i8A4sJOv065984; Thu, 9 Sep 2004 21:54:19 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i8A4sJ5n065983; Thu, 9 Sep 2004 21:54:19 -0700 (PDT) (envelope-from sgk) Date: Thu, 9 Sep 2004 21:54:19 -0700 From: Steve Kargl To: Rob Message-ID: <20040910045419.GA65654@troutmask.apl.washington.edu> References: <41410C1E.1080204@pythonemproject.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41410C1E.1080204@pythonemproject.com> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: Mergemaster 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, 10 Sep 2004 04:54:20 -0000 On Thu, Sep 09, 2004 at 07:06:22PM -0700, Rob wrote: > > For now there's nothing to merge with.. > What gives you the idea there is nothing to merge? With what you have posted in other threads (which is quite annoying, can't you simply post to a single thread?) Your /etc/rc script are probable screwed up. Mergemaster will find this, but you need a populated /usr/src/etc/. > First impressions are generally > the most important. Would use it if I had some test bed to figure out > what the hell I'm doing. I found the program unintuitive and cryptic. > Maybe I need a manual next to me if I try it. man mergemaster > I just rely on the skill of the release people to do a good job on the > iso. AFIAK, your problems have nothing to do with the skill of the release people. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 05:48: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 9977816A4CE for ; Fri, 10 Sep 2004 05:48:05 +0000 (GMT) Received: from kestrel.alerce.com (kestrel.alerce.com [209.182.219.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B1D243D3F for ; Fri, 10 Sep 2004 05:48:05 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from rosebud.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (authenticated bits=128) by kestrel.alerce.com (8.12.10/8.12.10) with ESMTP id i8A5m0kk022639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Sep 2004 22:48:01 -0700 (PDT) (envelope-from hartzell@kestrel.alerce.com) Received: from rosebud.alerce.com (localhost [127.0.0.1]) by rosebud.alerce.com (8.12.9p2/8.12.9) with ESMTP id i8A5mewg006634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 22:48:40 -0700 (PDT) (envelope-from hartzell@rosebud.alerce.com) Received: (from hartzell@localhost) by rosebud.alerce.com (8.12.9p2/8.12.9/Submit) id i8A5mccR006630; Thu, 9 Sep 2004 22:48:38 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16705.16437.481491.160457@rosebud.alerce.com> Date: Thu, 9 Sep 2004 22:48:37 -0700 To: Randy Bush In-Reply-To: <16705.10104.272584.474462@roam.psg.com> References: <16701.23928.267840.215410@roam.psg.com> <16704.52415.291907.332939@rosebud.alerce.com> <16705.10104.272584.474462@roam.psg.com> X-Mailer: VM 7.14 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-current@freebsd.org Subject: Re: t40 hints, ctls, and loads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@kestrel.alerce.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, 10 Sep 2004 05:48:05 -0000 Randy Bush writes: > > Anything interesting to say about suspend/hibernate/acpi etc? > > well, with the settings i posted, except mouse config corrected > to 0x2200, > o suspends and resumes pretty well, even multiple times, except > o i need to restart moused manually Try setting hint.psm.0.flags="0x6000" and give it about 5-10 seconds after you resume. Seems to work for me. g. From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 06:06: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 628E116A4CE; Fri, 10 Sep 2004 06:06:21 +0000 (GMT) Received: from spxau01.smeglobalnet.net (spxau01.smeglobalnet.net [203.57.65.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AC0243D4C; Fri, 10 Sep 2004 06:06:20 +0000 (GMT) (envelope-from andy@bradfieldprichard.com.au) Received: from bpgate.speednet.com.au ([203.41.15.9]) by spxau01.smeglobalnet.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Sep 2004 15:26:33 +1000 Received: from bpgate.speednet.com.au (localhost [127.0.0.1]) i8A5QWMG021456; Fri, 10 Sep 2004 15:26:33 +1000 (EST) (envelope-from andy@bradfieldprichard.com.au) Received: from localhost (andy@localhost)i8A5QVY7021453; Fri, 10 Sep 2004 15:26:32 +1000 (EST) (envelope-from andy@bradfieldprichard.com.au) X-Authentication-Warning: bpgate.speednet.com.au: andy owned process doing -bs Date: Fri, 10 Sep 2004 15:26:31 +1000 (EST) From: Andy Farkas X-X-Sender: andy@bpgate.speednet.com.au To: John Baldwin In-Reply-To: <200409091347.19431.jhb@FreeBSD.org> Message-ID: <20040910151513.M21251@bpgate.speednet.com.au> References: <20040909023413.T14321@bpgate.speednet.com.au> <200409091347.19431.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Sep 2004 05:26:34.0100 (UTC) FILETIME=[BC732340:01C496F6] cc: freebsd-current@FreeBSD.org Subject: Re: panic: APIC: Previous IPI is stuck 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, 10 Sep 2004 06:06:21 -0000 On Thu, 9 Sep 2004, John Baldwin wrote: > On Wednesday 08 September 2004 12:39 pm, Andy Farkas wrote: >> My box is still crashing with above APIC panic when I do a >> make -j4 buildworld. >> >> In file src/sys/i386/i386/local_apic.c I tried increasing >> BEFORE_SPIN to 100000000 but it still panics. >> >> Any suggestions on why this is happenning? > > Try changing the consant to -1. Note that I apparently just managed to > trigger a hard lockup on my test machine here with that change, but it had > managed to run for about 20 hours under heavy load that panic'd in a few > hours on a stock kernel. > >> FreeBSD 5.3-BETA3 #1: Wed Sep 8 00:37:07 EST 2004 I changed it to -1. Now I get a hard lockup. I assume its spinning inside lapic_ipi_wait(). FYI: the box is a *slow* 200MHz quad Pentium-Pro. I mention this because the IPI patches posted a couple weeks ago mention fixing fast CPUs... Also, "this never used to happen before." (instability started late August) -andyf From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 06:15: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 9574916A4CE for ; Fri, 10 Sep 2004 06:15:28 +0000 (GMT) Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DA7D43D5A for ; Fri, 10 Sep 2004 06:15:28 +0000 (GMT) (envelope-from nakal@web.de) Received: from [217.81.254.60] (helo=[217.81.254.60]) by smtp06.web.de with esmtp (TLSv1:DES-CBC3-SHA:168) (WEB.DE 4.101 #44) id 1C5efw-0002Da-00; Fri, 10 Sep 2004 08:14:25 +0200 From: Martin To: "Boris B. Samorodov" In-Reply-To: <20040910045306.GA1037@ipt.ru> References: <1094765463.754.1.camel@klotz.local> <20040910045306.GA1037@ipt.ru> Content-Type: text/plain Message-Id: <1094796862.782.6.camel@klotz.local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 08:14:23 +0200 Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de cc: FreeBSD Current Subject: Re: Interrupt storm detected on "irq7: lpt0" 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, 10 Sep 2004 06:15:28 -0000 Am Fr, den 10.09.2004 schrieb Boris B. Samorodov um 6:53: > We had a similar problem with multiport network adapter. > Adding SMP capabilities to the kernel (but we have only > one processor) cured the problem. > > OS: FreeBSD-5.3-BETA3. My kernel doesn't have SMP compiled in. Martin From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 06:37: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 5344C16A4CE for ; Fri, 10 Sep 2004 06:37:53 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B9F343D39 for ; Fri, 10 Sep 2004 06:37:52 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id i8A6boEg053627; Fri, 10 Sep 2004 08:37:50 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <41414BC0.40009@withagen.nl> Date: Fri, 10 Sep 2004 08:37:52 +0200 From: Willem Jan Withagen 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: Martin References: <1094765463.754.1.camel@klotz.local> <20040910045306.GA1037@ipt.ru> <1094796862.782.6.camel@klotz.local> In-Reply-To: <1094796862.782.6.camel@klotz.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: "Boris B. Samorodov" cc: FreeBSD Current Subject: Re: Interrupt storm detected on "irq7: lpt0" 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, 10 Sep 2004 06:37:53 -0000 I've uped the limit for what the max of interrupts could be.... In /etc/sysctl.conf hw.intr_storm_threshold=20000 Bit I've seen my lpt intr go as high as 60.000 --WjW Martin wrote: >Am Fr, den 10.09.2004 schrieb Boris B. Samorodov um 6:53: > > > >>We had a similar problem with multiport network adapter. >>Adding SMP capabilities to the kernel (but we have only >>one processor) cured the problem. >> >>OS: FreeBSD-5.3-BETA3. >> >> > >My kernel doesn't have SMP compiled in. > >Martin > > >_______________________________________________ >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 Sep 10 06:41: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 BA2A416A4CE; Fri, 10 Sep 2004 06:41:30 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EA7C43D49; Fri, 10 Sep 2004 06:41:28 +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 i8A6fRYL074510; Fri, 10 Sep 2004 02:41:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8A6fREg068848; Fri, 10 Sep 2004 02:41:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9C9C37303F; Fri, 10 Sep 2004 02:41:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040910064127.9C9C37303F@freebsd-current.sentex.ca> Date: Fri, 10 Sep 2004 02:41:27 -0400 (EDT) Subject: [releng_5 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: Fri, 10 Sep 2004 06:41:30 -0000 TB --- 2004-09-10 04:54:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-10 04:54:54 - starting RELENG_5 tinderbox run for ia64/ia64 TB --- 2004-09-10 04:54:54 - checking out the source tree TB --- 2004-09-10 04:54:54 - cd /home/tinderbox/RELENG_5/ia64/ia64 TB --- 2004-09-10 04:54:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-10 05:17:51 - building world (CFLAGS=-O -pipe) TB --- 2004-09-10 05:17:51 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-10 05:17:51 - /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-09-10 06:21:33 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-10 06:21:33 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-10 06:21:33 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 10 06:21:33 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 >>> Kernel build for GENERIC completed on Fri Sep 10 06:34:35 UTC 2004 TB --- 2004-09-10 06:34:35 - generating LINT kernel config TB --- 2004-09-10 06:34:35 - cd /home/tinderbox/RELENG_5/ia64/ia64/src/sys/ia64/conf TB --- 2004-09-10 06:34:35 - /usr/bin/make -B LINT TB --- 2004-09-10 06:34:35 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-10 06:34:35 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-10 06:34:35 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 10 06:34:35 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 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/gate/g_gate.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_iso9660.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_msdosfs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_ufs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2483: warning: 'sc' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/obj/ia64/tinderbox/RELENG_5/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. TB --- 2004-09-10 06:41:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-10 06:41:27 - ERROR: failed to build lint kernel TB --- 2004-09-10 06:41:27 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 06:54: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 AFEA216A4CE; Fri, 10 Sep 2004 06:54: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 CC32E43D45; Fri, 10 Sep 2004 06:54:33 +0000 (GMT) (envelope-from ru@ip.net.ua) 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 i8A6sRkJ032165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 09:54:29 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8A6sS39058962; Fri, 10 Sep 2004 09:54:28 +0300 (EEST) (envelope-from ru) Date: Fri, 10 Sep 2004 09:54:27 +0300 From: Ruslan Ermilov To: "David O'Brien" , FreeBSD Tinderbox Message-ID: <20040910065427.GA42906@ip.net.ua> References: <20040909220741.D550D7303F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20040909220741.D550D7303F@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: powerpc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: [current tinderbox] failure on powerpc/powerpc 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, 10 Sep 2004 06:54:34 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable David, I went ahead and committed my fix that I sent you last night (my local time) because your change broke the PPC build -- the reason is that SRCS for "powerpc" has the .asm file that was not stripped by the ${.ALLSRC:N*.h}, breaking the compile command. I called a new fix "non-intrusive" because putting *.h's in BEGINSRC and ENDSRC wasn't probably a good idea, and made things harder to understand. I hope you're happy with the new fix. Good catch, by the way! ;) On Thu, Sep 09, 2004 at 06:07:41PM -0400, FreeBSD Tinderbox wrote: > TB --- 2004-09-09 21:52:11 - tinderbox 2.3 running on freebsd-current.sen= tex.ca > TB --- 2004-09-09 21:52:11 - starting CURRENT tinderbox run for powerpc/p= owerpc > TB --- 2004-09-09 21:52:11 - checking out the source tree > TB --- 2004-09-09 21:52:11 - cd /home/tinderbox/CURRENT/powerpc/powerpc > TB --- 2004-09-09 21:52:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -P= d -A src > TB --- 2004-09-09 21:57:18 - building world (CFLAGS=3D-O2 -pipe) > TB --- 2004-09-09 21:57:18 - cd /home/tinderbox/CURRENT/powerpc/powerpc/s= rc > TB --- 2004-09-09 21:57:18 - /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 > [...] > cc: /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/g= cc/config/rs6000/crtsavres.asm: linker input file unused because linking no= t done > In file included from ./tm.h:10, > from /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/= =2E./../../contrib/gcc/crtstuff.c:64: > /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/c= onfig/rs6000/sysv4.h:24:1: warning: "NO_IMPLICIT_EXTERN_C" redefined > In file included from ./tm.h:9, > from /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/= =2E./../../contrib/gcc/crtstuff.c:64: > /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/c= onfig/freebsd.h:69:1: warning: this is the location of the previous definit= ion > /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu/../../../contrib/gcc/c= onfig/rs6000/crtsavres.asm:40: error: syntax error before '.' token > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/powerpc/powerpc/src/gnu/lib/csu. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/powerpc/powerpc/src. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/powerpc/powerpc/src. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/powerpc/powerpc/src. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/powerpc/powerpc/src. > TB --- 2004-09-09 22:07:41 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2004-09-09 22:07:41 - ERROR: failed to build world > TB --- 2004-09-09 22:07:41 - tinderbox aborted >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBQU+jqRfpzJluFF4RAqBRAKCXClRnTK9wb+7nat5zTDN0zQKsMACeLWng fExtbXQbHYgN7BLNnDuMVUk= =HVee -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 06:57: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 69EDD16A4CE; Fri, 10 Sep 2004 06:57:25 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1775343D48; Fri, 10 Sep 2004 06:57:25 +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 i8A6vO7F040447; Fri, 10 Sep 2004 02:57:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8A6vOlP047704; Fri, 10 Sep 2004 02:57:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 45CE67303F; Fri, 10 Sep 2004 02:57:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040910065724.45CE67303F@freebsd-current.sentex.ca> Date: Fri, 10 Sep 2004 02:57:24 -0400 (EDT) Subject: [releng_5 tinderbox] failure on powerpc/powerpc 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, 10 Sep 2004 06:57:25 -0000 TB --- 2004-09-10 06:41:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-10 06:41:27 - starting RELENG_5 tinderbox run for powerpc/powerpc TB --- 2004-09-10 06:41:27 - checking out the source tree TB --- 2004-09-10 06:41:27 - cd /home/tinderbox/RELENG_5/powerpc/powerpc TB --- 2004-09-10 06:41:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-10 06:49:12 - building world (CFLAGS=-O -pipe) TB --- 2004-09-10 06:49:12 - cd /home/tinderbox/RELENG_5/powerpc/powerpc/src TB --- 2004-09-10 06:49:12 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REP.c -o asn1_TGS_REP.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REQ.c -o asn1_TGS_REQ.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_Ticket.c -o asn1_Ticket.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TicketFlags.c -o asn1_TicketFlags.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TransitedEncoding.c -o asn1_TransitedEncoding.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_UNSIGNED.c -o asn1_UNSIGNED.So building shared library libasn1.so.7 Abort trap (core dumped) *** Error code 134 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. TB --- 2004-09-10 06:57:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-10 06:57:24 - ERROR: failed to build world TB --- 2004-09-10 06:57:24 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 07:40: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 0739D16A4CE; Fri, 10 Sep 2004 07:40:45 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1032543D45; Fri, 10 Sep 2004 07:40:44 +0000 (GMT) (envelope-from scottl@pooker.samsco.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8A7fKrM016557; Fri, 10 Sep 2004 01:41:20 -0600 (MDT) (envelope-from scottl@pooker.samsco.org) Received: (from scottl@localhost) by pooker.samsco.org (8.12.11/8.12.10/Submit) id i8A7fGIO016556; Fri, 10 Sep 2004 01:41:16 -0600 (MDT) (envelope-from scottl) Date: Fri, 10 Sep 2004 01:41:16 -0600 (MDT) Message-Id: <200409100741.i8A7fGIO016556@pooker.samsco.org> From: Scott Long To: current@FreeBSD.org X-Spam-Status: No, hits=0.6 required=3.8 tests=SUBJ_ALL_CAPS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org Subject: 5.3-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: re@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 07:40:45 -0000 This is an automated weekly mailing of the FreeBSD 5.3 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.3R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.3 FreeBSD 5.3 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.3. If you have any updates for this list, please e-mail re@FreeBSD.org. Show stopper defects for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |--------------------+-------------+-------------+-----------------------| | | | | PREEMPTION appears to | | | | | increase the chances | | | | | of triggering a race | | | | | condition in the | | | | | thread context | | PREEMPTION-related | | Scott Long, | management and | | hangs involving | In progress | Julian | scheduling code. | | threads | | Elischer | Patches to mitigate | | | | | the problem have been | | | | | developed, with | | | | | on-going work to come | | | | | up with the correct | | | | | solution prior to | | | | | 5.3. | |--------------------+-------------+-------------+-----------------------| | | | | Jun Kuriyama has | | | | | reported problems | | | | | with NFS over IPv6 | | | | | not functioning | | | | | correctly as of the | | | | | improved NFS support | | | | | for disconnection | | NFS over IPv6 | | | changes. Doug White | | problems | In progress | Doug White | has tracked down the | | | | | source of the problem | | | | | (EMSGSIZE being | | | | | returned by IPv6 UDP | | | | | send routine due to | | | | | fragmentation), and | | | | | is currently | | | | | exploring possible | | | | | fixes. | |--------------------+-------------+-------------+-----------------------| | | | | There are reports of | | | | | applications wedging | | | | | in poll() and | | | | | select() while | | | | | running the network | | | | | stack without the | | | | | Giant lock. A recent | | | | | sleepq change appears | | | | | to have caused some | | poll()/select() | | | of the observed | | application wedge | | Robert | problems to go away | | reports with | In progress | Watson | (others are difficult | | debug.mpsafenet=1 | | | to test for due to | | | | | recent SMP | | | | | instability). | | | | | uipc_socket.c:1.211 | | | | | appears to correct | | | | | this race in the CVS | | | | | HEAD (6.x), but the | | | | | fix is currently in a | | | | | waiting period to be | | | | | merged back to | | | | | RELENG_5. | |--------------------+-------------+-------------+-----------------------| | | | | ether_input() calls | | | | | random_harvest() on | | | | | the mbuf after it has | | | | | been handed off to | | | | | ether_demux(), at | | ether_input() may | | | which point it may | | harvest entropy | In progress | Mark Murray | have been free()'d | | from free()'d mbuf | | | back to the mbuf | | | | | allocator. It also | | | | | passes in a pointer | | | | | to the mbuf itself, | | | | | rather than ethernet | | | | | frame header. | |--------------------+-------------+-------------+-----------------------| | | | | Kris Kennaway has | | | | | reported problems | | | | | with boot time | | | | | panic's, mutex Giant | | boot time panic | Not done | - | not owned at | | | | | kern/vfs_subr.c:1365. | | | | | See "Re: 5.3-RELEASE | | | | | TODO" thread in | | | | | -current@. | +------------------------------------------------------------------------+ Required features for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-----------------+-------------+--------------+-------------------------| | BIND9 import | In progress | Doug Barton | BIND9 must be imported | | into 5-CURRENT | | | for 5.3-RELEASE. | |-----------------+-------------+--------------+-------------------------| | | | | Kernel bits | | KSE support for | | | implemented, userland | | sparc64 | -- | -- | not implemented. | | | | | Required for | | | | | 5.3-RELEASE. | |-----------------+-------------+--------------+-------------------------| | | | | With improved support | | | | | for threading | | | | | primitives, support is | | | | David Xu, | now required to ease | | GDB thread | In progress | Marcel | debugging of threaded | | support | | Moolenaar | applications. Ideally, | | | | | this support will work | | | | | for both libthr and | | | | | libkse threading | | | | | models. | |-----------------+-------------+--------------+-------------------------| | | | | Currently, two | | | | | schedulers are present: | | | | | SCHED_ULE (default), an | | | | | SMP-optimized scheduler | | | | | created as part of | | | | | SMPng, and SCHED_4BSD, | | | | | an SMP-adapted version | | | | | of the original 4BSD | | | | | scheduler. They have | | | | | quite different | | | | | performance properties, | | | | | with ULE providing | | | | | strong interactivity | | | | | characteristics, and | | Scheduler | | | performing quite well | | cleanup and | In progress | -- | in a number of | | resolution | | | benchmarks, and 4BSD | | | | | showing greater | | | | | strength in IPC | | | | | intensive user space | | | | | benchmarks, such as | | | | | databases. One of these | | | | | schedulers must be the | | | | | default for 5.3, and | | | | | whichever one it is, it | | | | | requires careful | | | | | measurement, analysis, | | | | | and optimization before | | | | | the release in order to | | | | | address its | | | | | deficiencies. | |-----------------+-------------+--------------+-------------------------| | | | | There have been several | | | | | reports that growfs(8) | | | | | works improperly with | | Reports of UFS2 | | | large disk sizes, and | | "large disk" | In progress | Scott Long | other size-related nits | | problems | | | in the current disk and | | | | | label management tool | | | | | set. These must be | | | | | resolved for | | | | | 5.3-RELEASE. | |-----------------+-------------+--------------+-------------------------| | | | | Synaptics updates to | | Synaptics | | | the psm(4) driver have | | touchpad | In progress | Philip Paeps | resulted in poor | | problems | | | interactivity for taps | | | | | and button press events | | | | | for some users. | |-----------------+-------------+--------------+-------------------------| | | | | Entropy harvesting in | | | | | the interrupt and | | | | | incoming packet paths | | | | | currently involves a | | | | | large number of mutex | | | | | operations. In order to | | | | | improve performance, it | | Entropy | | Robert | is desirable to reduce | | harvesting | In progress | Watson, | the number of mutex | | optimizations | | Mark Murray | operations | | | | | substantially. Work is | | | | | in progress to improve | | | | | the harvesting code | | | | | along these lines, but | | | | | has not yet been | | | | | properly measured, and | | | | | therefore not yet | | | | | merged to CVS. | +------------------------------------------------------------------------+ Desired features for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |------------------+-------------+----------------+----------------------| | | | | Almost all process | | | | | debugging tools have | | | | | been updated to use | | | | | non-procfs kernel | | | | | primitives, with the | | | | | exception of | | | | | truss(1). As procfs | | | | | is considered | | | | | deprecated due to | | | | | its inherent | | | | | security risks, it | | truss support | | | is highly desirable | | for ptrace | -- | -- | to update truss to | | | | | operate in a | | | | | post-procfs world. | | | | | Dag-Erling Smorgrav | | | | | had prototype | | | | | patches; | | | | | Robert Drehmel is | | | | | developing and | | | | | testing patches now. | | | | | Support for system | | | | | call tracing has | | | | | been added to | | | | | ptrace(). | |------------------+-------------+----------------+----------------------| | | | | FAST_IPSEC currently | | | | | cannot be used | | | | | directly with the | | | | | KAME IPv6 | | | | | implementation, | | | | | requiring an | | | | | additional level of | | | | | IP tunnel | | | | | indirection to | | | | | protect IPv6 packets | | FAST_IPSEC and | | | when using hardware | | KAME | Not done | -- | crypto acceleration. | | compatibility | | | This issue must be | | | | | resolved so that the | | | | | two services may | | | | | more easily be used | | | | | together. Among | | | | | other things, this | | | | | will require a | | | | | careful review of | | | | | the handling of mbuf | | | | | header copying and | | | | | m_tag support in the | | | | | KAME IPv6 code. | |------------------+-------------+----------------+----------------------| | | | | A process cannot be | | | | | interrupted while | | | | | waiting on a lock. | | rpc.lockd(8) | | | Fixing this requires | | stability | -- | -- | that the RPC code be | | | | | taught how to deal | | | | | with lock | | | | | cancellation and | | | | | interruption events. | |------------------+-------------+----------------+----------------------| | | | | Kernel modules are | | | | | currently built | | | | | independently from a | | | | | kernel | | | | | configuration, and | | | | | independently from | | | | | one another, | | | | | resulting in | | | | | substantially | | | | | redundant | | | | | compilation of | | | | | objects, as well as | | | | | the inability to | | | | | easily manage | | | | | compile-time options | | Revised kld | | | for kernel objects | | build | Not done | Peter Wemm | (such as MAC, PAE, | | infrastructure | | | etc) that may | | | | | require conditional | | | | | compilation in the | | | | | kernel modules. In | | | | | order to improve | | | | | build performance | | | | | and better support | | | | | options of this | | | | | sort, the KLD build | | | | | infrastructure needs | | | | | to be revamped. | | | | | Peter Wemm has done | | | | | some initial | | | | | prototyping, and | | | | | should be contacted | | | | | before starting on | | | | | this work. | |------------------+-------------+----------------+----------------------| | | | | Apple's Darwin | | | | | operating system has | | | | | fairly extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | Not done | -- | msdosfs and other | | fixes | | | kernel services; | | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD tree. | |------------------+-------------+----------------+----------------------| | | | | Truss appears to | | | | | contain a race | | | | | condition during the | | | | | start-up of | | | | | debugging, which can | | | | | result in truss | | | | | failing to attach to | | | | | the process before | | | | | it exits. The | | | | | symptom is that | | | | | truss reports that | | | | | it cannot open the | | | | | procfs node | | | | | supporting the | | | | | process being | | | | | debugged. A bug also | | Race conditions | Errata | Robert Drehmel | appears to exist | | in truss | candidate | | where in truss will | | | | | hang if execve() | | | | | returns ENOENT. A | | | | | further race appears | | | | | to exist in which | | | | | truss will return | | | | | "PIOCWAIT: | | | | | Input/output error" | | | | | occasionally on | | | | | startup. The fix for | | | | | this sufficiently | | | | | changes process | | | | | execution handling | | | | | that we will defer | | | | | the fix to post-5.0 | | | | | and consider this | | | | | errata. | |------------------+-------------+----------------+----------------------| | | | | Truss appears to | | | | | have another | | | | | problem. It is | | | | | repeatable by | | | | | running "truss -f | | More truss | Not done | -- | fsck -p /", | | problems | | | suspending it with | | | | | ^Z, and then killing | | | | | truss. It will leave | | | | | behind the fsck | | | | | processes which will | | | | | be unkillable. | |------------------+-------------+----------------+----------------------| | | | | Many systems | | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | ACL_MASK | | | entry overrides the | | override of | Not done | Robert Watson | umask, rather than | | umask support in | | | being intersected | | UFS | | | with it. The | | | | | resulting semantics | | | | | can be useful in | | | | | group-oriented | | | | | environments, and as | | | | | such would be very | | | | | helpful on FreeBSD. | |------------------+-------------+----------------+----------------------| | | | | The LOR reported in | | | | | PR kern/55175 needs | | filedesc LOR | Not done | -- | to be fixed. | | | | | Filedesc locking | | | | | needs to be heavily | | | | | reviewed in general. | |------------------+-------------+----------------+----------------------| | | | | Currently, MAC | | | | | protections are | | | | | enforced only on | | | | | locally originated | | | | | file system | | | | | operations (VOPs), | | | | | and not on RPCs | | | | | generated via the | | | | | NFS server. | | MAC support for | | | Improvements in NFS | | NFS Server | Not done | Robert Watson | server credential | | | | | handling are | | | | | required to correct | | | | | this problem, as | | | | | well as the | | | | | introduction of new | | | | | entry points to | | | | | properly label NFS | | | | | credentials and | | | | | perform enforcement | | | | | properly. | |------------------+-------------+----------------+----------------------| | | | | All PCI drivers must | | | | | use busdma for DMA; | | | | | no use of vtophys() | | busdma in all | In progress | -- | will be permitted | | PCI drivers | | | for any recent | | | | | device driver. ISA | | | | | drivers may be | | | | | exempt. | |------------------+-------------+----------------+----------------------| | | | | Userland bits | | KSE support for | In progress | Marcel | implemented, kernel | | alpha | | Moolenaar | bits not | | | | | implemented. | |------------------+-------------+----------------+----------------------| | | | | For kernel API/ABI | | | | | compatibility | | | | | reasons, it would be | | CAM locking | In progress | Scott Long, | desirable to have | | | | Justin Gibbs | the CAM locking | | | | | strategy determined | | | | | and loosely | | | | | implemented for 5.3. | |------------------+-------------+----------------+----------------------| | | | | When running syscons | | | | | on an Ultra-30 with | | | | | Creator-3D typing | | | | | characters on the | | | | | keyboard produces | | | | | garbage. Problem | | | | | reported by Kris | | syscons not | | | Kennaway. Debugging | | working on | Not done | -- | difficult due to | | Sparc64 Ultra-30 | | | lack of this | | | | | particular | | | | | configuration among | | | | | developers and | | | | | problem isn't | | | | | present on similar | | | | | hardware (e.g. no | | | | | problem on Ultra-60 | | | | | w/Creator-3D). | +------------------------------------------------------------------------+ Documentation items that must be resolved for 5.3 +-------------------------------------------------------------------------+ | Issue | Status |Responsible| Description | |--------------+-----------+-----------+----------------------------------| | | | |The installation documentation | |i386 Floppy | |Gavin |doesn't take into account the new | |Installation |Done |Atkinson, |floppy images (with a full kernel | |Docs | |Bruce A. |split across multiple disks). This| | | |Mah |should be updated. | | | | |References: docs/70485 (closed) | |--------------+-----------+-----------+----------------------------------| | | |Simon L. |Finish removing mention of | |Finish | |Nielsen, |individual devices in the hardware| |hardware notes|In progress|Christian |notes and use auto-generated | |trimming | |Brueffer |lists, based on driver manual | | | | |pages, instead. | |--------------+-----------+-----------+----------------------------------| | | | |The snd(4) and pcm(4) drivers have| | | | |been renamed but their manual | | | | |pages are still outdated. sound(4)| | | | |has to be added and pcm(4), | | | |Ruslan |csa(4), gusc(4), sbc(4), and | |sound(4) | |Ermilov, |uaudio(4) should be revised. Other| |related manual|In progress|Simon L. |manual pages which refer to pcm(4)| |pages | |Nielsen |(if any) should possibly be | | | | |revised, too. In addition, | | | | |supported cards list needs to be | | | | |updated. | | | | |References: Manpage for snd_solo | | | | |on -doc@ | |--------------+-----------+-----------+----------------------------------| |Sound section | |Marc |This section is outdated, some | |in the |In progress|Fonvieille |rewrites are needed for | |Handbook | | |5.3-RELEASE. | |--------------+-----------+-----------+----------------------------------| |FDP | | |With the snd(4) and pcm(4) drivers| |documentations|Not done |-- |changes, documentations (FAQ) | |related pcm(4)| | |regarding the use of these drivers| | | | |need an update. | |--------------+-----------+-----------+----------------------------------| | | | |Xin LI pointed out that FreeBSD | | | | |5.3-RELEASE is the first stable | | | | |release on 5.X and it is | | | | |(hopefully) not for early | |Early | |Bruce A. |adopters. Early Adopter's Guide is| |Adopter's |In progress|Mah, Tom |still useful, but contains a bit | |Guide | |Rhodes |old information. Some parts of | | | | |this guide need a rewrite, and | | | | |this document should be published | | | | |as "4.X to 5.X Migration Guide", | | | | |which focuses difference between | | | | |4.X and 5.X. | |--------------+-----------+-----------+----------------------------------| | | | |Some parts are outdated. doc/70485| | | | |has been committed, but more work | | | | |is needed to reflect the | | | | |realities. bmah@ pointed out that | |Installation |Not done |Tom Rhodes |we should have "quick-start" | |Notes | | |installation guide for each | | | | |platform instead of the current | | | | |ones because they become too long | | | | |and difficult to be maintained. | | | | |References: doc/70485 (closed) | |--------------+-----------+-----------+----------------------------------| | | | |Update the X11 chapter of the | | | |Ken Tom, |Handbook for X.Org's X11 server. | |Xorg |Done |Marc |References: | | | |Fonvieille |books/handbook/config/chapter.sgml| | | | |rev.1.147 | |--------------+-----------+-----------+----------------------------------| | | | |Ch.11.4 and 11.5 of the Handbook | | | | |must be updated to mention the new| | | | |rc.d scripts and some ports use | |rc.d scripts |In progress|Tom Rhodes |/etc/rc.conf for their | | | | |configuration. | | | | |References: | | | | |books/handbook/config/chapter.sgml| | | | |rev.1.170 | |--------------+-----------+-----------+----------------------------------| |Handbook's | | |Chapter 8 must be updated to match| |kernel |In progress|Ceri Davies|5.3-RELEASE. | |configuration | | |References: docs/70674 (open) | |chapter | | | | |--------------+-----------+-----------+----------------------------------| | | | |Some parts of Section 14.10 are | |Handbook's |Not done |-- |outdated and are not correct for | |IPsec section | | |5.X systems. | | | | |References: ipsec on -doc@ | |--------------+-----------+-----------+----------------------------------| |Handbook's |Not done |-- |Vinum chapter needs to be revised | |Vinum chapter | | |for 5.X systems. | +-------------------------------------------------------------------------+ Testing focuses for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-------------------+---------------+--------------+---------------------| | | | | SCHED_ULE provides | | | | | better | | | | | interactivity, | | | | | higher performance, | | SCHED_ULE as the | Needs testing | Jeff | and the ability to | | default scheduler | | Roberson | support pinning and | | | | | affinity. Basic HTT | | | | | scheduling policies | | | | | should be in place | | | | | for 5.3 also. | |-------------------+---------------+--------------+---------------------| | | | | KSE has matured to | | | | | the point of being | | | | | more stable and | | | | | POSIX-compliant | | | | | than the | | | | | traditional libc_r. | | | | | All Tier-1 | | | | | platforms MUST have | | KSE as the | | David Xu, | stable KSE support | | default threads | Needs testing | Daniel | for 5.3 in order to | | library | | Eischen | support a | | | | | consistent | | | | | transition. | | | | | Additionally, all | | | | | ports that depend | | | | | on the pthreads API | | | | | must be modified to | | | | | properly detect and | | | | | support the default | | | | | threading library. | |-------------------+---------------+--------------+---------------------| | | | | Binutils needs | | | | | updating in order | | Updated binutils | | David | to support new | | for all platforms | Needs testing | O'Brien | platforms, newer | | | | | GDB versions, and | | | | | Thread Local | | | | | Storage. | |-------------------+---------------+--------------+---------------------| | | | | The previous GCC | | | | | 3.3 snapshot | | | | | included | | | | | regressions in | | | | | alignment of | | | | | floating point | | gcc 3.3 floating | | | arguments, | | point alignment | Needs testing | | resulting in a | | regression | | | substantial | | | | | performance | | | | | degradation. The | | | | | recent GCC 3.4.2 | | | | | import should fix | | | | | this, but more | | | | | testing is needed. | |-------------------+---------------+--------------+---------------------| | | | | Jun Kuriyama has | | | | | reportged a failed | | | | | locking assertion | | | | | with IPv6 TCP | | in6_pcbnotify() | Needs testing | Robert | notifications. A | | panic with TCP | | Watson | patch has been | | | | | committed to the | | | | | CVS HEAD and | | | | | RELENG_5 and needs | | | | | further testing. | |-------------------+---------------+--------------+---------------------| | | | | To complete support | | | | | for thread-local | | | | | storage on FreeBSD, | | | | | per-architecture | | Per-platform | | Doug Rabson, | changes must be | | Thread-Local | Needs testing | Marcel | made. Currently | | Storage | | Moolenaar | pending platforms | | | | | are amd64, alpha, | | | | | ia64, i386, | | | | | sparc64, and | | | | | powerpc. | |-------------------+---------------+--------------+---------------------| | | | | High load on SMP | | | | | systems appears to | | | | | result in a hard | | | | | hang related to VM | | | | | IPI. Doug White has | | SMP instability | | Doug White, | prepared a | | under load | Needs testing | Alan L. Cox | candidate patch | | | | | that appears to | | | | | resolve this | | | | | instability, which | | | | | is currently in | | | | | testing for merge | | | | | to the CVS HEAD. | |-------------------+---------------+--------------+---------------------| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4, UNIX domain | | | | | IPC, and sockets) | | | | | now have | | | | | fine-grained | | | | | locking of their | | | | | data structures. | | | | | It's possible to | | | | | run many common | | | | | network subsystems | | | | | and services | | | | | without the Giant | | Fine-grained | | | lock. However, a | | network stack | Needs testing | Robert | number of device | | locking without | | Watson | drivers and less | | Giant | | | mainstream network | | | | | subsystems are | | | | | currently not | | | | | MPSAFE. By | | | | | 5.3-RELEASE, it is | | | | | necessary to have | | | | | the vast majority | | | | | of network code | | | | | running without | | | | | Giant, including | | | | | sockets, permitting | | | | | complete | | | | | local<->remote | | | | | delivery without | | | | | grabbing Giant. | |-------------------+---------------+--------------+---------------------| | | | | As part of the | | | | | MPSAFE network | | | | | stack work, | | | | | delivery of routing | | | | | socket messages was | | | | | moved to queued | | | | | dispatch via netisr | | | | | rather than direct | | | | | dispatch from the | | | | | routing code. | | Increased and | | | However, the risks | | configurable | | Robert | of lost routing | | netisr queue max | Needs testing | Watson | messages for | | depth for routing | | | routing daemons are | | sockets | | | high; respond by | | | | | increasing the max | | | | | depth beyond a | | | | | default interface | | | | | max depth of 50 to | | | | | 128, and allow it | | | | | to be | | | | | user-configured. | | | | | This change is now | | | | | present in CVS HEAD | | | | | and RELENG_5. | |-------------------+---------------+--------------+---------------------| | | | | KLDs work when | | | | | loaded from | | | | | userland, but not | | | | David | from the loader. | | kld support for | Needs testing | O'Brien, Ian | kldxref and loader | | amd64 | | Dowse | support has been | | | | | committed to HEAD | | | | | and RELENG_5 and | | | | | needs final | | | | | testing. | |-------------------+---------------+--------------+---------------------| | | | | Recent changes to | | | | | the ATA driver | | | | | trigger a bug on | | ATA panics under | | So/ren | sparc64 that causes | | sparc64 | Needs testing | Schmidt, | a panic on boot. | | | | Scott Long | This was caused by | | | | | bugs in busdma that | | | | | have been hopefully | | | | | fixed. | +------------------------------------------------------------------------+ ---------------------------------------------------------------------- home | contact | legal | (c) 1995-2004 The FreeBSD Project. All rights reserved. Last modified: 2004/09/09 23:13:10 From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 08:35: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 CBC1616A4CE for ; Fri, 10 Sep 2004 08:35:39 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A51343D1D for ; Fri, 10 Sep 2004 08:35:39 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1C5gqo-000LJc-00; Fri, 10 Sep 2004 10:33:46 +0200 To: Willem Jan Withagen From: Ian FREISLICH In-Reply-To: Message from Willem Jan Withagen of "Fri, 10 Sep 2004 08:37:52 +0200." <41414BC0.40009@withagen.nl> Date: Fri, 10 Sep 2004 10:33:46 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: "Boris B. Samorodov" cc: FreeBSD Current cc: Martin Subject: Re: Interrupt storm detected on "irq7: lpt0" 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, 10 Sep 2004 08:35:39 -0000 Willem Jan Withagen wrote: > I've uped the limit for what the max of interrupts could be.... > In /etc/sysctl.conf > hw.intr_storm_threshold=20000 > > Bit I've seen my lpt intr go as high as 60.000 Why not force ECP? /boot/device.hints: hint.ppc.0.flags="0x8" ppc0: at port 0x378-0x37f irq 7 flags 0x8 on isa0 ppc0: SMC-like chipset (ECP-only) in ECP mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 08:37: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 92D9D16A4CE; Fri, 10 Sep 2004 08:37:18 +0000 (GMT) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0C6D43D5E; Fri, 10 Sep 2004 08:37:17 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1C5gup-00011m-G6; Fri, 10 Sep 2004 12:37:55 +0400 Date: Fri, 10 Sep 2004 12:37:55 +0400 From: "Boris B. Samorodov" To: Andre Oppermann Message-ID: <20040910083755.GA3615@ipt.ru> References: <413B9A36.2D0B9696@freebsd.org> <20040906051024.GA31706@ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906051024.GA31706@ipt.ru> Sender: "Boris B. Samorodov" cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12 in kernel module uipc_mbuf2.c 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, 10 Sep 2004 08:37:18 -0000 Hi! On Mon, Sep 06, 2004 at 09:10:25AM +0400, Boris B. Samorodov wrote: > On Mon, Sep 06, 2004 at 12:59:02AM +0200, Andre Oppermann wrote: > > > > Does it panic 'reliablily' in the same place or is it more of a random > > occurence? I'm not long in the office tomorrow (my test machine is there) > > but I'll try to reproduce it within the next few days. > > Yes. It panics 'reliably'. Here is the console message. > ----- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdeadc0e6 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc053a1f0 > stack pointer = 0x10:0xc7fcb8e8 > frame pointer = 0x10:0xc7fcb8f0 > 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 = 37 (swi1: net) > [thread 100038] > Stopped at m_tag_locate+0x40: cmpl %ecx,0x8(%edx) > ----- I've got another trap 12 with the same instuction pointer. Host has two local nets and two upstream interfaces. $onet_ip1 -- default gateway, $onet_ip2 is used for policy routing. If one try to ping ip to which we fwd packets (i.e. interface of our second provider), system traps. Pinging (and other work with) other ips does not cause traps. > > Andre > bsam WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 09:19: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 5066D16A4CE for ; Fri, 10 Sep 2004 09:19:29 +0000 (GMT) Received: from picard.newmillennium.net.au (dsl-114.250.240.220.dsl.comindico.com.au [220.240.250.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 880D343D1D for ; Fri, 10 Sep 2004 09:19:28 +0000 (GMT) (envelope-from freebsd@newmillennium.net.au) Received: from [172.16.0.67] (crusher.nmn.cafn [172.16.0.67]) i8A9ItIu001759; Fri, 10 Sep 2004 19:18:57 +1000 (EST) (envelope-from freebsd@newmillennium.net.au) From: "Alastair D'Silva" To: Oliver Brandmueller In-Reply-To: <20040910001711.GA79295@e-Gitt.NET> References: <1094768862.1380.10.camel@crusher.laptop> <20040910001711.GA79295@e-Gitt.NET> Content-Type: text/plain Organization: New Millennium Networking Message-Id: <1094807933.80285.1.camel@crusher.laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 19:18:53 +1000 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Transparent proxying broken? 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, 10 Sep 2004 09:19:29 -0000 On Fri, 2004-09-10 at 10:17, Oliver Brandmueller wrote: > On Fri, Sep 10, 2004 at 08:27:42AM +1000, Alastair D'Silva wrote: > > It seems that transparent proxying has been broken with all the changes > > to the networking stack. > > Have a look at the thread "RELENG_5 ipfw problem" starting Aug 27 in > this mailing list. There are hints about using a special kernel option > and also me with a forwarding problem even with this kernel option. > Please give your comments to this thread then also. Adding "options IPFIREWALL_FORWARD" has fixed my problem - I never noticed the "rule based forwarding disabled" message. -- Alastair D'Silva mob: 0423 762 819 Networking Consultant fax: 0413 181 661 New Millennium Networking web: http://www.newmillennium.net.au From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 09:25: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 43D6116A4CF for ; Fri, 10 Sep 2004 09:25:59 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id E609443D39 for ; Fri, 10 Sep 2004 09:25:57 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id i8A9PtEg059011; Fri, 10 Sep 2004 11:25:56 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <41417326.1000309@withagen.nl> Date: Fri, 10 Sep 2004 11:25:58 +0200 From: Willem Jan Withagen 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: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "Boris B. Samorodov" cc: FreeBSD Current cc: Martin Subject: Re: Interrupt storm detected on "irq7: lpt0" 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, 10 Sep 2004 09:25:59 -0000 I think I tried that one, but it did not work. I still have that flag standing. Now that is a long time ago, and this could be done without rebooting the server. dmesg: ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x778-0x77b,0x378-0x37b 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 ppbus0: IEEE1284 device found /NIBBLE/ECP/NIBBLE_ID/ECP_ID/Extensibility Link Probing for PnP devices on ppbus0: ppbus0: PJL,MLC,PCL,PCLXL,POSTSCRIPT lpt0: on ppbus0 lpt0: Interrupt-driven port I'll give it a shot for the next reboot. Major difference I see is that you've got the device on isa0 whereas mine is on acpi0 --WjW Ian FREISLICH wrote: >Willem Jan Withagen wrote: > > >>I've uped the limit for what the max of interrupts could be.... >>In /etc/sysctl.conf >>hw.intr_storm_threshold=20000 >> >>Bit I've seen my lpt intr go as high as 60.000 >> >> > >Why not force ECP? > >/boot/device.hints: hint.ppc.0.flags="0x8" > >ppc0: at port 0x378-0x37f irq 7 flags 0x8 on isa0 >ppc0: SMC-like chipset (ECP-only) in ECP mode >ppc0: FIFO with 16/16/16 bytes threshold >ppbus0: on ppc0 >lpt0: on ppbus0 >lpt0: Interrupt-driven port > >Ian > >-- >Ian Freislich > > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 09: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 54D8316A4D3 for ; Fri, 10 Sep 2004 09:57:17 +0000 (GMT) Received: from shrike.submonkey.net (cpc2-cdif3-6-0-cust204.cdif.cable.ntl.com [81.103.67.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id F24E543D4C for ; Fri, 10 Sep 2004 09:57:16 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.42 (FreeBSD)) id 1C5i9c-0009V9-0p; Fri, 10 Sep 2004 10:57:16 +0100 Date: Fri, 10 Sep 2004 10:57:15 +0100 From: Ceri Davies To: Rob Message-ID: <20040910095715.GO44674@submonkey.net> Mail-Followup-To: Ceri Davies , Rob , freebsd-current References: <4140C31C.8020801@pythonemproject.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qo7zVO9a9OQ5oQtr" Content-Disposition: inline In-Reply-To: <4140C31C.8020801@pythonemproject.com> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.6i Sender: Ceri Davies cc: freebsd-current Subject: Re: warning messages from root mount until login, also my rc.conf file 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, 10 Sep 2004 09:57:17 -0000 --qo7zVO9a9OQ5oQtr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2004 at 01:54:52PM -0700, Rob wrote: > Sorry about attaching files but can't seem to put them inline with > mozilla. Perhaps Sylpheed would work better. >=20 > I can actually get even more warning messages if I delay logging in. > For example, sendmail claims it can't find a socket and comes back with > a multitude of warnings. In this particular case, just wanted to show a > few examples. Do you have an /etc/defaults/rc.conf ? > Sep 7 20:07:41 lm741n kernel: Mounting root from ufs:/dev/ad0s3a > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not s= et properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable i= s not set properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is= not set properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is= not set properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $named_enable is not set p= roperly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $enable_quotas is not set = properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pflog_enable is not set p= roperly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pf_enable is not set prop= erly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set = properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $virecover_enable is not s= et properly - see rc.conf(5). > Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $timed_enable is not set p= roperly - see rc.conf(5). --qo7zVO9a9OQ5oQtr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBQXp7ocfcwTS3JF8RAnqTAJ9n7o/zoR3xW+DAXgAKxLvIWXC/0gCbBkDc NJhT3zCwB794kwriiyIsTbI= =/jTD -----END PGP SIGNATURE----- --qo7zVO9a9OQ5oQtr-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 10:22: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 B1D2816A4CE for ; Fri, 10 Sep 2004 10:22:13 +0000 (GMT) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4604143D1D for ; Fri, 10 Sep 2004 10:22:13 +0000 (GMT) (envelope-from cernm0bm@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 10663) id 712EA57F7; Fri, 10 Sep 2004 12:22:11 +0200 (CEST) Date: Fri, 10 Sep 2004 12:22:11 +0200 From: Marian Cerny To: "Bjoern A. Zeeb" Message-ID: <20040910102211.GA15808@artax.karlin.mff.cuni.cz> References: <20040907163133.GA24426@artax.karlin.mff.cuni.cz> <20040908133452.GA11639@artax.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 10:22:13 -0000 Heh, I noticed one more LOR. This one happens when I turn the laptop off using 'halt -p' after syncing disks. It's *hand*-rewritten, because the laptop turned itself off after 10 seconds, despite the fact, that I was inside kernel debugger (I took a shot with my digital photo camera). lock order reversal 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c08bde68,c08beb88,c084ddac) at kdb_backtrace+0x29 withness_checkorder(c08adee4,9,c0808137,bb5) at witness_checkorder+0x544 _sx_xlock(c08adee4,c0808137,bb5) at _sx_xlock+0x50 _vm_map_lock_read(c08adea0,c0808137,bb5,20000004,c16bae6c) at _vm_map_lock_read+0x37 vm_map_lookup(ceef9bb8,0,2,ceef9bbc,ceef9bac) at vm_map_lookup+0x28 vm_fault(c08adea0,0,2,8,c16b5b00) at vm_fault+0x66 trap_pfault(ceef9c80,0,c) at trap_pgault+0xf2 trap(18,10,10,0,3b) at trap+0x335 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- re_rxeof(c177b000) at re_rxeof+0x2ae re_intr(c177b000) at re_intr+0xb3 ithread_loop(c16bf400,ceef9d48,c16bf400,c05ed66c,0) at ithread_loop+0x124 fork_exit(c05ed66c,c16bf400,ceef9d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = exceef9d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x8:0xc0575b76 stack pointer = 0x10:0xceef8cc0 frame pointer = 0x10:0xceef9cdc 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 = 22 (irq11: re0 ohci0+) [thread 100019] Stopped at re_rxeof+0x2ae: movl %eax,0xc(%edi) db> This LOR might be obsolete, because I'm not using patched version of if_re0.c for the LOR #26 in LORs database (I'm using 5.3-BETA3). After 5.3-BETA4 will be available, I can send, wether this patch helped in this situation also, because I get this LOR + PANIC in 30% of shutdown attempts. Marian Cerny -- Marian Cerny Jabber: jojo@njs.netlab.cz [ UNIX is user friendly. It's just selective about who its friends are. ] From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 10:45: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 B971A16A4CE for ; Fri, 10 Sep 2004 10:45:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D06D43D1F for ; Fri, 10 Sep 2004 10:45: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 5FA561FFDD9; Fri, 10 Sep 2004 12:45:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 50FC21FFDD8; Fri, 10 Sep 2004 12:45:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 1A5641567C; Fri, 10 Sep 2004 10:40:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 16C7215329; Fri, 10 Sep 2004 10:40:50 +0000 (UTC) Date: Fri, 10 Sep 2004 10:40:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Marian Cerny In-Reply-To: <20040910102211.GA15808@artax.karlin.mff.cuni.cz> Message-ID: References: <20040907163133.GA24426@artax.karlin.mff.cuni.cz> <20040908133452.GA11639@artax.karlin.mff.cuni.cz> <20040910102211.GA15808@artax.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-current@freebsd.org Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 10:45:09 -0000 On Fri, 10 Sep 2004, Marian Cerny wrote: > lock order reversal > 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 > 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c08bde68,c08beb88,c084ddac) at kdb_backtrace+0x29 > withness_checkorder(c08adee4,9,c0808137,bb5) at witness_checkorder+0x544 > _sx_xlock(c08adee4,c0808137,bb5) at _sx_xlock+0x50 > _vm_map_lock_read(c08adea0,c0808137,bb5,20000004,c16bae6c) at _vm_map_lock_read+0x37 > vm_map_lookup(ceef9bb8,0,2,ceef9bbc,ceef9bac) at vm_map_lookup+0x28 > vm_fault(c08adea0,0,2,8,c16b5b00) at vm_fault+0x66 > trap_pfault(ceef9c80,0,c) at trap_pgault+0xf2 > trap(18,10,10,0,3b) at trap+0x335 > calltrap() at calltrap+0x5 this first half looks pretty much the same as http://sources.zabbadoz.net/freebsd/lor.html#031 1st 0xc08ec200 ifnet (ifnet) @ sys/net/if.c:1489 2nd 0xc46703c8 user map (user map) @ sys/vm/vm_map.c:2994 > --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- > re_rxeof(c177b000) at re_rxeof+0x2ae > re_intr(c177b000) at re_intr+0xb3 > ithread_loop(c16bf400,ceef9d48,c16bf400,c05ed66c,0) at ithread_loop+0x124 > fork_exit(c05ed66c,c16bf400,ceef9d48) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = exceef9d7c, ebp = 0 --- -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 10:59: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 5544A16A4CE for ; Fri, 10 Sep 2004 10:59:46 +0000 (GMT) Received: from shub-internet.kew.com (h00062574bf3c.ne.client2.attbi.com [66.30.223.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EB2A43D58 for ; Fri, 10 Sep 2004 10:59:46 +0000 (GMT) (envelope-from ahd@kew.com) Received: by shub-internet.kew.com (Postfix, from userid 1015) id ADFEB12325; Fri, 10 Sep 2004 06:59:45 -0400 (EDT) Received: from kendra (kendra.hh.kew.com [192.168.203.132]) by shub-internet.kew.com (Postfix) with ESMTP id 7CCD1122DE; Fri, 10 Sep 2004 06:59:43 -0400 (EDT) From: "Andrew H. Derbyshire" To: "'Bruce Evans'" , "'M. Warner Losh'" Date: Fri, 10 Sep 2004 06:59:42 -0400 Organization: Kendra Electronic Wonderworks, Stoneham, MA (http://www.kew.com) Message-ID: <00a701c49725$465caf80$84cba8c0@hh.kew.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20040910180421.Y1368@epsplex.bde.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal cc: freebsd-current@freebsd.org Subject: RE: PCI SIO devices hog interrupts, cause lock order 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: Fri, 10 Sep 2004 10:59:46 -0000 >> > Does the distributed GENERIC > > : kernel have room for the PUC device? Are there side > effects that PUC should > > : be excluded from GENERIC? > > > > puc should be in GENERIC, imho. > > I agree. It is too large due to its sparse data structures, > but since the > sparse data compresses very well, it doesn't take any more space on > boot media than most drivers in GENERIC. I opened kern/71198 requesting this add last week. -ahd- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 11:51: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 4B9BB16A4CE for ; Fri, 10 Sep 2004 11:51:53 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6428F43D39 for ; Fri, 10 Sep 2004 11:51:52 +0000 (GMT) (envelope-from sebastian.ssmoller@gmx.net) Received: (qmail 347 invoked by uid 65534); 10 Sep 2004 11:51:50 -0000 Received: from pD9E8220A.dip.t-dialin.net (HELO tyrael.linnet) (217.232.34.10) by mail.gmx.net (mp027) with SMTP; 10 Sep 2004 13:51:50 +0200 X-Authenticated: #15005775 Date: Fri, 10 Sep 2004 13:52:22 +0200 From: sebastian ssmoller To: freebsd-current@freebsd.org Message-Id: <20040910135222.48f20952.sebastian.ssmoller@gmx.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.1; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: snd_ich no longer works. 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, 10 Sep 2004 11:51:53 -0000 hi, works fine here ... $ uname -a FreeBSD hadriel.linnet 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sun Sep 5 18:26:57 CEST 2004 seb@hadriel.linnet:/usr/obj/usr/src/sys/DEBUG i386 $ dmesg pcm0: port 0xe100-0xe13f,0xe000-0xe0ff at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: $ pciconf -vl pcm0@pci0:31:5: class=0x040100 card=0x17131043 chip=0x24c58086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller' class = multimedia subclass = audio regards, seb On Thu, 09 Sep 2004 07:51:40 -0500 eculp wrote: > I just realized that my onboard > pcm0@pci0:2:7: class=0x040100 card=0xa00c1019 chip=0x70121039 > rev=0xa0 hdr=0x00 > vendor = 'Silicon Integrated Systems (SiS)' > device = 'SiS7012 PCI Audio Accelerator' > class = multimedia > That uses snd_ich no longer works with my new world and kernel from > yesterday morning but the by going back to a kernel from Sept 3, it > works fine. > > Is this a known issue? Is there something that I can do to help > isolate the issue? > > Thanks, > > ed > > P.S. This is an AMD Duron > CPU: AMD Duron(tm) (1600.06-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 > Features=0x383fbff ,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE> > AMD Features=0xc0400000 > > > _______________________________________________ > 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" > -- "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." --- Antoine de St. Exupery, Wind, Sand, and Stars, 1939 From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 11:52: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 C838216A4CE for ; Fri, 10 Sep 2004 11:52:46 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D1F43D5D for ; Fri, 10 Sep 2004 11:52:45 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [195.159.6.24] (ws24.ns5.powertech.no [195.159.6.24]) by smtp1.powertech.no (Postfix) with ESMTP id CFCFA8093; Fri, 10 Sep 2004 13:52:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) To: current@freebsd.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-15-545846285 From: Frode Nordahl Date: Fri, 10 Sep 2004 13:52:43 +0200 X-Mailer: Apple Mail (2.619) cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Promise PDC20267 ATA RAID, poor write performance 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, 10 Sep 2004 11:52:46 -0000 --Apple-Mail-15-545846285 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hello, I have a intel S845WD1-E board with onboard Promise PDC20267 controller. The system is set up with a P4 2Ghz with 1GB RAM. The board also has a Intel ICH2, but that's only used by a CDROM. Disks connected: ad4: 39205MB [79656/16/63] at ata2-master UDMA100 ad6: 39205MB [79656/16/63] at ata3-master UDMA100 I have them set up in a RAID1 I have tried this on FreeBSD 4.10-RELEASE, and 6-CURRENT (from today) with similar results. I also tried with RAID0, and that showed the same results*2, that is, ca. 7MB/s write instead of 3.5MB/s. I have no previous experience with this hardware on other OS'es, so I'm not sure what to expect, but I'm pretty sure it should be better than this :) dmesg included below. Doing simple tests show very poor write performance: (reboot) # dd if=/dev/zero of=fill bs=1m count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 588.383886 secs (3564258 bytes/sec) (reboot) # dd if=fill of=/dev/null bs=1m 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 68.492015 secs (30618927 bytes/sec) sample output from iostat 10 during write: 0 8 0.00 0 0.00 0.00 0 0.00 127.18 27 3.39 0 0 3 1 96 0 8 0.00 0 0.00 0.00 0 0.00 126.22 27 3.39 0 0 3 0 97 0 8 0.00 0 0.00 0.00 0 0.00 122.15 30 3.57 0 0 3 0 97 0 8 0.00 0 0.00 0.00 0 0.00 127.59 27 3.41 0 0 3 0 97 sample output from iostat 10 during read: 0 8 0.00 0 0.00 0.00 0 0.00 127.53 238 29.61 0 0 14 1 86 1 90 0.00 0 0.00 0.00 0 0.00 126.71 241 29.80 1 0 14 1 84 0 8 0.00 0 0.00 0.00 0 0.00 127.06 231 28.67 0 0 15 1 84 0 62 0.00 0 0.00 0.00 0 0.00 127.52 235 29.26 0 0 14 1 85 sample output from vmstat -i during write: interrupt total rate irq1: atkbd0 4 0 irq6: fdc0 5 0 irq8: rtc 30548 127 irq13: npx0 1 0 irq14: ata0 47 0 irq18: fxp0 3990 16 irq22: atapci0 18032 75 irq0: clk 23865 99 Total 76492 318 sample output from vmstat -i during read: interrupt total rate irq1: atkbd0 1 0 irq6: fdc0 5 0 irq8: rtc 21926 127 irq13: npx0 1 0 irq14: ata0 47 0 irq18: fxp0 1523 8 irq22: atapci0 33047 192 irq0: clk 17128 99 Total 73678 428 Mvh, Frode Nordahl --Apple-Mail-15-545846285 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name="dmesg.txt" Content-Disposition: attachment; filename=dmesg.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. FreeBSD 5.3-BETA3 #1: Fri Sep 10 13:26:36 CEST 2004 frode@somewhere.else.org:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1993.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 1073479680 (1023 MB) avail memory = 1040932864 (992 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 30.0 on pci0 pci2: on pcib2 fxp0: port 0xde80-0xdebf mem 0xfea80000-0xfea9ffff,0xfeafe000-0xfeafefff irq 18 at device 12.0 on pci2 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:aa:00:30:8f:4c fxp1: port 0xdd80-0xddbf mem 0xfea40000-0xfea5ffff,0xfeafd000-0xfeafdfff irq 19 at device 13.0 on pci2 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:aa:00:30:8f:4d atapci0: port 0xdf00-0xdf3f,0xdfe0-0xdfe3,0xdfa8-0xdfaf,0xdfe4-0xdfe7,0xdff0-0xdff7 mem 0xfeaa0000-0xfeabffff irq 22 at device 14.0 on pci2 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 pci2: at device 15.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 uhci0: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) uhci1: port 0xef80-0xef9f irq 23 at device 31.4 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xd2800-0xd37ff,0xd1800-0xd27ff,0xc9000-0xd17ff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1993544204 Hz quality 800 Timecounters tick every 10.000 msec ATAPI_RESET time = 20us acd0: CDROM at ata0-slave UDMA33 ad4: 39205MB [79656/16/63] at ata2-master UDMA100 ad6: 39205MB [79656/16/63] at ata3-master UDMA100 ar0: 39100MB [4984/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Mounting root from ufs:/dev/ar0s1a --Apple-Mail-15-545846285-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 12:24: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 B97D016A4CE for ; Thu, 9 Sep 2004 12:24:33 +0000 (GMT) Received: from web53809.mail.yahoo.com (web53809.mail.yahoo.com [206.190.36.204]) by mx1.FreeBSD.org (Postfix) with SMTP id 749DB43D1F for ; Thu, 9 Sep 2004 12:24:33 +0000 (GMT) (envelope-from santoshdj123@yahoo.com) Message-ID: <20040909122432.53140.qmail@web53809.mail.yahoo.com> Received: from [202.56.203.243] by web53809.mail.yahoo.com via HTTP; Thu, 09 Sep 2004 05:24:32 PDT Date: Thu, 9 Sep 2004 05:24:32 -0700 (PDT) From: santosh jambhlikar To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 Subject: samba+ldap+vpopmail 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, 09 Sep 2004 12:24:33 -0000 hi, I saw ur posting at http://lists.freebsd.org/pipermail/freebsd-current/2004-April/026369.html website. I was happy to see that someone has allready worked on this. i.e. samba+ldap+vpopmail. i configured samba+ldap working fine. i also configured vpopmail+ldap it is also working fine. but i can not place the ldap for both to authenticate. Can u Please tell me how to do that? Thanks and Regards Santosh Linux admin. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 20:37: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 BF4F116A4CE for ; Thu, 9 Sep 2004 20:37:46 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3C8943D5E for ; Thu, 9 Sep 2004 20:37:45 +0000 (GMT) (envelope-from europax@comcast.net) Received: from [192.168.1.101] (c-67-169-203-186.client.comcast.net[67.169.203.186]) by comcast.net (sccrmhc11) with ESMTP id <200409092037440110023tj7e> (Authid: europax); Thu, 9 Sep 2004 20:37:44 +0000 Message-ID: <4140BF50.2080700@comcast.net> Date: Thu, 09 Sep 2004 13:38:40 -0700 From: Rob User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current Content-Type: multipart/mixed; boundary="------------080204040203040204040005" X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 Subject: warning messages from root mount until login, also my rc.conf file 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, 09 Sep 2004 20:37:46 -0000 This is a multi-part message in MIME format. --------------080204040203040204040005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry about attaching files but can't seem to put them inline with mozilla. Perhaps Sylpheed would work better. I can actually get even more warning messages if I delay logging in. For example, sendmail claims it can't find a socket and comes back with a multitude of warnings. In this particular case, just wanted to show a few examples. Rob --------------080204040203040204040005 Content-Type: text/plain; name="rc.conf1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc.conf1" #!/bin/sh # # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. You should # not edit this file! Put any overrides into one of the ${rc_conf_files} # instead and you will be able to update these defaults later without # spamming your local configuration information. # # The ${rc_conf_files} files should only contain values which override # values set in this file. This eases the upgrade path when defaults # are changed and new features are added. # # All arguments must be in double or single quotes. # # $FreeBSD: src/etc/defaults/rc.conf,v 1.212 2004/07/27 00:28:16 mlaier Exp $ ############################################################## ### Important initial Boot-time options #################### ############################################################## apm_enable="YES" # Set to YES to enable APM BIOS functions (or NO). apmd_enable="YES" # Run apmd to handle APM event from userland. apmd_flags="" # Flags to apmd (if enabled). pccard_enable="NO" # Set to YES if you want to configure PCCARD devices. pccard_mem="DEFAULT" # If pccard_enable=YES, this is card memory address. pccard_beep="2" # pccard beep type. pccard_ifconfig="NO" # Specialized pccard ethernet configuration (or NO). pccardd_flags="-z" # Additional flags for pccardd. pccard_conf="/etc/defaults/pccard.conf" # pccardd(8) config file pccard_ether_delay="5" # Delay before trying to start dhclient in pccard_ether removable_interfaces="" # Removable network interfaces for /etc/pccard_ether. tmpmfs="AUTO" # Set to YES to always create an mfs /tmp, NO to never tmpsize="20m" # Size of mfs /tmp if created varmfs="AUTO" # Set to YES to always create an mfs /var, NO to never varsize="32m" # Size of mfs /var if created populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # startup script dirs. rc_conf_files="/etc/rc.conf /etc/rc.conf.local" background_fsck="YES" # Attempt to run fsck in the background where possible. background_fsck_delay="60" # Time to wait (seconds) before starting the fsck. # mount at startup (or NO). ############################################################## ### Network configuration sub-section ###################### ############################################################## ### Basic network and firewall/security options: ### firewall_enable="NO" # Set to YES to enable firewall functionality firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall) firewall_quiet="NO" # Set to YES to suppress rule display firewall_logging="NO" # Set to YES to enable events logging firewall_flags="" # Flags passed to ipfw when type is a file ip_portrange_first="NO" # Set first dynamically allocated port ip_portrange_last="NO" # Set last dynamically allocated port ipfilter_enable="YES" # Set to YES to enable ipfilter functionality ipfilter_program="/sbin/ipf" # where the ipfilter program lives ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see # /usr/src/contrib/ipfilter/rules for examples ipfilter_flags="" # additional flags for ipfilter ipmon_enable="YES" # Set to YES for ipmon; needs ipfilter or ipnat ipmon_program="/sbin/ipmon" # where the ipfilter monitor program lives ipmon_flags="-Ds" # typically "-Ds" or "-D /var/log/ipflog" tcp_keepalive="YES" # Enable stale TCP connection timeout (or NO). # For the following option you need to have TCP_DROP_SYNFIN set in your # kernel. Please refer to LINT and NOTES for details. tcp_drop_synfin="YES" # Set to YES to drop TCP packets with SYN+FIN # NOTE: this violates the TCP specification icmp_drop_redirect="YES" # Set to YES to ignore ICMP REDIRECT packet icmp_log_redirect="YES" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a different one. syslogd_flags="-s" # Flags to syslogd (if enabled). #syslogd_flags="-ss" # Syslogd flags to not bind an inet socket inetd_enable="YES" # Run the network daemon dispatcher (YES/NO). inetd_program="/usr/sbin/inetd" # path to inetd, if you want a different one. inetd_flags="-wW -C 60" # Optional flags to inetd # sshd_enable="YES" # Enable sshd sshd_program="/usr/sbin/sshd" # path to sshd, if you want a different one. sshd_flags="" # Additional flags for sshd. ############################################################## ### System console options ################################# ############################################################## moused_enable="YES" # Run the mouse daemon. moused_type="auto" # See man page for rc.conf(5) for available settings. moused_port="/dev/psm0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. mousechar_start="NO" # if 0xd0-0xd3 default range is occupied in your # language code table, specify alternative range # start like mousechar_start=3, see vidcontrol(1) ############################################################## ### Mail Transfer Agent (MTA) options ###################### ############################################################## mta_start_script="/etc/rc.sendmail" # Script to start your chosen MTA, called by /etc/rc. # Settings for /etc/rc.sendmail and /etc/rc.d/sendmail: sendmail_enable="NO" # Run the sendmail inbound daemon (YES/NO). sendmail_pidfile="/var/run/sendmail.pid" # sendmail pid file sendmail_procname="/usr/sbin/sendmail" # sendmail process name sendmail_flags="-L sm-mta -bd -q30m" # Flags to sendmail (as a server) sendmail_submit_enable="YES" # Start a localhost-only MTA for mail submission sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost" # Flags for localhost-only MTA sendmail_outbound_enable="YES" # Dequeue stuck mail (YES/NO). sendmail_outbound_flags="-L sm-queue -q30m" # Flags to sendmail (outbound only) sendmail_msp_queue_enable="YES" # Dequeue stuck clientmqueue mail (YES/NO). sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m" # Flags for sendmail_msp_queue daemon. ############################################################## ### Miscellaneous administrative options ################### ############################################################## cron_enable="YES" # Run the periodic job daemon. cron_program="/usr/sbin/cron" # Which cron executable to run (if enabled). cron_dst="YES" # Handle DST transitions intelligently (YES/NO) cron_flags="" # Which options to pass to the cron daemon. lpd_enable="YES" # Run the line printer daemon. lpd_program="/usr/sbin/lpd" # path to lpd, if you want a different one. lpd_flags="" # Flags to lpd (if enabled). usbd_enable="YES" # Run the usbd daemon. usbd_flags="" # Flags to usbd (if enabled). linux_enable="YES" # Linux binary compatibility loaded at startup (or NO). ldconfig_insecure="YES" # Set to YES to disable ldconfig security checks ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib" # shared library search paths ldconfig_paths_aout="/usr/lib/compat/aout /usr/X11R6/lib/aout /usr/local/lib/aout" # a.out shared library search paths kern_securelevel_enable="NO" # kernel security level (see init(8)), kern_securelevel="-1" # range: -1..3 ; `-1' is the most insecure dmesg_enable="YES" # Save dmesg(8) to /var/run/dmesg.boot performance_throttle_state="HIGH" # Online throttling state # Enable network daemons for user convenience. # Created: Tue Sep 7 03:09:30 2004 # -- sysinstall generated deltas -- # Tue Sep 7 03:09:30 2004 ifconfig_bfe0="inet 192.168.1.101 netmask 255.255.255.0" defaultrouter="192.168.1.1" hostname="lm741n.comcast.net" # This file now contains just the overrides from /etc/defaults/rc.conf. # Please make all changes to this file, not to /etc/defaults/rc.conf. --------------080204040203040204040005 Content-Type: text/plain; name="messages1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages1" Sep 7 20:07:41 lm741n kernel: Mounting root from ufs:/dev/ad0s3a Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $named_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $enable_quotas is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pflog_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pf_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $virecover_enable is not set properly - see rc.conf(5). Sep 7 20:07:41 lm741n root: /etc/rc: WARNING: $timed_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) Sep 7 20:07:42 lm741n apmd[385]: start Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $bootparamd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n lpd[397]: lpd startup: logging=0 Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $update_motd is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $ntpd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $rarpd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $rtadvd_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $rwhod_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $ibcs2_enable is not set properly - see rc.conf(5). Sep 7 20:07:42 lm741n root: /etc/rc: WARNING: $sysvipc_enable is not set properly - see rc.conf(5). Sep 7 20:07:44 lm741n root: /etc/rc: WARNING: $svr4_enable is not set properly - see rc.conf(5). Sep 7 20:07:44 lm741n root: /etc/rc: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 20:07:44 lm741n root: /etc/rc: WARNING: $ntpdate_enable is not set properly - see rc.conf(5). Sep 7 20:19:05 lm741n kernel: ugen1: NEC NEC USB UF000x, rev 1.10/1.50, addr 2 Sep 7 20:20:27 lm741n kernel: ugen1: at uhub0 port 1 (addr 2) disconnected Sep 7 20:20:27 lm741n kernel: ugen1: detached Sep 7 21:51:38 lm741n login: ROOT LOGIN (root) ON ttyv1 Sep 7 21:56:09 lm741n su: rob to root on /dev/ttyv0 Sep 7 22:00:56 lm741n shutdown: shutdown by rob: Sep 7 22:00:59 lm741n root: /etc/rc.shutdown: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 22:00:59 lm741n root: /etc/rc.shutdown: WARNING: $ipfs_enable is not set properly - see rc.conf(5). Sep 7 22:00:59 lm741n syslogd: exiting on signal 15 Sep 7 22:01:10 lm741n syslogd: kernel boot file is /boot/kernel/kernel Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $named_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $enable_quotas is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $pflog_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $pf_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set properly - see rc.conf(5). Sep 7 22:01:10 lm741n root: /etc/rc: WARNING: $virecover_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $timed_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) Sep 7 22:01:11 lm741n apmd[1212]: start Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $bootparamd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n lpd[1224]: lpd startup: logging=0 Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $update_motd is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $ntpd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $rarpd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $rtadvd_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $rwhod_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $ibcs2_enable is not set properly - see rc.conf(5). Sep 7 22:01:11 lm741n root: /etc/rc: WARNING: $sysvipc_enable is not set properly - see rc.conf(5). Sep 7 22:01:13 lm741n root: /etc/rc: WARNING: $svr4_enable is not set properly - see rc.conf(5). Sep 7 22:01:13 lm741n root: /etc/rc: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 22:01:13 lm741n root: /etc/rc: WARNING: $ntpdate_enable is not set properly - see rc.conf(5). Sep 7 22:03:04 lm741n su: rob to root on /dev/ttyv0 Sep 7 23:21:48 lm741n shutdown: power-down by rob: Sep 7 23:21:50 lm741n root: /etc/rc.shutdown: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 7 23:21:50 lm741n root: /etc/rc.shutdown: WARNING: $ipfs_enable is not set properly - see rc.conf(5). Sep 7 23:21:50 lm741n syslogd: exiting on signal 15 Sep 9 13:14:01 lm741n syslogd: kernel boot file is /boot/kernel/kernel Sep 9 13:14:01 lm741n kernel: Copyright (c) 1992-2004 The FreeBSD Project. Sep 9 13:14:01 lm741n kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Sep 9 13:14:01 lm741n kernel: The Regents of the University of California. All rights reserved. Sep 9 13:14:01 lm741n kernel: FreeBSD 5.3-BETA2 #0: Mon Sep 6 22:22:52 PDT 2004 Sep 9 13:14:01 lm741n kernel: root@:/usr/src/sys/i386/compile/ROBKERN Sep 9 13:14:01 lm741n kernel: WARNING: WITNESS option enabled, expect reduced performance. Sep 9 13:14:01 lm741n kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Sep 9 13:14:01 lm741n kernel: CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.57-MHz 686-class CPU) Sep 9 13:14:01 lm741n kernel: Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Sep 9 13:14:01 lm741n kernel: Features=0xa7e9f9bf Sep 9 13:14:01 lm741n kernel: real memory = 1073405952 (1023 MB) Sep 9 13:14:01 lm741n kernel: avail memory = 1040867328 (992 MB) Sep 9 13:14:01 lm741n kernel: npx0: [FAST] Sep 9 13:14:01 lm741n kernel: npx0: on motherboard Sep 9 13:14:01 lm741n kernel: npx0: INT 16 interface Sep 9 13:14:01 lm741n kernel: pcib0: pcibus 0 on motherboard Sep 9 13:14:01 lm741n kernel: pir0: on motherboard Sep 9 13:14:01 lm741n kernel: $PIR: BIOS IRQ 11 for 0.29.INTB is not valid for link 0x63 Sep 9 13:14:01 lm741n kernel: $PIR: BIOS IRQ 11 for 2.1.INTA is not valid for link 0x63 Sep 9 13:14:01 lm741n kernel: pci0: on pcib0 Sep 9 13:14:01 lm741n kernel: agp0: mem 0xe0000000-0xe7ffffff at device 0.0 on pci0 Sep 9 13:14:01 lm741n kernel: pcib1: at device 1.0 on pci0 Sep 9 13:14:01 lm741n kernel: pci1: on pcib1 Sep 9 13:14:01 lm741n kernel: pci1: at device 0.0 (no driver attached) Sep 9 13:14:01 lm741n kernel: uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 Sep 9 13:14:01 lm741n kernel: uhci0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb0: on uhci0 Sep 9 13:14:01 lm741n kernel: usb0: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub0: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: uhci1: port 0xbf40-0xbf5f irq 11 at device 29.1 on pci0 Sep 9 13:14:01 lm741n kernel: uhci1: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb1: on uhci1 Sep 9 13:14:01 lm741n kernel: usb1: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub1: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: uhci2: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 Sep 9 13:14:01 lm741n kernel: uhci2: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb2: on uhci2 Sep 9 13:14:01 lm741n kernel: usb2: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub2: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: pci0: at device 29.7 (no driver attached) Sep 9 13:14:01 lm741n kernel: pcib2: at device 30.0 on pci0 Sep 9 13:14:01 lm741n kernel: pci2: on pcib2 Sep 9 13:14:01 lm741n kernel: bfe0: mem 0xfaffe000-0xfaffffff irq 11 at device 0.0 on pci2 Sep 9 13:14:01 lm741n kernel: miibus0: on bfe0 Sep 9 13:14:01 lm741n kernel: bmtphy0: on miibus0 Sep 9 13:14:01 lm741n kernel: bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Sep 9 13:14:01 lm741n kernel: bfe0: Ethernet address: 00:0d:56:38:b8:a0 Sep 9 13:14:01 lm741n kernel: bfe0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: cbb0: irq 11 at device 1.0 on pci2 Sep 9 13:14:01 lm741n kernel: cardbus0: on cbb0 Sep 9 13:14:01 lm741n kernel: pccard0: <16-bit PCCard bus> on cbb0 Sep 9 13:14:01 lm741n kernel: fwohci0: <1394 Open Host Controller Interface> mem 0xfaff8000-0xfaffbfff,0xfaffd800-0xfaffdfff irq 11 at device 1.1 on pci2 Sep 9 13:14:01 lm741n kernel: fwohci0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: fwohci0: OHCI version 1.10 (ROM=0) Sep 9 13:14:01 lm741n kernel: fwohci0: No. of Isochronous channels is 4. Sep 9 13:14:01 lm741n kernel: fwohci0: EUI64 5b:4f:c0:00:3f:ff:ff:ff Sep 9 13:14:01 lm741n kernel: fwohci0: Phy 1394a available S400, 2 ports. Sep 9 13:14:01 lm741n kernel: fwohci0: Link S400, max_rec 2048 bytes. Sep 9 13:14:01 lm741n kernel: firewire0: on fwohci0 Sep 9 13:14:01 lm741n kernel: sbp0: on firewire0 Sep 9 13:14:01 lm741n kernel: fwe0: on firewire0 Sep 9 13:14:01 lm741n kernel: if_fwe0: Fake Ethernet address: 5a:4f:c0:ff:ff:ff Sep 9 13:14:01 lm741n kernel: fwe0: Ethernet address: 5a:4f:c0:ff:ff:ff Sep 9 13:14:01 lm741n kernel: fwohci0: Initiate bus reset Sep 9 13:14:01 lm741n kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Sep 9 13:14:01 lm741n kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Sep 9 13:14:01 lm741n kernel: firewire0: bus manager 0 (me) Sep 9 13:14:01 lm741n kernel: pci2: at device 3.0 (no driver attached) Sep 9 13:14:01 lm741n kernel: isab0: at device 31.0 on pci0 Sep 9 13:14:01 lm741n kernel: isa0: on isab0 Sep 9 13:14:01 lm741n kernel: atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 Sep 9 13:14:01 lm741n kernel: ata0: channel #0 on atapci0 Sep 9 13:14:01 lm741n kernel: ata1: channel #1 on atapci0 Sep 9 13:14:01 lm741n kernel: pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff400-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 11 at device 31.5 on pci0 Sep 9 13:14:01 lm741n kernel: pcm0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: pcm0: Sep 9 13:14:01 lm741n kernel: pci0: at device 31.6 (no driver attached) Sep 9 13:14:01 lm741n kernel: cpu0 on motherboard Sep 9 13:14:01 lm741n kernel: orm0: at iomem 0xcf800-0xcffff,0xc0000-0xcf7ff on isa0 Sep 9 13:14:01 lm741n kernel: pmtimer0 on isa0 Sep 9 13:14:01 lm741n kernel: atkbdc0: at port 0x64,0x60 on isa0 Sep 9 13:14:01 lm741n kernel: atkbd0: irq 1 on atkbdc0 Sep 9 13:14:01 lm741n kernel: kbd0 at atkbd0 Sep 9 13:14:01 lm741n kernel: atkbd0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: psm0: irq 12 on atkbdc0 Sep 9 13:14:01 lm741n kernel: psm0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: psm0: model GlidePoint, device ID 0 Sep 9 13:14:01 lm741n kernel: fdc0: ready for input in output Sep 9 13:14:01 lm741n kernel: fdc0: cmd 3 failed at out byte 1 of 3 Sep 9 13:14:01 lm741n kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Sep 9 13:14:01 lm741n kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Sep 9 13:14:01 lm741n kernel: ppc0: FIFO with 16/16/8 bytes threshold Sep 9 13:14:01 lm741n kernel: ppbus0: on ppc0 Sep 9 13:14:01 lm741n kernel: plip0: on ppbus0 Sep 9 13:14:01 lm741n kernel: lpt0: on ppbus0 Sep 9 13:14:01 lm741n kernel: lpt0: Interrupt-driven port Sep 9 13:14:01 lm741n kernel: ppi0: on ppbus0 Sep 9 13:14:01 lm741n kernel: sc0: at flags 0x100 on isa0 Sep 9 13:14:01 lm741n kernel: sc0: VGA <16 virtual consoles, flags=0x300> Sep 9 13:14:01 lm741n kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Sep 9 13:14:01 lm741n kernel: sio0: type 16550A Sep 9 13:14:01 lm741n kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Sep 9 13:14:01 lm741n kernel: sio1: port may not be enabled Sep 9 13:14:01 lm741n kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (port) Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (irq) Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (port) Sep 9 13:14:01 lm741n kernel: unknown: can't assign resources (port) Sep 9 13:14:01 lm741n kernel: Timecounter "TSC" frequency 1698567438 Hz quality 800 Sep 9 13:14:01 lm741n kernel: Timecounters tick every 10.000 msec Sep 9 13:14:01 lm741n kernel: IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled Sep 9 13:14:01 lm741n kernel: cardbus0: Resource not specified in CIS: id=10, size=1000 Sep 9 13:14:01 lm741n kernel: ohci0: mem 0xf6001000-0xf6001fff irq 11 at device 0.0 on cardbus0 Sep 9 13:14:01 lm741n kernel: ohci0: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb3: OHCI version 1.0 Sep 9 13:14:01 lm741n kernel: ad0: 57231MB [116280/16/63] at ata0-master PIO4 Sep 9 13:14:01 lm741n kernel: ATAPI_RESET time = 30us Sep 9 13:14:01 lm741n kernel: acd0: CDRW <_NEC DVD+RW ND-5100A/10AC> at ata1-master PIO4 Sep 9 13:14:01 lm741n kernel: usb3: on ohci0 Sep 9 13:14:01 lm741n kernel: usb3: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub3: 3 ports with 3 removable, self powered Sep 9 13:14:01 lm741n kernel: cardbus0: Resource not specified in CIS: id=10, size=1000 Sep 9 13:14:01 lm741n kernel: ohci1: mem 0xf6002000-0xf6002fff irq 11 at device 0.1 on cardbus0 Sep 9 13:14:01 lm741n kernel: ohci1: [GIANT-LOCKED] Sep 9 13:14:01 lm741n kernel: usb4: OHCI version 1.0 Sep 9 13:14:01 lm741n kernel: usb4: on ohci1 Sep 9 13:14:01 lm741n kernel: usb4: USB revision 1.0 Sep 9 13:14:01 lm741n kernel: uhub4: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 9 13:14:01 lm741n kernel: uhub4: 2 ports with 2 removable, self powered Sep 9 13:14:01 lm741n kernel: cardbus0: Resource not specified in CIS: id=10, size=100 Sep 9 13:14:01 lm741n kernel: cardbus0: at device 0.2 (no driver attached) Sep 9 13:14:01 lm741n kernel: ugen0: Orange Micro iBOT2 Camera, rev 2.00/1.00, addr 2 Sep 9 13:14:01 lm741n kernel: Mounting root from ufs:/dev/ad0s3a Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $ipxrouted_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $kerberos5_server_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $kadmind5_server_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $kpasswdd_server_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $named_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $enable_quotas is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $pflog_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $pf_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $pppoed_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $virecover_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: $timed_enable is not set properly - see rc.conf(5). Sep 9 13:14:01 lm741n root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) Sep 9 13:14:02 lm741n apmd[385]: start Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $bootparamd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n lpd[397]: lpd startup: logging=0 Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $update_motd is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $ntpd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $rarpd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $rtadvd_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $rwhod_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $ibcs2_enable is not set properly - see rc.conf(5). Sep 9 13:14:02 lm741n root: /etc/rc: WARNING: $sysvipc_enable is not set properly - see rc.conf(5). Sep 9 13:14:04 lm741n root: /etc/rc: WARNING: $svr4_enable is not set properly - see rc.conf(5). Sep 9 13:14:04 lm741n root: /etc/rc: WARNING: $jail_enable is not set properly - see rc.conf(5). Sep 9 13:14:04 lm741n root: /etc/rc: WARNING: $ntpdate_enable is not set properly - see rc.conf(5). Sep 9 13:14:34 lm741n login: ROOT LOGIN (root) ON ttyv0 --------------080204040203040204040005-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 21:32: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 E1C6B16A4CE for ; Thu, 9 Sep 2004 21:32:06 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A22543D5E for ; Thu, 9 Sep 2004 21:32:06 +0000 (GMT) (envelope-from error404@cox.net) Received: from [192.168.123.106] (really [68.225.59.143]) by lakermmtao01.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040909213204.SHNN25113.lakermmtao01.cox.net@[192.168.123.106]> for ; Thu, 9 Sep 2004 17:32:04 -0400 Message-ID: <4140CBD3.1010002@cox.net> Date: Thu, 09 Sep 2004 16:32:03 -0500 From: Tom Cage User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: FWD: setrunqueue(): corrupt kq_runq 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, 09 Sep 2004 21:32:07 -0000 Hi Tom, Recent changes to the email setup for the mailing lists (actually all of freebsd.org) has hosed me. I am unable to post this report as my email is rejected saying that it cannot find my hostname. I would appreciate it if you could forward this to the list. Thanks, Sean ------------------------------------------------------------------------ Subject: setrunqueue(): corrupt kq_runq From: Sean McNeil Date: Thu, 09 Sep 2004 11:55:52 -0700 To: freebsd-current@freebsd.org amd64 -CURRENT system has crashed now several times in the last 2 days. Ever since the change to SCHED_4BSD and PREEMPTION. I certainly hope this is fixed before 5.3-RELEASE. Sep 9 11:43:46 server syslogd: kernel boot file is /boot/kernel/kernel Sep 9 11:43:46 server kernel: setrunqueue(): corrupt kq_runq, td= 0xffffff004be8e520 Sep 9 11:43:46 server kernel: panic: deadlock in setrunqueue Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21a90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21aa0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21810 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21820 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21590 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c215a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21310 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21320 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21090 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c210a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20e10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20e20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20b90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20ba0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20910 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20920 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20690 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c206a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20410 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20420 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20190 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c201a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ff10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1ff20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fc90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fca0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fa10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fa20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f790 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f7a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f510 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f520 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f290 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f2a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f010 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f020 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ed90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eda0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1eb10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eb20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e890 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e8a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e610 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e620 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Then a reboot. Sean From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 01:16: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 A027416A4CE for ; Fri, 10 Sep 2004 01:16:51 +0000 (GMT) Received: from smtp02.net-yan.com (smtp02.hgcbroadband.com [210.0.255.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7B7343D39 for ; Fri, 10 Sep 2004 01:16:50 +0000 (GMT) (envelope-from sam.wun@authtec.net) Received: (qmail 65307 invoked from network); 10 Sep 2004 01:16:48 -0000 Received: from unknown (HELO [192.168.4.129]) (samwun@hgcbroadband.com@[221.127.106.234]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 01:16:48 -0000 Message-ID: <4140FF73.7090800@authtec.net> Date: Fri, 10 Sep 2004 09:12:19 +0800 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 Subject: Current crash with db prompt 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, 10 Sep 2004 01:16:51 -0000 Hi, After updated the source dated as (09-09-2004), and finished make buildworkd, and installkernel, the system crashed into a db> prompt. Does anyone had this problem? should I download the source again? I m not sure whether I download the source in a bad time or not.. Thanks Sam From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 03:23: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 BB92E16A4CE for ; Fri, 10 Sep 2004 03:23:46 +0000 (GMT) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E75D43D55 for ; Fri, 10 Sep 2004 03:23:45 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (unknown [211.96.21.195]) by gddsn.org.cn (Postfix) with ESMTP id D1FE738CBE7 for ; Fri, 10 Sep 2004 11:21:56 +0800 (CST) Message-ID: <41411DBC.3070703@gddsn.org.cn> Date: Fri, 10 Sep 2004 11:21:32 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040706 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 Subject: 6.0-CURRENT ppp build failed with NONETGRAPH 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, 10 Sep 2004 03:23:46 -0000 hi,list.build ppp failed with -DNONETGRAPH today.any ideas? follows the error msgs: > # make -DNONETGRAPH > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/acf.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/arp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/async.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/auth.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/bundle.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/cbcp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/ccp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/chap.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/chat.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/command.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/datalink.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/deflate.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/defs.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/exec.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/filter.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/fsm.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/hdlc.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/iface.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/ip.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/ipcp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/ipv6cp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/iplist.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/lcp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/link.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/log.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/lqr.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/main.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/mbuf.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/mp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/ncp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/ncpaddr.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/pap.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/physical.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/pred.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/probe.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/prompt.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/proto.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/route.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/server.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/sig.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/slcompress.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/sync.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/systems.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/tcp.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/tcpmss.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/throughput.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/timer.c > cc -O -pipe -DNONETGRAPH -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -c /usr/src/usr.sbin/ppp/tty.c > /usr/src/usr.sbin/ppp/tty.c:577: warning: unused parameter 'auxfd' > /usr/src/usr.sbin/ppp/tty.c:577: warning: unused parameter 'nauxfd' > /usr/src/usr.sbin/ppp/tty.c:626: warning: unused parameter 'auxfd' > /usr/src/usr.sbin/ppp/tty.c:626: warning: unused parameter 'nauxfd' > *** Error code 1 > > Stop in /usr/src/usr.sbin/ppp. From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 05:54: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 EA69716A4CE for ; Fri, 10 Sep 2004 05:54:01 +0000 (GMT) Received: from mailhub2.uq.edu.au (mailhub2.uq.edu.au [130.102.149.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id D57B343D48 for ; Fri, 10 Sep 2004 05:54:00 +0000 (GMT) (envelope-from t.jago@its.uq.edu.au) Received: from smtp2.uq.edu.au (smtp2.uq.edu.au [130.102.5.53]) by mailhub2.uq.edu.au (8.12.11/8.12.11) with ESMTP id i8A5rxHk046481 for ; Fri, 10 Sep 2004 15:53:59 +1000 (EST) Received: from [130.102.153.111] (bigt.its.uq.edu.au [130.102.153.111]) by smtp2.uq.edu.au (8.12.10/8.12.10) with ESMTP id i8A5rxKa020364 for ; Fri, 10 Sep 2004 15:53:59 +1000 (EST) From: Tony Jago To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1094795639.36147.158.camel@bigt.its.uq.edu.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 15:53:59 +1000 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.43 on UQ Mailhub X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 Subject: Dell 1850 + Perc 4e/Si + FreeBSD 5.3-BETA3 install CD = Panic at boot 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, 10 Sep 2004 05:54:02 -0000 Hi all, Just a quick note to let you know that the FreeBSD 5.3-BETA3 cd panic's a Dell 1850. These machines have the new Perc 4e/Si Raid controller. If the card is in either "RAID Enabled" or "SCSI Enabled" mode in the BIOS the machine panics booting the installation CD. If this Perc 4e card is disabled the CD boots into sysinstall just fine. acd1: CDROM at ata2-slave BIOSPIO Memory modified after free 0xc3c01180(124) val=c3c3f80c @ 0xc3c01198 panic: Most recently used by AFD driver ... db> trace kdb_enter(.. panic(... mtrash_ctor( malloc( cam_periph_alloc( xpt_scan_lun( xpt_action( xpt_scan_bus( .... If anybody wants any further debugging done please let me know. Tony From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 09:35: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 58D0B16A4CF for ; Fri, 10 Sep 2004 09:35:40 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC4743D54 for ; Fri, 10 Sep 2004 09:35:39 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i8A9ZSje012917; Fri, 10 Sep 2004 19:35:28 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) i8A9ZNlZ030017; Fri, 10 Sep 2004 19:35:25 +1000 Date: Fri, 10 Sep 2004 19:35:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: "M. Warner Losh" In-Reply-To: <20040830.124141.44509158.imp@bsdimp.com> Message-ID: <20040910180421.Y1368@epsplex.bde.org> References: <012301c48e25$14924180$84cba8c0@hh.kew.com> <20040830.124141.44509158.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 cc: freebsd-current@freebsd.org cc: ahd@kew.com Subject: Re: PCI SIO devices hog interrupts, cause lock order 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: Fri, 10 Sep 2004 09:35:40 -0000 On Mon, 30 Aug 2004, M. Warner Losh wrote: > In message: <012301c48e25$14924180$84cba8c0@hh.kew.com> > "Andrew H. Derbyshire" writes: > : Basically, any PCI SIO device hogs its interrupt if the PUC device is not > : also in the kernel, and this causes real problems for any environment like > : mine where pulling the modem is not trivial. This seems to be just the old bug that interrupt attributes are wired at bus_setup_intr() time, but that time is too early for at least the INTR_FAST attribute because the best possible wiring depends on the set of devices that is actively using the interrupt. (This set may grow as more devices are attached; it should also shrink as devices are attached, and it should be fully dynamic so that inactive devices don't pessimize the interrupt wiring of active ones.) sio just attempts to set up the interrupt using INTR_FAST because that is best for it. If this fails, then sio tries again without INTR_FAST. The fallback only helps if, if some (non-sio) device on the interrupt can't handle INTR_FAST, then at least one such device is wired to the interrupt before any (not necessarily sio) device asks for the interrupt to be wired as INTR_FAST. Using puc works around the problem by breaking setup of the interrupt using INTR_FAST more deterministically provided PUC_FASTINTR is not used. This depends on the magic and arguably broken ordering of puc and pci-sio attachment -- it depends on puc being attached first, but perhaps pci-sio should be first since it is less generic and more efficient for the small set of hardware that it handles. The cy driver works around the problem in a different way: INTR_FAST is not tried by default, but the CY_PCI_FASTINTR option forces it to be tried first with a fallback to !INTR_FAST in the same way as in sio. Thus the default is fail-safe but pessimal for cy. The default is fail-unsafe for sio mainly for historical reasons. > Does the distributed GENERIC > : kernel have room for the PUC device? Are there side effects that PUC should > : be excluded from GENERIC? > > puc should be in GENERIC, imho. I agree. It is too large due to its sparse data structures, but since the sparse data compresses very well, it doesn't take any more space on boot media than most drivers in GENERIC. Bruce From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 09:38: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 3552D16A4CE; Fri, 10 Sep 2004 09:38:40 +0000 (GMT) Received: from mailbox.rainbownet.com (mailbox.rainbownet.com [213.174.191.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4BD743D5D; Fri, 10 Sep 2004 09:38:38 +0000 (GMT) (envelope-from aturetta@rainbownet.com) Received: from nbangx ([81.208.52.78]) (authenticated user aturetta@rainbownet.com) by rainbownet.com (mailbox.rainbownet.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 36-md50000000041.tmp; Fri, 10 Sep 2004 11:38:05 +0200 Message-ID: <007501c49719$df5bd2d0$1e21a8c0@lan> From: "Angelo Turetta" To: =?iso-8859-1?Q?S=F8ren_Schmidt?= , "Kevin Oberman" References: <20040909202807.1F5295D09@ptavv.es.net> Date: Fri, 10 Sep 2004 11:38:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: aturetta@rainbownet.com X-Spam-Processed: mailbox.rainbownet.com, Fri, 10 Sep 2004 11:38:05 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.208.52.78 X-Return-Path: aturetta@rainbownet.com X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig cc: sos@FreeBSD.ORG Subject: Re: poor ATA disk speed with ICH2 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, 10 Sep 2004 09:38:40 -0000 >----- Original Message ----- >From: "Kevin Oberman" >Sent: Thursday, September 09, 2004 10:28 PM > > While the test is running, the disk being written to "sings" with the > frequency somewhat dependent on the size of the write. On read, I get > silence. When I copy my full disk (if=ad0 of=ad2), I can clearly hear > the sound of the actuator moving the heads constantly toward the end of > the backup. I assume that they are being returned to track 0 on a > repeated basis. This sounds a lot like thermal recalibration seeks, to me. Except it's something modern hardware is supposed to need very rarely, if not at all... Might be the effect of some power-saving setting intruduced in 5.x ? (or maybe the new ATA code is actually so fast it's overheating your disks :-) :-) Angelo Turetta From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 12:14: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 BE6B116A4CF for ; Fri, 10 Sep 2004 12:14:42 +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 53AA243D4C for ; Fri, 10 Sep 2004 12:14:42 +0000 (GMT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from localhost (localhost [127.0.0.1])8FEE53D03E; Fri, 10 Sep 2004 14:14:41 +0200 (CEST) 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 25224-02-16; Fri, 10 Sep 2004 14:14:41 +0200 (CEST) Received: from m2a2.dyndns.org (p508EF060.dip.t-dialin.net [80.142.240.96]) 4883E3D039; Fri, 10 Sep 2004 14:14:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 90213CEA8E; Fri, 10 Sep 2004 14:14:40 +0200 (CEST) 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 11269-04-6; Fri, 10 Sep 2004 14:14:40 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 407C0CE308; Fri, 10 Sep 2004 14:14:40 +0200 (CEST) To: Matthias Andree , "Bjoern A. Zeeb" , Max Laier , freebsd-current@freebsd.org, nakal@web.de In-Reply-To: (Matthias Andree's message of "Mon, 26 Jul 2004 10:48:46 +0200") References: <200407231750.32302.max@love2party.net> From: Matthias Andree Date: Fri, 10 Sep 2004 14:14:40 +0200 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 Subject: Re: xl(4) autonegotiation trouble - ng_pppoe related? 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, 10 Sep 2004 12:14:42 -0000 Matthias Andree writes: > Yes, I do. ppp/ng_pppoe has worked a few weeks ago and I hadn't changed > my configuration for months. FYI: a fix to my problem has been committed as src/sys/pci/if_xl.c r1.180 (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_xl.c) kern/69133 is now closed. (http://www.freebsd.org/cgi/query-pr.cgi?pr=69133) -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 12:54: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 66BA416A4CE for ; Fri, 10 Sep 2004 12:54:40 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1E5343D48 for ; Fri, 10 Sep 2004 12:54:39 +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 i8ACsXFZ041253; Fri, 10 Sep 2004 08:54:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8ACsXGe041250; Fri, 10 Sep 2004 08:54:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 10 Sep 2004 08:54:33 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marian Cerny cc: freebsd-current@freebsd.org Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 12:54:40 -0000 On Fri, 10 Sep 2004, Bjoern A. Zeeb wrote: > On Fri, 10 Sep 2004, Marian Cerny wrote: > > > lock order reversal > > 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 > > 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 > > KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c08bde68,c08beb88,c084ddac) at kdb_backtrace+0x29 > > withness_checkorder(c08adee4,9,c0808137,bb5) at witness_checkorder+0x544 > > _sx_xlock(c08adee4,c0808137,bb5) at _sx_xlock+0x50 > > _vm_map_lock_read(c08adea0,c0808137,bb5,20000004,c16bae6c) at _vm_map_lock_read+0x37 > > vm_map_lookup(ceef9bb8,0,2,ceef9bbc,ceef9bac) at vm_map_lookup+0x28 > > vm_fault(c08adea0,0,2,8,c16b5b00) at vm_fault+0x66 > > trap_pfault(ceef9c80,0,c) at trap_pgault+0xf2 > > trap(18,10,10,0,3b) at trap+0x335 > > calltrap() at calltrap+0x5 > > this first half looks pretty much the same as > http://sources.zabbadoz.net/freebsd/lor.html#031 This lock order reversal is a false positive resulting from a page fault in kernel; the real problem is the NULL pointer dereference below. I've been thinking of tweaking the page fault handler to not even try to process page faults against the first page in the address space in order to generate a more clean panic message... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > 1st 0xc08ec200 ifnet (ifnet) @ sys/net/if.c:1489 > 2nd 0xc46703c8 user map (user map) @ sys/vm/vm_map.c:2994 > > > --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- > > re_rxeof(c177b000) at re_rxeof+0x2ae > > re_intr(c177b000) at re_intr+0xb3 > > ithread_loop(c16bf400,ceef9d48,c16bf400,c05ed66c,0) at ithread_loop+0x124 > > fork_exit(c05ed66c,c16bf400,ceef9d48) at fork_exit+0xa4 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = exceef9d7c, ebp = 0 --- > > -- > 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 Fri Sep 10 13:07: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 96A1316A4CE for ; Fri, 10 Sep 2004 13:07:41 +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 C8EE443D66 for ; Fri, 10 Sep 2004 13:07:40 +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 i8AD7cGJ049519; Fri, 10 Sep 2004 15:07:38 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4141A6F0.7000009@DeepCore.dk> Date: Fri, 10 Sep 2004 15:06:56 +0200 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: Frode Nordahl References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: Promise PDC20267 ATA RAID, poor write performance 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, 10 Sep 2004 13:07:41 -0000 Frode Nordahl wrote: > Hello, >=20 > I have a intel S845WD1-E board with onboard Promise PDC20267 controller= =2E > The system is set up with a P4 2Ghz with 1GB RAM. > The board also has a Intel ICH2, but that's only used by a CDROM. >=20 > Disks connected: > ad4: 39205MB [79656/16/63] at ata2-master UDM= A100 > ad6: 39205MB [79656/16/63] at ata3-master UDM= A100 >=20 > I have them set up in a RAID1 >=20 > I have tried this on FreeBSD 4.10-RELEASE, and 6-CURRENT (from today)=20 > with similar results. >=20 > I also tried with RAID0, and that showed the same results*2, that is,=20 > ca. 7MB/s write instead of 3.5MB/s. Hmm that is "somewhat" on the low side, even with those Maxtors it=20 should be better. I'll try to reproduce here, I should have semilar or even identical HW=20 in the ATA collection in the lab, give me a few days to get it setup... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 13:11: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 6895416A4CE for ; Fri, 10 Sep 2004 13:11:09 +0000 (GMT) Received: from av13-2-sn4.m-sp.skanova.net (av13-2-sn4.m-sp.skanova.net [81.228.10.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 309C043D60 for ; Fri, 10 Sep 2004 13:11:08 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av13-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0AA6437E43; Fri, 10 Sep 2004 15:11:07 +0200 (CEST) Received: from smtp4-1-sn4.m-sp.skanova.net (smtp4-1-sn4.m-sp.skanova.net [81.228.10.181]) by av13-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id EFFF537E42 for ; Fri, 10 Sep 2004 15:11:06 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp4-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 7D4DC37E45 for ; Fri, 10 Sep 2004 15:11:06 +0200 (CEST) Received: (qmail 13238 invoked by uid 1001); 10 Sep 2004 13:11:06 -0000 Date: Fri, 10 Sep 2004 15:11:06 +0200 From: Erik Trulsson To: Angelo Turetta Message-ID: <20040910131105.GA13219@falcon.midgard.homeip.net> Mail-Followup-To: Angelo Turetta , =?iso-8859-1?Q?S=F8ren?= Schmidt , Kevin Oberman , freebsd-current@FreeBSD.ORG, Bjoern Koenig , sos@FreeBSD.ORG References: <20040909202807.1F5295D09@ptavv.es.net> <007501c49719$df5bd2d0$1e21a8c0@lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501c49719$df5bd2d0$1e21a8c0@lan> User-Agent: Mutt/1.5.6i cc: sos@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig cc: =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: Re: poor ATA disk speed with ICH2 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, 10 Sep 2004 13:11:09 -0000 On Fri, Sep 10, 2004 at 11:38:03AM +0200, Angelo Turetta wrote: > >----- Original Message ----- > >From: "Kevin Oberman" > >Sent: Thursday, September 09, 2004 10:28 PM > > > > While the test is running, the disk being written to "sings" with the > > frequency somewhat dependent on the size of the write. On read, I get > > silence. When I copy my full disk (if=ad0 of=ad2), I can clearly hear > > the sound of the actuator moving the heads constantly toward the end of > > the backup. I assume that they are being returned to track 0 on a > > repeated basis. > > This sounds a lot like thermal recalibration seeks, to me. Except it's > something modern hardware is supposed to need very rarely, if not at all... Very rarely *if* there is sufficient cooling - if the disk becomes too warm it is needed. One harddisk I have was not only quite loud, but also slower than it ought to have been. After I installed an extra fan in the case blowing air directly at the disk, it not only became much quieter, but also noticeable faster. (The airflow around the disk was fairly bad before that.) I assume that the extra noise and slowness was simply thermal recalibration trying to compensate for the disk being somewhat overheated. > Might be the effect of some power-saving setting intruduced in 5.x ? > (or maybe the new ATA code is actually so fast it's overheating your disks > :-) :-) > > Angelo Turetta -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 13:24: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 17A5C16A4CE for ; Fri, 10 Sep 2004 13:24:30 +0000 (GMT) Received: from dedi.fuckner.net (fuckner.net [81.169.152.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A77943D6D for ; Fri, 10 Sep 2004 13:24:29 +0000 (GMT) (envelope-from hscholz@raisdorf.net) Received: from localhost (localhost [127.0.0.1]) by dedi.fuckner.net (Postfix) with ESMTP id 29DCBC0D6 for ; Fri, 10 Sep 2004 15:24:28 +0200 (CEST) Received: from dedi.fuckner.net ([127.0.0.1]) by localhost (dedi.fuckner.net [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 79248-10 for ; Fri, 10 Sep 2004 15:24:26 +0200 (CEST) Received: from [192.168.1.101] (pD95D37BA.dip.t-dialin.net [217.93.55.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dedi.fuckner.net (Postfix) with ESMTP id AD634C0D4 for ; Fri, 10 Sep 2004 15:24:25 +0200 (CEST) Message-ID: <4141AB09.3090508@raisdorf.net> Date: Fri, 10 Sep 2004 15:24:25 +0200 From: Hendrik Scholz User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at fuckner.net Subject: dcons(4) console for jails 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, 10 Sep 2004 13:24:30 -0000 Hi! I've been thinking for this for a few days and eventually had the time to have a first look at it. What I'd like to do is basicly running '/usr/libexec/getty dcons dcons' inside a jail and allow the host system to access the console. It's easy to do using the dconschat TCP feature (dconschat -rTC 12345) and using telnet to connect but I don't like the idea of allowing telnet connections from remote systems to important services. So my solution (only had a quick look at the code) should work like this: - write a firewire-like extension for dconschat, i.e. 'dcons -j myjail' that connects to the console on the local jail 'myjail' - build a miniature version of /etc/ttys in the jail to allow configuration. - make sure the comserver-con port works with this extension :) Are there any comments or recommondations? Thanks, Hendrik -- Hendrik Scholz - - http://www.wormulon.net/ drag me, drop me - treat me like an object From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 13:28: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 0FE3E16A4CE for ; Fri, 10 Sep 2004 13:28:55 +0000 (GMT) Received: from thunderbird.etv.net (thunderbird.etv.net [208.14.190.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4777D43D5D for ; Fri, 10 Sep 2004 13:28:54 +0000 (GMT) (envelope-from lists@efinley.com) Received: from [205.161.203.50] (helo=science1) by thunderbird.etv.net with smtp (Exim 4.34 (FreeBSD)) id 1C5lSO-000F0A-NR for freebsd-current@freebsd.org; Fri, 10 Sep 2004 07:28:53 -0600 Message-ID: <06c601c4973a$1d1c5570$32cba1cd@science1> From: "Elliot Finley" To: Date: Fri, 10 Sep 2004 07:28:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Beta3 core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Elliot Finley List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 13:28:55 -0000 ASUS P4P800 (if it matters) with a fresh ports cvsup, after rebuilding INDEX. If I do a 'portsdb -fu', I get a core dump. This is consistent. It happens every time, in the same place. [Updating the portsdb in /usr/ports ... - 11736 port entries found .........1000.........2000.........3000.........4000.........5000.........60 00.........7000.........8000..../usr/local/lib/ruby/site_ruby/1.8/portsdb.rb :587: [BUG] Bus Error ruby 1.8.2 (2004-07-29) [i386-freebsd5] Abort (core dumped) Is anyone else seeing this? DMESG follows: 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-BETA3 #12: Fri Sep 10 07:16:09 MDT 2004 root@oregon.etv.net:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2598.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) avail memory = 1040351232 (992 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface 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 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0xef00-0xef1f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xef20-0xef3f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xef40-0xef5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xef80-0xef9f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) sk0: on skc0 sk0: Ethernet address: 00:0c:6e:54:4b:25 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto atapci0: port 0xdc00-0xdc7f,0xdfa0-0xdfaf,0xdf00-0xdf3f mem 0xfeac0000-0xfeadffff,0xfeafb000-0xfeafbfff irq 21 at device 9.0 on pci2 atapci0: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 ata5: channel #3 on atapci0 fxp0: port 0xde80-0xdebf mem 0xfeaa0000-0xfeabffff,0xfeafa000-0xfeafafff irq 23 at device 11.0 on pci2 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:d1:f7:ad isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 atapci2: port 0xef60-0xef6f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 irq 18 at device 31.2 on pci0 ata6: channel #0 on atapci2 ata7: channel #1 on atapci2 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) acpi_button0: on acpi0 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, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2e8-0x2ef irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 orm0: at iomem 0xc8000-0xc97ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2598760676 Hz quality 800 Timecounters tick every 10.000 msec ATAPI_RESET time = 80us acd0: CDROM at ata0-master UDMA33 ad12: 76319MB [155061/16/63] at ata6-master SATA150 ad14: 76319MB [155061/16/63] at ata7-master SATA150 Mounting root from ufs:/dev/ad12s1a pid 511 (ruby18), uid 0: exited on signal 6 (core dumped) From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 13:31: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 08C8716A4CE; Fri, 10 Sep 2004 13:31:35 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84DBC43D1F; Fri, 10 Sep 2004 13:31:34 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [198.82.175.68] (hc652af44.dhcp.vt.edu [198.82.175.68]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id i8ADVSX21370 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Fri, 10 Sep 2004 09:31:29 -0400 In-Reply-To: <24D02CEA-022C-11D9-870B-000A95C4D7BC@FreeBSD.org> References: <20040905124526.F15143@midi.ihme.net> <24D02CEA-022C-11D9-870B-000A95C4D7BC@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Fri, 10 Sep 2004 09:31:23 -0400 To: Suleiman Souhlal X-Mailer: Apple Mail (2.619) cc: freebsd-current@FreeBSD.org cc: =?ISO-8859-1?Q?Markus_H=E4stbacka?= Subject: Re: Sound performance problems in FreeBSD 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, 10 Sep 2004 13:31:35 -0000 Hi, > FYI, after a few IRC discussions with Markus, we've discovered that > turning off the memory part of Gnome's System Monitor applet, would > get rid of the skips. I believe the problem is that both sysctl and > the sound drivers are Giant-locked, and so there is some contention. > An easy way to reproduce these > skips is to run `while true; do sysctl vm.vmtotal; done`, while > playing an mp3. In case you are interested, we've confirmed that Giant contention is the problem: Applying the hack at http://people.freebsd.org/~ssouhlal/giantless-sysctl.diff , which removes Giant from sysctl, seems to stop the skips when running the above command. Of course, it doesn't prevent skips from happening during heavy file operation, which would probably require VFS locking (or of course, locking the sound drivers, which is probably easier), and maybe, a better disk scheduler. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 13:43: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 F265E16A4CE for ; Fri, 10 Sep 2004 13:43:27 +0000 (GMT) Received: from raadradd.homeunix.org (bvy151.neoplus.adsl.tpnet.pl [83.29.222.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F8BD43D39 for ; Fri, 10 Sep 2004 13:43:27 +0000 (GMT) (envelope-from radek@raadradd.com) Received: by raadradd.homeunix.org (Postfix, from userid 1001) id 9E22FA562; Fri, 10 Sep 2004 15:43:30 +0200 (CEST) Date: Fri, 10 Sep 2004 15:43:30 +0200 From: Radek Kozlowski To: Elliot Finley Message-ID: <20040910134330.GC99118@werd> References: <06c601c4973a$1d1c5570$32cba1cd@science1> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <06c601c4973a$1d1c5570$32cba1cd@science1> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Beta3 core dump 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, 10 Sep 2004 13:43:28 -0000 On Fri, Sep 10, 2004 at 07:28:52AM -0600, Elliot Finley wrote: > ASUS P4P800 (if it matters) > > with a fresh ports cvsup, after rebuilding INDEX. If I do a 'portsdb -fu', > I get a core dump. This is consistent. It happens every time, in the same > place. > > [Updating the portsdb in /usr/ports ... - 11736 port > entries found > .........1000.........2000.........3000.........4000.........5000.........60 > 00.........7000.........8000..../usr/local/lib/ruby/site_ruby/1.8/portsdb.rb > :587: [BUG] Bus Error > ruby 1.8.2 (2004-07-29) [i386-freebsd5] > > Abort (core dumped) > > > Is anyone else seeing this? Everyday, man. http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/016006.html http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/015902.html http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/015922.html http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/015925.html a.s.o. -Radek From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 13:56: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 5A24916A4CE for ; Fri, 10 Sep 2004 13:56:53 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94F3743D39 for ; Fri, 10 Sep 2004 13:56:52 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 4C8D150C29 for ; Fri, 10 Sep 2004 22:56:51 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 1EFCA50C27 for ; Fri, 10 Sep 2004 22:56:49 +0900 (JST) Date: Fri, 10 Sep 2004 22:56:49 +0900 Message-ID: <7m8ybip6qm.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: In-Reply-To: <06c601c4973a$1d1c5570$32cba1cd@science1> References: <06c601c4973a$1d1c5570$32cba1cd@science1> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: Re: Beta3 core dump 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, 10 Sep 2004 13:56:53 -0000 At Fri, 10 Sep 2004 07:28:52 -0600, Elliot Finley wrote: > with a fresh ports cvsup, after rebuilding INDEX. If I do a 'portsdb -fu', > I get a core dump. This is consistent. It happens every time, in the same > place. > > [Updating the portsdb in /usr/ports ... - 11736 port > entries found > ........1000.........2000.........3000.........4000.........5000.........60 > 00.........7000.........8000..../usr/local/lib/ruby/site_ruby/1.8/portsdb.rb > :587: [BUG] Bus Error > ruby 1.8.2 (2004-07-29) [i386-freebsd5] > > Abort (core dumped) Could you please trying with this patch? Index: lib/libc/db/btree/bt_split.c =================================================================== RCS file: /home/ncvs/src/lib/libc/db/btree/bt_split.c,v retrieving revision 1.5 diff -u -r1.5 bt_split.c --- lib/libc/db/btree/bt_split.c 16 Feb 2003 17:29:09 -0000 1.5 +++ lib/libc/db/btree/bt_split.c 10 Sep 2004 13:52:38 -0000 @@ -361,6 +361,8 @@ r->nextpg = h->nextpg; r->prevpg = h->pgno; r->flags = h->flags & P_TYPE; + /* XXX: Workaround for broken page data access. */ + r->linp[0] = 0xffff; /* * If we're splitting the last page on a level because we're appending -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 14:28: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 1E03516A4CE for ; Fri, 10 Sep 2004 14:28:03 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE65C43D48 for ; Fri, 10 Sep 2004 14:28:02 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 158C950BEE for ; Fri, 10 Sep 2004 23:28:02 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 7F00B50B8F for ; Fri, 10 Sep 2004 23:28:00 +0900 (JST) Date: Fri, 10 Sep 2004 23:28:00 +0900 Message-ID: <7m7jr2p5an.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: ktrace for linux binary 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, 10 Sep 2004 14:28:03 -0000 On my current box, ktrace(1)/kdump(1) shows FreeBSD sysctl number. But I remember someone posted to this list with kdump output including Linux sysctl number decoded. Is there a magic for this? ----- % ktrace ./linux-ls % kdump ... 20417 linux-ls CALL mmap(0x3,0xbfbfd7e4,0x28069560) 20417 linux-ls RET mmap 0 20417 linux-ls CALL dup2(0xbfbfd6c4) 20417 linux-ls RET dup2 0x28070000 20417 linux-ls CALL old.recvfrom(0x2819c000,0x9628,0) 20417 linux-ls RET old.recvfrom 0 20417 linux-ls CALL dup2(0xbfbfd6c4) 20417 linux-ls RET dup2 0x2819c000 20417 linux-ls CALL dup2(0xbfbfd6c4) 20417 linux-ls RET dup2 0x281a2000 20417 linux-ls CALL close(0x3) 20417 linux-ls RET close 0 20417 linux-ls CALL #91(0x2806a000,0x1a02) 20417 linux-ls RET #91 0 ... -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 14:38: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 0A66D16A4CE; Fri, 10 Sep 2004 14:38:16 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id E12C843D5E; Fri, 10 Sep 2004 14:38:15 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 10 Sep 2004 07:38:15 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 39FD15D04; Fri, 10 Sep 2004 07:38:15 -0700 (PDT) To: "Angelo Turetta" In-reply-to: Your message of "Fri, 10 Sep 2004 11:38:03 +0200." <007501c49719$df5bd2d0$1e21a8c0@lan> Date: Fri, 10 Sep 2004 07:38:15 -0700 From: "Kevin Oberman" Message-Id: <20040910143815.39FD15D04@ptavv.es.net> cc: freebsd-current@FreeBSD.ORG cc: Bjoern Koenig cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= cc: sos@FreeBSD.ORG Subject: Re: poor ATA disk speed with ICH2 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, 10 Sep 2004 14:38:16 -0000 > From: "Angelo Turetta" > Date: Fri, 10 Sep 2004 11:38:03 +0200 > > >----- Original Message ----- > >From: "Kevin Oberman" > >Sent: Thursday, September 09, 2004 10:28 PM > > > > While the test is running, the disk being written to "sings" with the > > frequency somewhat dependent on the size of the write. On read, I get > > silence. When I copy my full disk (if=ad0 of=ad2), I can clearly hear > > the sound of the actuator moving the heads constantly toward the end of > > the backup. I assume that they are being returned to track 0 on a > > repeated basis. > > This sounds a lot like thermal recalibration seeks, to me. Except it's > something modern hardware is supposed to need very rarely, if not at all... > Might be the effect of some power-saving setting intruduced in 5.x ? > (or maybe the new ATA code is actually so fast it's overheating your disks > :-) :-) Recals should take much longer than what I'm seeing. I have not dealt with disk innards since back in SMD days, but back then a recal was a very slow operation. These are fast. It is causing only about a 40% drop in performance and only for writes, not reads. I have an idea that, since the actuator activity is not with every write but is very consistent, that it is happening only when the drive switches tracks. Instead of just moving from one track to the next (which is such a slight head movement that it is almost impossible to hear), it is jumping back and forth between tracks. By track, I mean physical cylinders on the drive. Because there is so much more data on outer tracks, that would account for the decrease in the frequency of the tone as the heads move out and the fact that it transitions from a tone to pulses as the disk copy nears its conclusion. It may even be some oddity in dd(1) and not the system, at all. Of course, this does nothing to explain what Bjoern saw with bonnie. That is software that has little in common with dd(1). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 15:01: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 9178C16A4CE for ; Fri, 10 Sep 2004 15:01:23 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04BE543D58 for ; Fri, 10 Sep 2004 15:01:23 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i8AF1LhI039008; Fri, 10 Sep 2004 10:01:21 -0500 (CDT) (envelope-from dan) Date: Fri, 10 Sep 2004 10:01:21 -0500 From: Dan Nelson To: Jun Kuriyama Message-ID: <20040910150120.GH5008@dan.emsphone.com> References: <7m7jr2p5an.wl@black.imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7m7jr2p5an.wl@black.imgsrc.co.jp> X-OS: FreeBSD 5.3-BETA3 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Current Subject: Re: ktrace for linux binary 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, 10 Sep 2004 15:01:23 -0000 In the last episode (Sep 10), Jun Kuriyama said: > On my current box, ktrace(1)/kdump(1) shows FreeBSD sysctl number. > But I remember someone posted to this list with kdump output > including Linux sysctl number decoded. > > Is there a magic for this? Install the devel/linux_kdump port. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 16:05: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 961FC16A4CE for ; Fri, 10 Sep 2004 16:05:37 +0000 (GMT) Received: from oasis.uptsoft.com (oasis.uptsoft.com [217.20.165.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9228F43D39 for ; Fri, 10 Sep 2004 16:05:36 +0000 (GMT) (envelope-from devnull@oasis.uptsoft.com) Received: (from devnull@localhost) by oasis.uptsoft.com (8.11.6/linuxconf) id i8AG5Z127671 for freebsd-current@freebsd.org; Fri, 10 Sep 2004 19:05:35 +0300 Date: Fri, 10 Sep 2004 19:05:35 +0300 From: Sergey Lyubka To: freebsd-current@freebsd.org Message-ID: <20040910190535.A27190@oasis.uptsoft.com> 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.2.5.1i Subject: big MD_ROOT_SIZE : BTX 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: Fri, 10 Sep 2004 16:05:37 -0000 I buit a kernel, with embedded MFS, MD_ROOT_SIZE was 8 Megs. Kernel booted and worked fine. After increasing MD_ROOT_SIZE to 16 Megs, BTX prints a hexdump and freezes. A dump looks like this (I've taken first line only) int=0000000d err=0000e14c efl=0010006 eip=0eff30c4 ... BTX halted Any ideas how to fix this ? From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 16:12: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 3B31416A4CE for ; Fri, 10 Sep 2004 16:12:13 +0000 (GMT) Received: from oasis.uptsoft.com (oasis.uptsoft.com [217.20.165.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4527B43D5A for ; Fri, 10 Sep 2004 16:12:12 +0000 (GMT) (envelope-from devnull@oasis.uptsoft.com) Received: (from devnull@localhost) by oasis.uptsoft.com (8.11.6/linuxconf) id i8AGCB427973 for freebsd-current@freebsd.org; Fri, 10 Sep 2004 19:12:11 +0300 Date: Fri, 10 Sep 2004 19:12:11 +0300 From: Sergey Lyubka To: freebsd-current@freebsd.org Message-ID: <20040910191211.C27190@oasis.uptsoft.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20040910190535.A27190@oasis.uptsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040910190535.A27190@oasis.uptsoft.com>; from devnull@uptsoft.com on Fri, Sep 10, 2004 at 07:05:35PM +0300 X-OS: FreeBSD 4.5-STABLE Subject: Re: big MD_ROOT_SIZE : BTX 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: Fri, 10 Sep 2004 16:12:13 -0000 Forgot to mention, it was latest 5.3 On Fri, Sep 10, 2004 at 07:05:35PM +0300, Sergey Lyubka wrote: > I buit a kernel, with embedded MFS, MD_ROOT_SIZE was 8 Megs. > Kernel booted and worked fine. From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 16:49: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 4D30F16A4CE for ; Fri, 10 Sep 2004 16:49:23 +0000 (GMT) Received: from zephon.secspace.de (zephon.secspace.de [62.75.136.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBD4543D46 for ; Fri, 10 Sep 2004 16:49:22 +0000 (GMT) (envelope-from ml@ps102.de) Received: from ariel.office.volker.de (p50817A3B.dip.t-dialin.net [80.129.122.59]) by zephon.secspace.de (Postfix) with ESMTP id 36C176EB20; Fri, 10 Sep 2004 18:49:20 +0200 (CEST) Date: Fri, 10 Sep 2004 18:49:19 +0200 From: Volker Kindermann To: Rob Message-ID: <20040910184919.42dd4416@ariel.office.volker.de> In-Reply-To: <4140BF50.2080700@comcast.net> References: <4140BF50.2080700@comcast.net> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current Subject: Re: warning messages from root mount until login, also my rc.conf file 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, 10 Sep 2004 16:49:23 -0000 Hi Rob, > I can actually get even more warning messages if I delay logging in. > For example, sendmail claims it can't find a socket and comes back with > a multitude of warnings. In this particular case, just wanted to show a > few examples. could it be that /etc/defaults/rc.conf is broken, i.e. has wrong line-brakes? Did you edit it with a Windows-PC? If yes, please check if the file is still ascii (for example, if Ctrl+G in vi shows [dos] then you have the culprit). Besides of that: did you change the kernel? Do the same warnings appear with GENERIC? -volker From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:09: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 883CE16A4CE for ; Fri, 10 Sep 2004 17:09:19 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60AA243D3F for ; Fri, 10 Sep 2004 17:09:19 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 19493 invoked from network); 10 Sep 2004 17:09:18 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 17:09:18 -0000 Received: from hydrogen.funkthat.com (yjgxwf@localhost.funkthat.com [127.0.0.1])i8AH9GuU010034; Fri, 10 Sep 2004 10:09:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8AH9EYQ010033; Fri, 10 Sep 2004 10:09:14 -0700 (PDT) Date: Fri, 10 Sep 2004 10:09:14 -0700 From: John-Mark Gurney To: Marian Cerny Message-ID: <20040910170913.GT72089@funkthat.com> Mail-Followup-To: Marian Cerny , "Bjoern A. Zeeb" , freebsd-current@freebsd.org References: <20040907163133.GA24426@artax.karlin.mff.cuni.cz> <20040908133452.GA11639@artax.karlin.mff.cuni.cz> <20040910102211.GA15808@artax.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910102211.GA15808@artax.karlin.mff.cuni.cz> 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: "Bjoern A. Zeeb" cc: freebsd-current@freebsd.org Subject: Re: LOR (re0 and user map) + PANIC 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: Fri, 10 Sep 2004 17:09:19 -0000 Marian Cerny wrote this message on Fri, Sep 10, 2004 at 12:22 +0200: > Heh, I noticed one more LOR. This one happens when I turn the laptop off > using 'halt -p' after syncing disks. It's *hand*-rewritten, because the > laptop turned itself off after 10 seconds, despite the fact, that I was > inside kernel debugger (I took a shot with my digital photo camera). > > lock order reversal > 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 > 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 What version of if_re.c are you running? neither RELENG_5 nor HEAD has a lock on line 1752. -- 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 Fri Sep 10 17:15: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 E0AC116A4CE for ; Fri, 10 Sep 2004 17:15:33 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91AC543D49 for ; Fri, 10 Sep 2004 17:15:33 +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 i8AHFRFD045139; Fri, 10 Sep 2004 13:15:27 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8AHFQ4W045136; Fri, 10 Sep 2004 13:15:26 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 10 Sep 2004 13:15:26 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John-Mark Gurney In-Reply-To: <20040910170913.GT72089@funkthat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Marian Cerny cc: "Bjoern A. Zeeb" cc: freebsd-current@freebsd.org Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 17:15:34 -0000 On Fri, 10 Sep 2004, John-Mark Gurney wrote: > Marian Cerny wrote this message on Fri, Sep 10, 2004 at 12:22 +0200: > > Heh, I noticed one more LOR. This one happens when I turn the laptop off > > using 'halt -p' after syncing disks. It's *hand*-rewritten, because the > > laptop turned itself off after 10 seconds, despite the fact, that I was > > inside kernel debugger (I took a shot with my digital photo camera). > > > > lock order reversal > > 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 > > 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 > > What version of if_re.c are you running? neither RELENG_5 nor HEAD has > a lock on line 1752. While this would be useful to know, the actual bug (per my earlier e-mail) is a NULL pointer deref: > > --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- > > re_rxeof(c177b000) at re_rxeof+0x2ae It would be very useful to know the revision of the file, as well as what line in the code re_rxeof+0x2ae is. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:17: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 B754416A4CE for ; Fri, 10 Sep 2004 17:17:18 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45D1F43D41 for ; Fri, 10 Sep 2004 17:17:18 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i8AHHGWR044322 for ; Sat, 11 Sep 2004 02:17:16 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 11 Sep 2004 02:17:16 +0900 (JST) Message-Id: <200409101717.i8AHHGWR044322@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.4; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Sat, 11 Sep 2004 02:17:17 +0900 (JST) Subject: PANIC: sym(4) didn't MODULE_DEPEND cam(4). 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, 10 Sep 2004 17:17:18 -0000 I found a problem. sym(4) module didn't MODULE_DEPEND on cam(4). So modulaized sym(4) will be panic on boot with following message. - - - - - - - - - - - - - - - - - - - - - - - - - - - (snip) link_elf: symbol xpt_print_path undefined KLD file sym.ko - could not finalize loading kernel trap 12 with interrupts disabled (snip) - - - - - - - - - - - - - - - - - - - - - - - - - - - I made a patch to fix this problem. In my environment, this looks good works. Anyone, please commit following patch. Index: sym_hipd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v retrieving revision 1.48 diff -u -r1.48 sym_hipd.c --- sym_hipd.c 17 Mar 2004 17:50:45 -0000 1.48 +++ sym_hipd.c 10 Sep 2004 17:10:34 -0000 @@ -8501,6 +8501,7 @@ static devclass_t sym_devclass; DRIVER_MODULE(sym, pci, sym_pci_driver, sym_devclass, 0, 0); +MODULE_DEPEND(sym, cam, 1, 1, 1); static struct sym_pci_chip sym_pci_dev_table[] = { From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17: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 B067816A4CE for ; Fri, 10 Sep 2004 17:18:12 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5476D43D49 for ; Fri, 10 Sep 2004 17:18:12 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i8AHIBJt027879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2004 13:18:11 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8AHI6jm060078; Fri, 10 Sep 2004 13:18:06 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16705.57806.550902.483858@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 13:18:06 -0400 (EDT) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: witness oddity 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, 10 Sep 2004 17:18:12 -0000 I'm trying to figure out what witness is complaining about in my (out of tree) driver code: lock order reversal 1st 0xe672baf0 MX foo mutex (MX foo mutex) @ /home/gallatin/mx/tiki/driver/freebsd/../common/mx_common.c:80 2nd 0xc1c6f878 user map (user map) @ vm/vm_map.c:2994 If I call copyout() holding one of my mutexes, it will always complain about a LOR, even if the mutex is freshly initiated: { struct mtx foo; bzero(&foo, sizeof(foo)); mtx_init(&foo, "MX foo mutex", NULL, MTX_DEF); mtx_lock(&foo); /* hacky copyout which should trigger vm_fault() */ mx_copyout(&status, 1, 4); mtx_unlock(&foo); mtx_destroy(&foo); } Is this happening because the vm_map "user map" is an sx lock? Does this imply that you can't acquire an sx lock while holding a mutex? Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:25: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 2E81A16A4CE for ; Fri, 10 Sep 2004 17:25:17 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id F38FA43D4C for ; Fri, 10 Sep 2004 17:25:16 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 4663 invoked from network); 10 Sep 2004 17:25:16 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 17:25:16 -0000 Received: from hydrogen.funkthat.com (hsrqxa@localhost.funkthat.com [127.0.0.1])i8AHPFuU010406; Fri, 10 Sep 2004 10:25:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8AHPFhM010405; Fri, 10 Sep 2004 10:25:15 -0700 (PDT) Date: Fri, 10 Sep 2004 10:25:15 -0700 From: John-Mark Gurney To: Andrew Gallatin Message-ID: <20040910172515.GU72089@funkthat.com> Mail-Followup-To: Andrew Gallatin , freebsd-current@freebsd.org References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16705.57806.550902.483858@grasshopper.cs.duke.edu> 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: freebsd-current@freebsd.org Subject: Re: witness oddity 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: Fri, 10 Sep 2004 17:25:17 -0000 Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400: > If I call copyout() holding one of my mutexes, it will always complain > about a LOR, even if the mutex is freshly initiated: Calling copyout while holding a mutex is not allowed... If the page isn't in memory, it could take many seconds for the page to be swapped back in during which time your mutex will continue to be held. -- 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 Fri Sep 10 17:26: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 3878116A4CF; Fri, 10 Sep 2004 17:26:25 +0000 (GMT) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDBC243D41; Fri, 10 Sep 2004 17:26:24 +0000 (GMT) (envelope-from cernm0bm@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 10663) id 78C66561C; Fri, 10 Sep 2004 19:26:23 +0200 (CEST) Date: Fri, 10 Sep 2004 19:26:23 +0200 From: Marian Cerny To: Robert Watson Message-ID: <20040910172623.GA1111@artax.karlin.mff.cuni.cz> References: <20040910170913.GT72089@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: "Bjoern A. Zeeb" cc: John-Mark Gurney cc: freebsd-current@freebsd.org Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 17:26:25 -0000 On 2004-09-10 13:15 -0400, Robert Watson wrote: > > On Fri, 10 Sep 2004, John-Mark Gurney wrote: > > > Marian Cerny wrote this message on Fri, Sep 10, 2004 at 12:22 +0200: > > > Heh, I noticed one more LOR. This one happens when I turn the laptop off > > > using 'halt -p' after syncing disks. It's *hand*-rewritten, because the > > > laptop turned itself off after 10 seconds, despite the fact, that I was > > > inside kernel debugger (I took a shot with my digital photo camera). > > > > > > lock order reversal > > > 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 > > > 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 > > > > What version of if_re.c are you running? neither RELENG_5 nor HEAD has > > a lock on line 1752. It is v 1.28 from BETA3. 1752: RL_LOCK(sc); > While this would be useful to know, the actual bug (per my earlier e-mail) > is a NULL pointer deref: > > > > --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- > > > re_rxeof(c177b000) at re_rxeof+0x2ae > > It would be very useful to know the revision of the file, as well as what > line in the code re_rxeof+0x2ae is. Is there any way how to find it out? re_rxoef() is called 4 times in that file. -- Marian Cerny Jabber: jojo@njs.netlab.cz [ UNIX is user friendly. It's just selective about who its friends are. ] From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:32: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 108BE16A4CE for ; Fri, 10 Sep 2004 17:32:53 +0000 (GMT) Received: from email12.aon.at (WARSL404PIP1.highway.telekom.at [195.3.96.112]) by mx1.FreeBSD.org (Postfix) with SMTP id E827743D2D for ; Fri, 10 Sep 2004 17:32:51 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 559526 invoked from network); 10 Sep 2004 17:32:50 -0000 Received: from n748p028.dipool.highway.telekom.at (HELO ?212.183.103.124?) ([212.183.103.124]) (envelope-sender ) by email12.aon.at (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 17:32:50 -0000 From: Stefan Ehmann To: current@freebsd.org Content-Type: text/plain Message-Id: <1094837567.942.9.camel@taxman> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 19:32:47 +0200 Content-Transfer-Encoding: 7bit Subject: rl0: watchdog timeout 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, 10 Sep 2004 17:32:53 -0000 I get rl0: watchdog timeout on a machine where i track RELENG_5. The problem goes away if I disable acpi. It seems that this was fixed for a couple of other people. cvsupped today again but the problem still exists for me. Here is the verbose 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 5.3-BETA3 #2: Fri Sep 10 15:11:12 CEST 2004 Shoe@yesterday.pepperland:/usr/obj/usr/src/sys/YESTERDAY WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0896000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc0896200. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08962ac. Calibrating clock(s) ... i8254 clock: 1193209 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 651484460 Hz CPU: Intel Pentium III (651.48-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387f9ff real memory = 402587648 (383 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x00000000178fffff, 382562304 bytes (93399 pages) avail memory = 384270336 (366 MB) bios32: Found BIOS32 Service Directory header at 0xc00fad40 bios32: Entry = 0xfb240 (c00fb240) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb270 pnpbios: Found PnP BIOS data at 0xc00fbf80 pnpbios: Entry = f0000:bfa8 Rev = 1.0 Other BIOS signatures found: io: null: random: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80003840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06911106) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fde60 PCI-Only Interrupts: 5 10 11 Location Bus Device Pin Link IRQs slot 1 0 9 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 7 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x05 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) ACPI timer looks BAD min = 1, max = 6, width = 5 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 acpi link get: empty IRQ resource ACPI PCI link initial configuration: \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.9.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.9.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.9.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.9.3 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.10.0 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.10.1 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.10.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.10.3 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.11.0 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.11.1 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.11.2 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.11.3 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.12.0 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.12.1 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.12.2 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.12.3 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.13.1 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.7.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.1.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.1.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 0+ low,level,sharable 0.1.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.1.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base d8000000, size 26, enabled found-> vendor=0x1106, dev=0x0691, revid=0x44 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x8598, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0596, revid=0x23 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000e000, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x10 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000e400, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.ISA_.LNKD) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 145173): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 280 280 330 5280 5280 5280 5280 5280 50280 50280100280 \\_SB_.PCI0.ISA_.LNKB (references 7, priority 145173): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 280 280 330 5280 5280 5280 5280 5280 50280 50280100280 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 145173): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 280 280 330 5280 5280 5280 5280 5280 50280 50280100280 \\_SB_.PCI0.ISA_.LNKD (references 7, priority 145173): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 280 280 330 5280 5280 5280 5280 5280 50280 50280100280 pcib0: slot 7 INTD routed to irq 10 via \\_SB_.PCI0.ISA_.LNKD found-> vendor=0x1106, dev=0x3038, revid=0x11 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3050, revid=0x30 bus=0, slot=7, func=3 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000e800, size 8, enabled map[14]: type 1, range 32, base df000000, size 8, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.ISA_.LNKB) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 147178): interrupts: 11 5 10 12 7 6 4 3 15 14 1 penalty: 560 610 630 5560 5560 5560 5560 5560 50560 50560100560 \\_SB_.PCI0.ISA_.LNKB (references 7, priority 147178): interrupts: 11 5 10 12 7 6 4 3 15 14 1 penalty: 560 610 630 5560 5560 5560 5560 5560 50560 50560100560 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 147178): interrupts: 11 5 10 12 7 6 4 3 15 14 1 penalty: 560 610 630 5560 5560 5560 5560 5560 50560 50560100560 pcib0: slot 10 INTA routed to irq 5 via \\_SB_.PCI0.ISA_.LNKB found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 map[10]: type 4, range 32, base 0000ec00, size 8, enabled pcib0: matched entry for 0.13.INTA (src \\_SB_.PCI0.ISA_.LNKD) pcib0: slot 13 INTA is already routed to irq 10 found-> vendor=0x13f6, dev=0x0111, revid=0x10 bus=0, slot=13, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xd8000000-0xdbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xd8000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xdc000000-0xddffffff pcib1: prefetched decode 0xd0000000-0xd7ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base dc000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xdc000000-0xdcffffff map[14]: type 3, range 32, base d0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xd0000000-0xd7ffffff pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.ISA_.LNKA) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 149182): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 840 910 960 5840 5840 5840 5840 5840 50840 50840100840 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 149182): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 840 910 960 5840 5840 5840 5840 5840 50840 50840100840 pcib0: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.ISA_.LNKA pcib1: slot 0 INTA is routed to irq 11 found-> vendor=0x10de, dev=0x0111, revid=0xb2 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe000 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0xd0 err=0x00 lsb=0x0e msb=0x00 ata1-master: stat=0xd0 err=0x00 lsb=0x0e msb=0x00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=10 devices=0xc ata1: [MPSAFE] uhci0: port 0xe400-0xe41f irq 10 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe400 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 pci0: at device 7.3 (no driver attached) rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe800 rl0: port 0xe800-0xe8ff mem 0xdf000000-0xdf0000ff irq 5 at device 10.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:50:fc:1e:52:9f rl0: [MPSAFE] pci0: at device 13.0 (no driver attached) fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x3 0x13 0x3 0x3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x3 0xb 0x3 0x3 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP 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/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 psmcpnp0 irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 651484460 Hz quality 800 Timecounters tick every 10.000 msec Linux ELF exec handler installed lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 82C596B chip ata0-master: setting UDMA66 on VIA 82C596B chip ad0: ATA-5 disk at ata0-master ad0: 58644MB (120103200 sectors), 119150 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA66 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 60us ata1-master: pio=0x0b wdma=0x21 udma=0xffffffff cable=40pin ATAPI_RESET time = 210us ata1-master: setting PIO3 on VIA 82C596B chip ata1-slave: setting PIO4 on VIA 82C596B chip ata1-slave: setting UDMA33 on VIA 82C596B chip acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 689KB/s (689KB/s), 2048KB buffer, PIO3 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: CDR, CDRW, test write acd0: Audio: play, 2 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: DVDROM drive at ata1 as slave acd1: 512KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, packet acd1: Writes: acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc [0] f:80 typ:7 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:36210447 [1] f:00 typ:165 s(CHS):1023/0/1 e(CHS):1023/254/63 s:36210510 l:25157790 [2] f:00 typ:165 s(CHS):1023/0/1 e(CHS):1023/254/63 s:61368300 l:58733640 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 18539748864 end 18539781119 GEOM: Configure ad0s2, start 18539781120 length 12880788480 end 31420569599 GEOM: Configure ad0s3, start 31420569600 length 30071623680 end 61492193279 GEOM: Configure ad0s2a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s2b, start 268435456 length 783785984 end 1052221439 GEOM: Configure ad0s2c, start 0 length 12880788480 end 12880788479 GEOM: Configure ad0s2d, start 1052221440 length 268435456 end 1320656895 GEOM: Configure ad0s2e, start 1320656896 length 268435456 end 1589092351 GEOM: Configure ad0s2f, start 1589092352 length 11291696128 end 12880788479 GEOM: Configure ad0s3c, start 0 length 30071623680 end 30071623679 Mounting root from ufs:/dev/ad0s2a start_init: trying /sbin/init rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:35: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 8D64B16A4CE; Fri, 10 Sep 2004 17:35:47 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C1B443D1D; Fri, 10 Sep 2004 17:35:47 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i8AHZkco054110; Fri, 10 Sep 2004 12:35:46 -0500 (CDT) (envelope-from dan) Date: Fri, 10 Sep 2004 12:35:46 -0500 From: Dan Nelson To: Marian Cerny Message-ID: <20040910173546.GI5008@dan.emsphone.com> References: <20040910170913.GT72089@funkthat.com> <20040910172623.GA1111@artax.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910172623.GA1111@artax.karlin.mff.cuni.cz> X-OS: FreeBSD 5.3-BETA3 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: "Bjoern A. Zeeb" cc: John-Mark Gurney cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 17:35:47 -0000 In the last episode (Sep 10), Marian Cerny said: > On 2004-09-10 13:15 -0400, Robert Watson wrote: > > On Fri, 10 Sep 2004, John-Mark Gurney wrote: > > > Marian Cerny wrote this message on Fri, Sep 10, 2004 at 12:22 +0200: > > > > --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- > > > > re_rxeof(c177b000) at re_rxeof+0x2ae > > > > It would be very useful to know the revision of the file, as well > > as what line in the code re_rxeof+0x2ae is. > > Is there any way how to find it out? re_rxoef() is called 4 times in > that file. Try this: addr2line -f -e /path/to/kernel.debug 0xc0575b76 -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:36: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 9654316A4CE for ; Fri, 10 Sep 2004 17:36:16 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C4F343D5C for ; Fri, 10 Sep 2004 17:36:16 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 780 invoked from network); 10 Sep 2004 17:36:16 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 17:36:16 -0000 Received: from hydrogen.funkthat.com (cpahev@localhost.funkthat.com [127.0.0.1])i8AHaEuU010694; Fri, 10 Sep 2004 10:36:15 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8AHaDEQ010693; Fri, 10 Sep 2004 10:36:13 -0700 (PDT) Date: Fri, 10 Sep 2004 10:36:13 -0700 From: John-Mark Gurney To: Marian Cerny Message-ID: <20040910173613.GV72089@funkthat.com> Mail-Followup-To: Marian Cerny , Robert Watson , "Bjoern A. Zeeb" , freebsd-current@freebsd.org References: <20040910170913.GT72089@funkthat.com> <20040910172623.GA1111@artax.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910172623.GA1111@artax.karlin.mff.cuni.cz> 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: "Bjoern A. Zeeb" cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: LOR (re0 and user map) + PANIC 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: Fri, 10 Sep 2004 17:36:16 -0000 Marian Cerny wrote this message on Fri, Sep 10, 2004 at 19:26 +0200: > > It would be very useful to know the revision of the file, as well as what > > line in the code re_rxeof+0x2ae is. > > Is there any way how to find it out? re_rxoef() is called 4 times in > that file. >From the kernel compile directory: gdb kernel.debug l *re_rxeof+0x2ae This of course requires you to have built your kernel with debugging symbols. Could you try using if_re.c from HEAD? I plan to merge the code from HEAD into RELENG_5 shortly. Though looking at the code, it doesn't appear that things have changed enough to have fixed this panic. Once we get the line number of re_rxeof+0x2ae, we'll have a much better idea of what the problem is. -- 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 Fri Sep 10 17:37: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 6896916A4CE for ; Fri, 10 Sep 2004 17:37:36 +0000 (GMT) Received: from thunderbird.etv.net (thunderbird.etv.net [208.14.190.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03CF243D45 for ; Fri, 10 Sep 2004 17:37:36 +0000 (GMT) (envelope-from lists@efinley.com) Received: from [205.161.203.50] (helo=science1) by thunderbird.etv.net with smtp (Exim 4.34 (FreeBSD)) id 1C5pL4-0000PL-QE; Fri, 10 Sep 2004 11:37:35 -0600 Message-ID: <072201c4975c$db5bfa00$32cba1cd@science1> From: "Elliot Finley" To: "Jun Kuriyama" , References: <06c601c4973a$1d1c5570$32cba1cd@science1> <7m8ybip6qm.wl@black.imgsrc.co.jp> Date: Fri, 10 Sep 2004 11:37:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: Beta3 core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Elliot Finley List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 17:37:36 -0000 I made the change, then I did a 'make && make install' in /usr/src/lib/libc. It still core dumps. Is there anything else I need to do to put this change into effect? ----- Original Message ----- From: "Jun Kuriyama" To: Sent: Friday, September 10, 2004 7:56 AM Subject: Re: Beta3 core dump > At Fri, 10 Sep 2004 07:28:52 -0600, > Elliot Finley wrote: > > with a fresh ports cvsup, after rebuilding INDEX. If I do a 'portsdb -fu', > > I get a core dump. This is consistent. It happens every time, in the same > > place. > > > > [Updating the portsdb in /usr/ports ... - 11736 port > > entries found > > ........1000.........2000.........3000.........4000.........5000.........60 > > 00.........7000.........8000..../usr/local/lib/ruby/site_ruby/1.8/portsdb.rb > > :587: [BUG] Bus Error > > ruby 1.8.2 (2004-07-29) [i386-freebsd5] > > > > Abort (core dumped) > > Could you please trying with this patch? > > > Index: lib/libc/db/btree/bt_split.c > =================================================================== > RCS file: /home/ncvs/src/lib/libc/db/btree/bt_split.c,v > retrieving revision 1.5 > diff -u -r1.5 bt_split.c > --- lib/libc/db/btree/bt_split.c 16 Feb 2003 17:29:09 -0000 1.5 > +++ lib/libc/db/btree/bt_split.c 10 Sep 2004 13:52:38 -0000 > @@ -361,6 +361,8 @@ > r->nextpg = h->nextpg; > r->prevpg = h->pgno; > r->flags = h->flags & P_TYPE; > + /* XXX: Workaround for broken page data access. */ > + r->linp[0] = 0xffff; > > /* > * If we're splitting the last page on a level because we're appending > > > -- > Jun Kuriyama // IMG SRC, Inc. > // FreeBSD Project > _______________________________________________ > 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 Sep 10 17: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 1CD6F16A4CE; Fri, 10 Sep 2004 17:51:22 +0000 (GMT) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D66E43D3F; Fri, 10 Sep 2004 17:51:16 +0000 (GMT) (envelope-from cernm0bm@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 10663) id 6C70759F6; Fri, 10 Sep 2004 19:51:15 +0200 (CEST) Date: Fri, 10 Sep 2004 19:51:15 +0200 From: Marian Cerny To: Robert Watson , "Bjoern A. Zeeb" , freebsd-current@freebsd.org Message-ID: <20040910175115.GA3334@artax.karlin.mff.cuni.cz> References: <20040910170913.GT72089@funkthat.com> <20040910172623.GA1111@artax.karlin.mff.cuni.cz> <20040910173613.GV72089@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910173613.GV72089@funkthat.com> User-Agent: Mutt/1.5.6i Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 17:51:22 -0000 On 2004-09-10 10:36 -0700, John-Mark Gurney wrote: > Marian Cerny wrote this message on Fri, Sep 10, 2004 at 19:26 +0200: > > > It would be very useful to know the revision of the file, as well > > > as what > > > line in the code re_rxeof+0x2ae is. > > > > Is there any way how to find it out? re_rxoef() is called 4 times in > > that file. > > >From the kernel compile directory: > gdb kernel.debug > l *re_rxeof+0x2ae I will rebuild the kernel and get the line for you. But this will not be sooner than before tomorrow. > Could you try using if_re.c from HEAD? I plan to merge the code from > HEAD into RELENG_5 shortly. Ok. Marian Cerny -- Marian Cerny Jabber: jojo@njs.netlab.cz [ UNIX is user friendly. It's just selective about who its friends are. ] From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 17:57: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 E2DD916A4CE for ; Fri, 10 Sep 2004 17:57:49 +0000 (GMT) Received: from web21430.mail.yahoo.com (web21430.mail.yahoo.com [216.136.232.146]) by mx1.FreeBSD.org (Postfix) with SMTP id C3F8143D60 for ; Fri, 10 Sep 2004 17:57:49 +0000 (GMT) (envelope-from mjacob44@yahoo.com) Message-ID: <20040910175749.22388.qmail@web21430.mail.yahoo.com> Received: from [146.174.53.5] by web21430.mail.yahoo.com via HTTP; Fri, 10 Sep 2004 10:57:49 PDT Date: Fri, 10 Sep 2004 10:57:49 -0700 (PDT) From: Matthew Jacob To: Norikatsu Shigemura , freebsd-current@FreeBSD.org In-Reply-To: <200409101717.i8AHHGWR044322@sakura.ninth-nine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PANIC: sym(4) didn't MODULE_DEPEND cam(4). 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, 10 Sep 2004 17:57:50 -0000 Committed- thanks! __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:06: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 2F6D816A4D8 for ; Fri, 10 Sep 2004 18:06:51 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0738E43D41 for ; Fri, 10 Sep 2004 18:06:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25509 invoked from network); 10 Sep 2004 18:06:50 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Sep 2004 18:06:50 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8AI6ibJ016609; Fri, 10 Sep 2004 14:06:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: "M. Warner Losh" Date: Fri, 10 Sep 2004 14:07:11 -0400 User-Agent: KMail/1.6.2 References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> <20040909.154123.106438047.imp@bsdimp.com> In-Reply-To: <20040909.154123.106438047.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200409101407.11508.jhb@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: mike@sentex.net Subject: Re: SIO Interrupt storms and unhandled interrupts 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, 10 Sep 2004 18:06:54 -0000 On Thursday 09 September 2004 05:41 pm, M. Warner Losh wrote: > In message: <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> > > Mike Tancsa writes: > : Thanks for the response! We found a different solution / > : approach which seems to work on both RELENG_4 and RELENG_5. The problem > : is that the modem is not being seen as a PCI / PUC device and instead is > : being seen as an ISA SIO device ?? The following RELENG_5 and RELENG_4 > : patches seem to fix the problem. I wonder if the other modems listed in > : sio.c suffer the same fate ? > : > : Also fixed in this are those "cant re-use leafs" at bootup time. The > : modem is seen as a PUC device now.... At the bottom is a diff between > : the boot -v > > I like this fix! I'll see if I can find to commit it. Note that hacking sio to not use INTR_FAST would have had the same result. Note that in his dmesg diff, sio4 has to fall back to normal interrupt mode. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:11: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 E021416A4CE; Fri, 10 Sep 2004 18:11:49 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B03443D2F; Fri, 10 Sep 2004 18:11:49 +0000 (GMT) (envelope-from se@freebsd.org) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C5psC-0001mO-00; Fri, 10 Sep 2004 20:11:48 +0200 Received: from [80.132.245.176] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1C5psC-0005e8-00; Fri, 10 Sep 2004 20:11:48 +0200 Received: from StefanEsser.FreeBSD.org (StefanEsser [192.168.0.10]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 92D4F5F23; Fri, 10 Sep 2004 20:11:45 +0200 (CEST) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id E7ECF2302; Fri, 10 Sep 2004 20:11:44 +0200 (CEST) Date: Fri, 10 Sep 2004 20:11:44 +0200 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Matthew Jacob Message-ID: <20040910181144.GA4513@StefanEsser.FreeBSD.org> Mail-Followup-To: Stefan =?iso-8859-1?Q?E=DFer?= , Matthew Jacob , Norikatsu Shigemura , freebsd-current@FreeBSD.org References: <200409101717.i8AHHGWR044322@sakura.ninth-nine.com> <20040910175749.22388.qmail@web21430.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910175749.22388.qmail@web21430.mail.yahoo.com> User-Agent: Mutt/1.5.6i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: freebsd-current@FreeBSD.org cc: Norikatsu Shigemura Subject: Re: PANIC: sym(4) didn't MODULE_DEPEND cam(4). 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, 10 Sep 2004 18:11:50 -0000 On 2004-09-10 10:57 -0700, Matthew Jacob wrote: > > Committed- thanks! How about adding a MODULE_DEPEND on PCI as well, as is common practice in other PCI device drivers ? Index: sym_hipd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v retrieving revision 1.49 diff -u -r1.49 sym_hipd.c --- sym_hipd.c 10 Sep 2004 17:57:33 -0000 1.49 +++ sym_hipd.c 10 Sep 2004 18:08:57 -0000 @@ -8502,6 +8502,7 @@ DRIVER_MODULE(sym, pci, sym_pci_driver, sym_devclass, 0, 0); MODULE_DEPEND(sym, cam, 1, 1, 1); +MODULE_DEPEND(sym, pci, 1, 1, 1); static struct sym_pci_chip sym_pci_dev_table[] = { Regards, STefan From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:14: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 348C916A4CE for ; Fri, 10 Sep 2004 18:14:06 +0000 (GMT) Received: from mail.mcneil.com (rrcs-24-199-45-54.west.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE14B43D2D for ; Fri, 10 Sep 2004 18:14: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 6A2D9F18CA for ; Thu, 9 Sep 2004 11:55:54 -0700 (PDT) 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 00767-01 for ; Thu, 9 Sep 2004 11:55:53 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 04DB8F1872 for ; Thu, 9 Sep 2004 11:55:52 -0700 (PDT) From: Sean McNeil To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1094756152.1061.6.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 11:55:52 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: setrunqueue(): corrupt kq_runq 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, 10 Sep 2004 18:14:06 -0000 amd64 -CURRENT system has crashed now several times in the last 2 days. Ever since the change to SCHED_4BSD and PREEMPTION. I certainly hope this is fixed before 5.3-RELEASE. Sep 9 11:43:46 server syslogd: kernel boot file is /boot/kernel/kernel Sep 9 11:43:46 server kernel: setrunqueue(): corrupt kq_runq, td= 0xffffff004be8e520 Sep 9 11:43:46 server kernel: panic: deadlock in setrunqueue Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21a90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21aa0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21810 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21820 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21590 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c215a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21310 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21320 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21090 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c210a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20e10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20e20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20b90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20ba0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20910 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20920 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20690 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c206a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20410 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20420 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20190 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c201a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ff10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1ff20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fc90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fca0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fa10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fa20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f790 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f7a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f510 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f520 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f290 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f2a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f010 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f020 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ed90 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eda0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1eb10 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eb20 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e890 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e8a0 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e610 Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e620 Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) Sep 9 11:43:46 server kernel: trap number = 3 Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault Sep 9 11:43:46 server kernel: KDB: enter: panic Then a reboot. Sean From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:14: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 38A0316A4CF for ; Fri, 10 Sep 2004 18:14:06 +0000 (GMT) Received: from mail.mcneil.com (rrcs-24-199-45-54.west.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0F4D43D45 for ; Fri, 10 Sep 2004 18:14: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 53909F18C4 for ; Thu, 9 Sep 2004 02:32:59 -0700 (PDT) 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 00652-01 for ; Thu, 9 Sep 2004 02:32:57 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 85469F187A for ; Thu, 9 Sep 2004 02:32:57 -0700 (PDT) From: Sean McNeil To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1094722377.1083.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 02:32:57 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: setrunqueue() 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: Fri, 10 Sep 2004 18:14:06 -0000 I've experienced this on my amd64 system. Had no problems at all with SCHED_ULE and no PREEMPTION, but since building a new kernel with these I have: Sep 9 02:20:03 server syslogd: kernel boot file is /boot/kernel/kernel Sep 9 02:20:03 server kernel: setrunqueue(): corrupt kq_runq, td= 0xffffff003767e520 Sep 9 02:20:03 server kernel: panic: deadlock in setrunqueue Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be48e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be48f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be4660 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be4670 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be43e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be43f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be4160 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be4170 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be3ee0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be3ef0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be3c60 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be3c70 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be39e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be39f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be3760 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be3770 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be34e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be34f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be3260 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be3270 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be2fe0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be2ff0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be2d60 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be2d70 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be2ae0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be2af0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be2860 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be2870 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be25e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be25f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be2360 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be2370 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be20e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be20f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be1e60 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be1e70 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be1be0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be1bf0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be1960 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be1970 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Sep 9 02:20:03 server kernel: Fatal trap 3: breakpoint instruction fault while in kernel mode Sep 9 02:20:03 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 02:20:03 server kernel: stack pointer = 0x10:0xffffffffb1be16e0 Sep 9 02:20:03 server kernel: frame pointer = 0x10:0xffffffffb1be16f0 Sep 9 02:20:03 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Sep 9 02:20:03 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Sep 9 02:20:03 server kernel: processor eflags = IOPL = 0 Sep 9 02:20:03 server kernel: current process = 51 (pagedaemon) Sep 9 02:20:03 server kernel: trap number = 3 Sep 9 02:20:03 server kernel: panic: breakpoint instruction fault Sep 9 02:20:03 server kernel: KDB: enter: panic then reboot. Sean From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:18: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 7F95116A4CE for ; Fri, 10 Sep 2004 18:18:24 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28F3043D2F for ; Fri, 10 Sep 2004 18:18:24 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i8AIINJt007854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 14:18:23 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8AIII6R060166; Fri, 10 Sep 2004 14:18:18 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16705.61418.553065.584034@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 14:18:18 -0400 (EDT) To: John-Mark Gurney In-Reply-To: <20040910172515.GU72089@funkthat.com> References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> <20040910172515.GU72089@funkthat.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-current@freebsd.org Subject: Re: witness oddity 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, 10 Sep 2004 18:18:24 -0000 John-Mark Gurney writes: > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400: > > If I call copyout() holding one of my mutexes, it will always complain > > about a LOR, even if the mutex is freshly initiated: > > Calling copyout while holding a mutex is not allowed... If the page > isn't in memory, it could take many seconds for the page to be swapped > back in during which time your mutex will continue to be held. Thanks.. but that's not really what I asked. I want to know how witness detects a particular just-created mutex as being in a deadlock with the vm map lock. Again, is it because the vm lock is an sx lock? Is there an implicit rule that you can't take an sx lock while holding a mutex (just like you can't take Giant, or sleep?) Or is it some ordering principal that I don't understand. DRew From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:37: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 6C73316A4D0 for ; Fri, 10 Sep 2004 18:37:33 +0000 (GMT) Received: from web21427.mail.yahoo.com (web21427.mail.yahoo.com [216.136.232.46]) by mx1.FreeBSD.org (Postfix) with SMTP id 43FA543D3F for ; Fri, 10 Sep 2004 18:37:33 +0000 (GMT) (envelope-from mjacob44@yahoo.com) Message-ID: <20040910183733.11515.qmail@web21427.mail.yahoo.com> Received: from [146.174.53.5] by web21427.mail.yahoo.com via HTTP; Fri, 10 Sep 2004 11:37:33 PDT Date: Fri, 10 Sep 2004 11:37:33 -0700 (PDT) From: Matthew Jacob To: Stefan "Eßer" In-Reply-To: <20040910181144.GA4513@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: Norikatsu Shigemura Subject: Re: PANIC: sym(4) didn't MODULE_DEPEND cam(4). 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, 10 Sep 2004 18:37:33 -0000 Oh, I suppose. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:39: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 8512216A4D0 for ; Fri, 10 Sep 2004 18:39:11 +0000 (GMT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 289A743D49 for ; Fri, 10 Sep 2004 18:39:10 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr8.xs4all.nl (8.12.11/8.12.11) with ESMTP id i8AId5eN010337 for ; Fri, 10 Sep 2004 20:39:05 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i8AId5XF021708 for ; Fri, 10 Sep 2004 20:39:05 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i8AId5Mf021707 for current@freebsd.org; Fri, 10 Sep 2004 20:39:05 +0200 (CEST) (envelope-from wb) Date: Fri, 10 Sep 2004 20:39:05 +0200 From: Wilko Bulte To: current@freebsd.org Message-ID: <20040910183905.GA21674@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner Subject: 5.3-BETA3 laptop sez: xf86MapVidMem: Address 0xd0100000 outside allowable range 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, 10 Sep 2004 18:39:11 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi there, I'm in the process of getting my Compaq EVO N160 to 5.3-BETA3 to see how well it works. Work it does quite well, apart from the new X.org x-stuff reporting: xf86MapVidMem: Address 0xd0100000 outside allowable range Verbose dmesg.boot and Xorg.0.log attached. Any ideas? Suggestions are much appreciated. W/ -- Wilko Bulte wilko@FreeBSD.org --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" 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-BETA3 #0: Wed Sep 8 21:12:45 CEST 2004 root@chuck.WBnet:/usr/src/sys/i386/compile/CHUCK Preloaded elf kernel "/boot/kernel/kernel" at 0xc07fb000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc07fb250. Calibrating clock(s) ... i8254 clock: 1193181 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1065765073 Hz CPU: Intel(R) Celeron(TM) CPU 1066MHz (1065.77-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383f9ff real memory = 267780096 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x000000000fab1fff, 254328832 bytes (62092 pages) avail memory = 256573440 (244 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6440 bios32: Entry = 0xfd850 (c00fd850) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd850+0x14b pnpbios: Found PnP BIOS data at 0xc00f6470 pnpbios: Entry = f0000:9194 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> null: random: io: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000e8c0 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=35758086) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fdf10 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 30 A 0x60 3 4 5 7 9 10 11 embedded 0 30 B 0x61 3 4 5 7 9 10 11 embedded 0 30 C 0x62 3 4 5 7 9 10 11 embedded 0 30 D 0x63 3 4 5 7 9 10 11 slot 1 2 4 A 0x61 3 4 5 7 9 10 11 embedded 2 5 A 0x68 3 4 5 7 9 11 embedded 2 6 A 0x63 3 4 5 7 9 10 11 embedded 2 8 A 0x68 3 4 5 7 9 11 embedded 0 0 A 0x60 3 4 5 7 9 10 11 embedded 0 0 B 0x61 3 4 5 7 9 10 11 embedded 0 0 C 0x62 3 4 5 7 9 10 11 embedded 0 0 D 0x63 3 4 5 7 9 10 11 embedded 0 31 A 0x62 3 4 5 7 9 10 11 embedded 0 31 B 0x61 3 4 5 7 9 10 11 embedded 0 29 A 0x60 3 4 5 7 9 10 11 embedded 0 29 B 0x63 3 4 5 7 9 10 11 embedded 0 29 C 0x62 3 4 5 7 9 10 11 embedded 0 29 D 0x6b 3 4 5 7 9 10 11 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 7 9 10 11 embedded 1 0 A 0x60 3 4 5 7 9 10 11 AcpiOsDerivePciId: bus 2 dev 6 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_ec0: port 0x66,0x62 on acpi0 acpi_ec0: info: new max delay is 30 us acpi_ec0: info: new max delay is 100 us acpi_ec0: info: new max delay is 110 us ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 acpi link get: empty IRQ resource acpi link get: empty IRQ resource ACPI PCI link initial configuration: \\_SB_.PCI0.LPCB.LNKA irq 0: [ 3 4 5 7 9 10 11 14 15] 11+ low,level,sharable 0.2.0 \\_SB_.PCI0.LPCB.LNKA irq 0: [ 3 4 5 7 9 10 11 14 15] 11+ low,level,sharable 0.29.0 \\_SB_.PCI0.LPCB.LNKD irq 0: [ 3 4 5 7 9 10 11 14 15] 10+ low,level,sharable 0.29.1 \\_SB_.PCI0.LPCB.LNKC irq 0: [ 3 4 5 7 9 10 11 14 15] 0+ low,level,sharable 0.29.2 \\_SB_.PCI0.LPCB.LNKH irq 0: [ 3 4 5 7 9 10 11 14 15] 0+ low,level,sharable 0.29.3 \\_SB_.PCI0.LPCB.LNKC irq 0: [ 3 4 5 7 9 10 11 14 15] 0+ low,level,sharable 0.31.0 \\_SB_.PCI0.LPCB.LNKB irq 0: [ 3 4 5 7 9 10 11 14 15] 5+ low,level,sharable 0.31.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 28, enabled found-> vendor=0x8086, dev=0x3575, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3576, revid=0x04 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x60 (2880 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LPCB.LNKA) pcib0: possible interrupts: 3 4 5 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPCB.LNKA (references 2, priority 25722): interrupts: 11 10 5 9 7 4 3 15 14 penalty: 70 70 120 140 5070 5070 5070 50070 50070 \\_SB_.PCI0.LPCB.LNKC (references 2, priority 25722): interrupts: 11 10 5 9 7 4 3 15 14 penalty: 70 70 120 140 5070 5070 5070 50070 50070 \\_SB_.PCI0.LPCB.LNKD (references 1, priority 12861): interrupts: 11 10 5 9 7 4 3 15 14 penalty: 70 70 120 140 5070 5070 5070 50070 50070 \\_SB_.PCI0.LPCB.LNKH (references 1, priority 12861): interrupts: 11 10 5 9 7 4 3 15 14 penalty: 70 70 120 140 5070 5070 5070 50070 50070 \\_SB_.PCI0.LPCB.LNKB (references 1, priority 12861): interrupts: 11 10 5 9 7 4 3 15 14 penalty: 70 70 120 140 5070 5070 5070 50070 50070 pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LPCB.LNKA found-> vendor=0x8086, dev=0x2482, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 00001860, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.PCI0.LPCB.LNKD) pcib0: possible interrupts: 3 4 5 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPCB.LNKC (references 2, priority 25882): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 140 160 190 280 5140 5140 5140 50140 50140 \\_SB_.PCI0.LPCB.LNKD (references 1, priority 12941): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 140 160 190 280 5140 5140 5140 50140 50140 \\_SB_.PCI0.LPCB.LNKH (references 1, priority 12941): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 140 160 190 280 5140 5140 5140 50140 50140 \\_SB_.PCI0.LPCB.LNKB (references 1, priority 12941): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 140 160 190 280 5140 5140 5140 50140 50140 pcib0: slot 29 INTB routed to irq 10 via \\_SB_.PCI0.LPCB.LNKD found-> vendor=0x8086, dev=0x2484, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 found-> vendor=0x8086, dev=0x2448, revid=0x42 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x248c, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001800, size 4, enabled found-> vendor=0x8086, dev=0x248a, revid=0x02 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LPCB.LNKB) pcib0: possible interrupts: 3 4 5 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPCB.LNKC (references 2, priority 26040): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 220 230 260 420 5210 5210 5210 50210 50210 \\_SB_.PCI0.LPCB.LNKH (references 1, priority 13020): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 220 230 260 420 5210 5210 5210 50210 50210 \\_SB_.PCI0.LPCB.LNKB (references 1, priority 13020): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 220 230 260 420 5210 5210 5210 50210 50210 pcib0: slot 31 INTB routed to irq 5 via \\_SB_.PCI0.LPCB.LNKB found-> vendor=0x8086, dev=0x2483, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[10]: type 4, range 32, base 00001c00, size 8, port disabled map[14]: type 4, range 32, base 00001880, size 6, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LPCB.LNKB) pcib0: slot 31 INTB is already routed to irq 5 found-> vendor=0x8086, dev=0x2485, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 agp0: mem 0xe0000000-0xefffffff at device 0.0 on pci0 agp0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 228M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xd0100000-0xd01fffff pcib1: prefetched decode 0xd8000000-0xdfffffff ACPI PCI link initial configuration: \\_SB_.PCI0.LPCB.LNKA irq*11: [ 3 4 5 7 9 10 11 14 15] 11+ low,level,sharable 1.0.0 \\_SB_.PCI0.LPCB.LNKB irq* 5: [ 3 4 5 7 9 10 11 14 15] 5+ low,level,sharable 1.0.1 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base d8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xd8000000-0xdfffffff map[14]: type 4, range 32, base 00002000, size 8, enabled pcib1: device (null) requested decoded I/O range 0x2000-0x20ff map[18]: type 1, range 32, base d0100000, size 16, enabled pcib1: device (null) requested decoded memory range 0xd0100000-0xd010ffff pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LPCB.LNKA) pcib1: slot 0 INTA is already routed to irq 11 found-> vendor=0x1002, dev=0x4c59, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0383, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) uhci0: port 0x1840-0x185f irq 11 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 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 0x1860-0x187f irq 10 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 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 pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x3000-0x3fff pcib2: memory decode 0xd0200000-0xd02fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: \\_SB_.PCI0.LPCB.LNKB irq* 5: [ 3 4 5 7 9 10 11 14 15] 5+ low,level,sharable 2.4.0 \\_SB_.PCI0.LPCB.LNKE irq 0: [ 3 4 5 7 9 10 11 14 15] 9+ low,level,sharable 2.5.0 \\_SB_.PCI0.LPCB.LNKD irq*10: [ 3 4 5 7 9 10 11 14 15] 10+ low,level,sharable 2.6.0 \\_SB_.PCI0.LPCB.LNKE irq 0: [ 3 4 5 7 9 10 11 14 15] 9+ low,level,sharable 2.8.0 pci2: on pcib2 pci2: physical bus=2 map[10]: type 1, range 32, base d0210000, size 16, memory disabled pcib2: device (null) requested decoded memory range 0xd0210000-0xd021ffff map[14]: type 4, range 32, base 00003040, size 3, port disabled pcib2: device (null) requested decoded I/O range 0x3040-0x3047 found-> vendor=0x14f1, dev=0x2f00, revid=0x01 bus=2, slot=4, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0100, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d0201000, size 11, enabled pcib2: device (null) requested decoded memory range 0xd0201000-0xd02017ff map[14]: type 1, range 32, base d0204000, size 14, enabled pcib2: device (null) requested decoded memory range 0xd0204000-0xd0207fff found-> vendor=0x104c, dev=0x8023, revid=0x00 bus=2, slot=5, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0112, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0xac50, revid=0x01 bus=2, slot=6, func=0 class=06-07-00, hdrtype=0x02, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d0200000, size 12, enabled pcib2: device (null) requested decoded memory range 0xd0200000-0xd0200fff map[14]: type 4, range 32, base 00003000, size 6, enabled pcib2: device (null) requested decoded I/O range 0x3000-0x303f pcib2: matched entry for 2.8.INTA (src \\_SB_.PCI0.LPCB.LNKE) pcib2: possible interrupts: 3 4 5 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LPCB.LNKC (references 2, priority 26202): interrupts: 10 11 5 9 3 4 7 14 15 penalty: 300 310 350 500 5290 5290 5290 50290 50290 \\_SB_.PCI0.LPCB.LNKE (references 2, priority 26202): interrupts: 10 11 5 9 7 4 3 15 14 penalty: 300 310 350 500 5290 5290 5290 50290 50290 \\_SB_.PCI0.LPCB.LNKH (references 1, priority 13101): interrupts: 10 11 5 9 3 4 7 14 15 penalty: 300 310 350 500 5290 5290 5290 50290 50290 pcib2: slot 8 INTA routed to irq 9 via \\_SB_.PCI0.LPCB.LNKE found-> vendor=0x8086, dev=0x1031, revid=0x42 bus=2, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0113, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D2 D3 current D0 pci2: at device 4.0 (no driver attached) fwohci0: mem 0xd0204000-0xd0207fff,0xd0201000-0xd02017ff at device 5.0 on pci2 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xd0201000 pcib2: matched entry for 2.5.INTA (src \\_SB_.PCI0.LPCB.LNKE) pcib2: slot 5 INTA is already routed to irq 9 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:50:8b:70:2f:53:04:83 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) cbb0: at device 6.0 on pci2 pcib2: device cbb0 requested decoded memory range 0xd0200000-0xd02fffff cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xd0202000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.6.INTA (src \\_SB_.PCI0.LPCB.LNKD) pcib2: slot 6 INTA is already routed to irq 10 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac50104c 0x02100007 0x06070001 0x00022000 0x10: 0xd0202000 0x020000a0 0x20040302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010a 0x40: 0xb1030e11 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0xc864b061 0x00000000 0x00000000 0x012c1202 0x90: 0x616482c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x00000001 0x0000001f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fxp0: port 0x3000-0x303f mem 0xd0200000-0xd0200fff irq 9 at device 8.0 on pci2 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0200000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1031 0e11 0093 0042 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:02:a5:9d:b3:30 fxp0: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1800-0x180f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1800 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:6 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x201 0x211 0x201 0x201 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port acpi_ec0: info: new max delay is 140 us fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 device_attach: fdc0 attach returned 6 acpi_ec0: info: new max delay is 180 us unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 device_attach: fdc0 attach returned 6 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 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 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xdc000-0xdffff,0xdb000-0xdbfff,0xc0000-0xcdfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 e7 73 4f 4f 97 52 83 b4 1f 00 4f 0d 0e 00 00 07 80 91 87 8f 28 1f 8f b5 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 e7 73 4f 4f 97 52 83 b4 1f 00 4f 0d 0e 00 00 07 80 91 87 8f 28 1f 8f b5 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1065765073 Hz quality 800 Timecounters tick every 10.000 msec Linux ELF exec handler installed lo0: bpf attached acpi_acad0: acline initialization start system power profile changed to 'economy' acpi_acad0: Off Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_ec0: info: new max delay is 220 us acpi_ec0: info: new max delay is 11000 us ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on Intel ICH3 chip ata0-master: setting UDMA100 on Intel ICH3 chip ad0: ATA-5 disk at ata0-master ad0: 19077MB (39070080 sectors), 38760 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 30us ata1-master: setting PIO4 on Intel ICH3 chip ata1-master: setting UDMA33 on Intel ICH3 chip acd0: CDROM drive at ata1 as master acd0: read 4125KB/s (4125KB/s), 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc [0] f:00 typ:7 s(CHS):0/1/1 e(CHS):700/254/63 s:63 l:11261502 [1] f:80 typ:165 s(CHS):701/0/1 e(CHS):1023/254/63 s:11261565 l:27808515 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 5765889024 end 5765921279 GEOM: Configure ad0s2, start 5765921280 length 14237959680 end 20003880959 GEOM: Configure ad0s2a, start 0 length 209715200 end 209715199 GEOM: Configure ad0s2b, start 209715200 length 269484032 end 479199231 GEOM: Configure ad0s2c, start 0 length 14237959680 end 14237959679 GEOM: Configure ad0s2d, start 479199232 length 67108864 end 546308095 GEOM: Configure ad0s2e, start 546308096 length 67108864 end 613416959 GEOM: Configure ad0s2f, start 613416960 length 5368709120 end 5982126079 GEOM: Configure ad0s2g, start 5982126080 length 8255833600 end 14237959679 acpi_cmbat0: battery initialization done, tried 1 times pcib2: device pccard0 requested decoded memory range 0xd0200000-0xd02fffff pccard0: CIS version PCCARD 2.0 or 2.1 pccard0: CIS info: Cisco Systems, 350 Series Wireless LAN Adapter pccard0: Manufacturer code 0x15f, product 0xa pccard0: function 0: network adapter, ccr addr 3e0 mask 7 pccard0: function 0, config table entry 5: I/O card; irq mask ffff; iomask 6, iospace 0-3f; io16 irqlevel pcib2: device pccard0 requested decoded I/O range 0x3000-0x3fff pcib2: device pccard0 requested decoded memory range 0xd0200000-0xd02fffff an0: at port 0x3080-0x30bf irq 10 function 0 config 5 on pccard0 pcib2: device an0 requested decoded I/O range 0x3080-0x30bf pcib2: device pccard0 requested decoded I/O range 0x3080-0x30bf pcib2: device an0 requested decoded I/O range 0x3080-0x30bf an0: record length mismatch -- expected 194, got 196 for Rid ff10 an0: record length mismatch -- expected 192, got 200 for Rid ff00 an0: got RSSI <-> dBM map an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps an0: bpf attached an0: Ethernet address: 00:09:b7:7b:9d:16 an0: [GIANT-LOCKED] (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error Mounting root from ufs:/dev/ad0s2a start_init: trying /sbin/init an0: record length mismatch -- expected 194, got 196 for Rid ff10 an0: record length mismatch -- expected 194, got 196 for Rid ff10 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Xorg.0.log" Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: FreeBSD 5.3 i386 [ELF] Current Operating System: FreeBSD chuck.WBnet 5.3-BETA3 FreeBSD 5.3-BETA3 #0: Wed Sep 8 21:12:45 CEST 2004 root@chuck.WBnet:/usr/src/sys/i386/compile/CHUCK i386 Build Date: 09 September 2004 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Sep 10 20:25:54 2004 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "XFree86 Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Keyboard: CustomKeycode disabled (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/Speedo/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/Speedo/"). (WW) The directory "/usr/X11R6/lib/X11/fonts/freefont/" does not exist. Entry deleted from font path. (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/URW/,unix/:7101" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" (WW) checkDevMem: failed to open /dev/mem (No such file or directory) (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8000e9c0, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3575 card ffff,ffff rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,3576 card 0000,0000 rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 0e11,009c rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 0e11,009c rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card 0000,0000 rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 0e11,009c rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,2483 card 0e11,009c rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 0e11,005c rev 02 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c59 card 0e11,b11b rev 00 class 03,00,00 hdr 00 (II) PCI: 02:04:0: chip 14f1,2f00 card 0e11,8d89 rev 01 class 07,80,00 hdr 00 (II) PCI: 02:05:0: chip 104c,8023 card 0e11,b1b1 rev 00 class 0c,00,10 hdr 00 (II) PCI: 02:06:0: chip 104c,ac50 card fffc,ffff rev 01 class 06,07,00 hdr 02 (II) PCI: 02:08:0: chip 8086,1031 card 0e11,0093 rev 42 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,3), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x00002000 - 0x000020ff (0x100) IX[B] [1] -1 0 0x00002400 - 0x000024ff (0x100) IX[B] [2] -1 0 0x00002800 - 0x000028ff (0x100) IX[B] [3] -1 0 0x00002c00 - 0x00002cff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xd0100000 - 0xd01fffff (0x100000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x00003000 - 0x000030ff (0x100) IX[B] [1] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [2] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] [3] -1 0 0x00003c00 - 0x00003cff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xd0200000 - 0xd02fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 3: bridge is at (2:6:0), (2,3,4), BCTRL: 0x0740 (VGA_EN is cleared) (--) PCI:*(1:0:0) ATI Technologies Inc Radeon Mobility M6 LY rev 0, Mem @ 0xd8000000/27, 0xd0100000/16, I/O @ 0x2000/8 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xe0000000 from 0xffffffff to 0xdfffffff (II) Active PCI resource ranges: [0] -1 0 0xd0200000 - 0xd03fffff (0x200000) MX[B]E [1] -1 0 0xd0204000 - 0xd0207fff (0x4000) MX[B]E [2] -1 0 0xd0201000 - 0xd0201fff (0x1000) MX[B]E [3] -1 0 0xd0210000 - 0xd021ffff (0x10000) MX[B]E [4] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [5] -1 0 0xd0100000 - 0xd010ffff (0x10000) MX[B](B) [6] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [7] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [8] -1 0 0x00003040 - 0x0000307f (0x40) IX[B]E [9] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [10] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [11] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [12] -1 0 0x00001800 - 0x000018ff (0x100) IX[B]E [13] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [14] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [15] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [16] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [17] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [18] -1 0 0x00001840 - 0x0000187f (0x40) IX[B]E [19] -1 0 0x00002000 - 0x000020ff (0x100) IX[B](B) (II) PCI I/O resource overlap reduced 0x00003000 from 0x000030ff to 0x0000303f (II) PCI Memory resource overlap reduced 0xd0200000 from 0xd03fffff to 0xd0200fff (II) PCI I/O resource overlap reduced 0x00001800 from 0x000018ff to 0x0000181f (II) PCI I/O resource overlap reduced 0x00001840 from 0x0000187f to 0x0000185f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xd0200000 - 0xd0200fff (0x1000) MX[B]E [1] -1 0 0xd0204000 - 0xd0207fff (0x4000) MX[B]E [2] -1 0 0xd0201000 - 0xd0201fff (0x1000) MX[B]E [3] -1 0 0xd0210000 - 0xd021ffff (0x10000) MX[B]E [4] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [5] -1 0 0xd0100000 - 0xd010ffff (0x10000) MX[B](B) [6] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [7] -1 0 0x00003000 - 0x0000303f (0x40) IX[B]E [8] -1 0 0x00003040 - 0x0000307f (0x40) IX[B]E [9] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [10] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [11] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [12] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [13] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [14] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [15] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [16] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [17] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [18] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [19] -1 0 0x00002000 - 0x000020ff (0x100) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xd0200000 - 0xd0200fff (0x1000) MX[B]E [6] -1 0 0xd0204000 - 0xd0207fff (0x4000) MX[B]E [7] -1 0 0xd0201000 - 0xd0201fff (0x1000) MX[B]E [8] -1 0 0xd0210000 - 0xd021ffff (0x10000) MX[B]E [9] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [10] -1 0 0xd0100000 - 0xd010ffff (0x10000) MX[B](B) [11] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [12] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [13] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [14] -1 0 0x00003000 - 0x0000303f (0x40) IX[B]E [15] -1 0 0x00003040 - 0x0000307f (0x40) IX[B]E [16] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [17] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [18] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [19] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [20] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [21] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [22] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [23] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [24] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [25] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [26] -1 0 0x00002000 - 0x000020ff (0x100) IX[B](B) (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension FontCache (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "xie" (WW) Warning, couldn't open module xie (II) UnloadModule: "xie" (EE) Failed to load module "xie" (module does not exist, 0) (II) LoadModule: "pex5" (WW) Warning, couldn't open module pex5 (II) UnloadModule: "pex5" (EE) Failed to load module "pex5" (module does not exist, 0) (II) LoadModule: "glx" (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a (II) Module GLcore: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a (II) Module drm: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) Loading extension XFree86-DRI (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "record" (II) Loading /usr/X11R6/lib/modules/extensions/librecord.a (II) Module record: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension RECORD (II) LoadModule: "xtrap" (II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a (II) Module xtrap: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.2 (II) Loading extension DEC-XTRAP (II) LoadModule: "speedo" (II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a (II) Module speedo: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.1 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Speedo (II) LoadModule: "type1" (II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a (II) Module type1: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Type1 (II) Loading font CID (II) LoadModule: "freetype" (II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 6.7.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font FreeType (II) LoadModule: "ati" (II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o (II) Module ati: vendor="X.Org Foundation" compiled for 6.7.0, module version = 6.5.6 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor="X.Org Foundation" compiled for 6.7.0, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.4 (II) ATI: ATI driver (version 6.5.6) for chipsets: ati, ativga (II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP), ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP), ATI Rage 128 Pro GL PA (PCI/AGP), ATI Rage 128 Pro GL PB (PCI/AGP), ATI Rage 128 Pro GL PC (PCI/AGP), ATI Rage 128 Pro GL PD (PCI), ATI Rage 128 Pro GL PE (PCI/AGP), ATI Rage 128 Pro GL PF (AGP), ATI Rage 128 Pro VR PG (PCI/AGP), ATI Rage 128 Pro VR PH (PCI/AGP), ATI Rage 128 Pro VR PI (PCI/AGP), ATI Rage 128 Pro VR PJ (PCI/AGP), ATI Rage 128 Pro VR PK (PCI/AGP), ATI Rage 128 Pro VR PL (PCI/AGP), ATI Rage 128 Pro VR PM (PCI/AGP), ATI Rage 128 Pro VR PN (PCI/AGP), ATI Rage 128 Pro VR PO (PCI/AGP), ATI Rage 128 Pro VR PP (PCI), ATI Rage 128 Pro VR PQ (PCI/AGP), ATI Rage 128 Pro VR PR (PCI), ATI Rage 128 Pro VR PS (PCI/AGP), ATI Rage 128 Pro VR PT (PCI/AGP), ATI Rage 128 Pro VR PU (PCI/AGP), ATI Rage 128 Pro VR PV (PCI/AGP), ATI Rage 128 Pro VR PW (PCI/AGP), ATI Rage 128 Pro VR PX (PCI/AGP), ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI), ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (PCI/AGP), ATI Rage 128 4X SF (PCI/AGP), ATI Rage 128 4X SG (PCI/AGP), ATI Rage 128 4X SH (PCI/AGP), ATI Rage 128 4X SK (PCI/AGP), ATI Rage 128 4X SL (PCI/AGP), ATI Rage 128 4X SM (AGP), ATI Rage 128 4X SN (PCI/AGP), ATI Rage 128 Pro ULTRA TF (AGP), ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP), ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?), ATI Rage 128 Pro ULTRA TU (AGP?) (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437, ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon 9200PRO 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI FireGL RV360 AV (AGP), ATI Radeon Mobility 9600 (M10) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2 (M11) NV (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP) (II) Primary Device is: PCI 01:00:0 (II) ATI: Candidate "Device" section "Card0". (--) Chipset ATI Radeon Mobility M6 LY (AGP) found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xd0200000 - 0xd0200fff (0x1000) MX[B]E [6] -1 0 0xd0204000 - 0xd0207fff (0x4000) MX[B]E [7] -1 0 0xd0201000 - 0xd0201fff (0x1000) MX[B]E [8] -1 0 0xd0210000 - 0xd021ffff (0x10000) MX[B]E [9] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [10] -1 0 0xd0100000 - 0xd010ffff (0x10000) MX[B](B) [11] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [12] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [13] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [14] -1 0 0x00003000 - 0x0000303f (0x40) IX[B]E [15] -1 0 0x00003040 - 0x0000307f (0x40) IX[B]E [16] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [17] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [18] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [19] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [20] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [21] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [22] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [23] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [24] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [25] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [26] -1 0 0x00002000 - 0x000020ff (0x100) IX[B](B) (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o (II) Module radeon: vendor="X.Org Foundation" compiled for 6.7.0, module version = 4.0.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 (II) resource ranges after probing: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0 0xd0200000 - 0xd0200fff (0x1000) MX[B]E [6] -1 0 0xd0204000 - 0xd0207fff (0x4000) MX[B]E [7] -1 0 0xd0201000 - 0xd0201fff (0x1000) MX[B]E [8] -1 0 0xd0210000 - 0xd021ffff (0x10000) MX[B]E [9] -1 0 0xe0000000 - 0xdfffffff (0x0) MX[B]EO [10] -1 0 0xd0100000 - 0xd010ffff (0x10000) MX[B](B) [11] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B) [12] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [13] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [14] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [15] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [16] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [17] -1 0 0x00003000 - 0x0000303f (0x40) IX[B]E [18] -1 0 0x00003040 - 0x0000307f (0x40) IX[B]E [19] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [22] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [23] -1 0 0x00000374 - 0x00000377 (0x4) IX[B]E [24] -1 0 0x00000170 - 0x0000017f (0x10) IX[B]E [25] -1 0 0x000003f4 - 0x000003f7 (0x4) IX[B]E [26] -1 0 0x000001f0 - 0x000001ff (0x10) IX[B]E [27] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [28] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [29] -1 0 0x00002000 - 0x000020ff (0x100) IX[B](B) [30] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [31] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): MMIO registers at 0xd0100000 Fatal server error: xf86MapVidMem: Address 0xd0100000 outside allowable range Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:59: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 7308916A4CE; Fri, 10 Sep 2004 18:59:35 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E15CD43D5C; Fri, 10 Sep 2004 18:59:34 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8AIxTYJ025807; Fri, 10 Sep 2004 14:59:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25517-04; Fri, 10 Sep 2004 14:59:29 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8AIxTiC025763; Fri, 10 Sep 2004 14:59:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8AIxMEe005767; Fri, 10 Sep 2004 14:59:23 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040910143939.0905b980@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 15:05:11 -0400 To: John Baldwin , "M. Warner Losh" From: Mike Tancsa In-Reply-To: <200409101407.11508.jhb@FreeBSD.org> References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> <20040909.154123.106438047.imp@bsdimp.com> <200409101407.11508.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-current@FreeBSD.org Subject: Re: SIO Interrupt storms and unhandled interrupts 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, 10 Sep 2004 18:59:35 -0000 At 02:07 PM 10/09/2004, John Baldwin wrote: > > Mike Tancsa writes: > > : Thanks for the response! We found a different solution / > > : approach which seems to work on both RELENG_4 and RELENG_5. The problem > > : is that the modem is not being seen as a PCI / PUC device and instead is > > : being seen as an ISA SIO device ?? The following RELENG_5 and RELENG_4 > > : patches seem to fix the problem. I wonder if the other modems listed in > > : sio.c suffer the same fate ? > > : > > : Also fixed in this are those "cant re-use leafs" at bootup time. The > > : modem is seen as a PUC device now.... At the bottom is a diff between > > : the boot -v > > > > I like this fix! I'll see if I can find to commit it. > >Note that hacking sio to not use INTR_FAST would have had the same result. >Note that in his dmesg diff, sio4 has to fall back to normal interrupt mode. While on this topic, we are still trying to track down one issue that we think is related. On a remote production machine (i.e. we cannot do too much with it just yet) the hardware watchdog will kick in a few times a month (perhaps in 1 week, perhaps after 2 weeks, perhaps 2 days-- at seemingly random intervals). Of the dozen or so machines we have deployed, its the only one with the modem (it does not have the patch forcing it to be a PUC device) that shares its interrupt with the onboard SMBus controller and its the only one where its locking up like this. We dont have the SMBus driver support compiled in. My question is this-- what happens if the SMBus device fires an interrupt ? Will the same lockups happen in that the kernel thinks the modem is firing the interrupt, but its really the SMBus ? The remote device is currently running RELENG_4, so there is no "storm detection" Also, if we went the hacking of the sio to not use INTR_FAST, I am not sure it would work. I am pretty sure that when we were debugging this issue with the help of Bruce Evans, he provided a patch to do just this and it did not work. ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:09: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 D0A3816A4CE for ; Fri, 10 Sep 2004 19:09:39 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id A56D243D2F for ; Fri, 10 Sep 2004 19:09:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4223 invoked from network); 10 Sep 2004 19:09:39 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Sep 2004 19:09:39 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8AJ9ZBc017027; Fri, 10 Sep 2004 15:09:35 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Fri, 10 Sep 2004 14:50:47 -0400 User-Agent: KMail/1.6.2 References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> <20040910172515.GU72089@funkthat.com> <16705.61418.553065.584034@grasshopper.cs.duke.edu> In-Reply-To: <16705.61418.553065.584034@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409101450.47478.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: John-Mark Gurney cc: Andrew Gallatin Subject: Re: witness oddity 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, 10 Sep 2004 19:09:39 -0000 On Friday 10 September 2004 02:18 pm, Andrew Gallatin wrote: > John-Mark Gurney writes: > > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400: > > > If I call copyout() holding one of my mutexes, it will always complain > > > about a LOR, even if the mutex is freshly initiated: > > > > Calling copyout while holding a mutex is not allowed... If the page > > isn't in memory, it could take many seconds for the page to be swapped > > back in during which time your mutex will continue to be held. > > Thanks.. but that's not really what I asked. > > I want to know how witness detects a particular just-created mutex as > being in a deadlock with the vm map lock. > > Again, is it because the vm lock is an sx lock? Is there an implicit > rule that you can't take an sx lock while holding a mutex (just like > you can't take Giant, or sleep?) Yes. An sx lock is allowed to be held across a sleep, so if you block on an sx lock, the owner of the lock you are waiting on might be asleep. If that happens, then your thread won't be able to resume until that other thread is woken up and it is basically akin to sleeping with a mutex. Also, if copyout() takes a page fault it can sleep, so holding a mutex across copy*() is a bad idea anyways. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:10: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 2194816A66C for ; Fri, 10 Sep 2004 19:09:55 +0000 (GMT) Received: from mail.mcneil.com (rrcs-24-199-45-54.west.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 896E143D1D for ; Fri, 10 Sep 2004 19:09:55 +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 53E96F18F1 for ; Fri, 10 Sep 2004 12:09:55 -0700 (PDT) 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 09271-02 for ; Fri, 10 Sep 2004 12:09:54 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 6D9D4F1802 for ; Fri, 10 Sep 2004 12:09:54 -0700 (PDT) From: Sean McNeil To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1094843394.9501.6.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 12:09:54 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: recent multiple posts by me 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, 10 Sep 2004 19:10:13 -0000 I'd like to apologize for the multple posts. My email server stated that there was a failure sending messages to freebsd.org. It would appear that it saved the messages and kept trying, though. My bad! Cheers, Sean From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:13: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 AAF9116A4CE; Fri, 10 Sep 2004 19:13:10 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B78043D53; Fri, 10 Sep 2004 19:13:10 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8AJDnk8018718; Fri, 10 Sep 2004 13:13:49 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4141FC17.7000204@samsco.org> Date: Fri, 10 Sep 2004 13:10:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, stable@freebsd.org 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 Subject: Call for FreeBSD status reports 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, 10 Sep 2004 19:13:10 -0000 All, It's time again for the bi-monthly FreeBSD status reports. It's a little late this month due to working on the 5.3 BETAs, so I apologize for that. We had an excellent turn out on reports last time, so please keep with that positive trend. As always, reports are encouraged for anything that relates to FreeBSD development, documentation, independent projects, community activities, or anything else that might be interesting to the community as a whole. Reports should be one to two paragraphs in length. The template can be found at http://www.freebsd.org/news/status/report-sample.xml Submissions are due to monthly@freebsd.org by September 20. Thanks, Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:20: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 8827D16A4CE for ; Fri, 10 Sep 2004 19:20:26 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A72043D41 for ; Fri, 10 Sep 2004 19:20:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29194 invoked from network); 10 Sep 2004 19:20:25 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Sep 2004 19:20:25 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8AJKLWi017227; Fri, 10 Sep 2004 15:20:22 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Mike Tancsa Date: Fri, 10 Sep 2004 15:20:44 -0400 User-Agent: KMail/1.6.2 References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <200409101407.11508.jhb@FreeBSD.org> <6.1.2.0.0.20040910143939.0905b980@64.7.153.2> In-Reply-To: <6.1.2.0.0.20040910143939.0905b980@64.7.153.2> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409101520.44916.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: "M. Warner Losh" Subject: Re: SIO Interrupt storms and unhandled interrupts 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, 10 Sep 2004 19:20:26 -0000 On Friday 10 September 2004 03:05 pm, Mike Tancsa wrote: > At 02:07 PM 10/09/2004, John Baldwin wrote: > > > Mike Tancsa writes: > > > : Thanks for the response! We found a different solution / > > > : approach which seems to work on both RELENG_4 and RELENG_5. The > > > : problem is that the modem is not being seen as a PCI / PUC device and > > > : instead is being seen as an ISA SIO device ?? The following RELENG_5 > > > : and RELENG_4 patches seem to fix the problem. I wonder if the other > > > : modems listed in sio.c suffer the same fate ? > > > : > > > : Also fixed in this are those "cant re-use leafs" at bootup time. The > > > : modem is seen as a PUC device now.... At the bottom is a diff > > > : between the boot -v > > > > > > I like this fix! I'll see if I can find to commit it. > > > >Note that hacking sio to not use INTR_FAST would have had the same result. > >Note that in his dmesg diff, sio4 has to fall back to normal interrupt > > mode. > > While on this topic, we are still trying to track down one issue that we > think is related. On a remote production machine (i.e. we cannot do too > much with it just yet) the hardware watchdog will kick in a few times a > month (perhaps in 1 week, perhaps after 2 weeks, perhaps 2 days-- at > seemingly random intervals). Of the dozen or so machines we have deployed, > its the only one with the modem (it does not have the patch forcing it to > be a PUC device) that shares its interrupt with the onboard SMBus > controller and its the only one where its locking up like this. We dont > have the SMBus driver support compiled in. My question is this-- what > happens if the SMBus device fires an interrupt ? Will the same lockups > happen in that the kernel thinks the modem is firing the interrupt, but its > really the SMBus ? The remote device is currently running RELENG_4, so > there is no "storm detection" Yes, that would be a storm, and only a driver for the smbus controller could turn it off, so if no driver it just locks up. > Also, if we went the hacking of the sio to not use INTR_FAST, I am not sure > it would work. I am pretty sure that when we were debugging this issue with > the help of Bruce Evans, he provided a patch to do just this and it did not > work. For the case with smbus the hack won't work, but for your puc case it should work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:32: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 F221A16A4CE; Fri, 10 Sep 2004 19:32:11 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631F443D45; Fri, 10 Sep 2004 19:32:11 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i8AJWAJt018557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 15:32:10 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8AJW5Jh060255; Fri, 10 Sep 2004 15:32:05 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16706.309.398789.905433@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 15:32:05 -0400 (EDT) To: John Baldwin In-Reply-To: <200409101450.47478.jhb@FreeBSD.org> References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> <20040910172515.GU72089@funkthat.com> <16705.61418.553065.584034@grasshopper.cs.duke.edu> <200409101450.47478.jhb@FreeBSD.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: John-Mark Gurney cc: freebsd-current@FreeBSD.org Subject: Re: witness oddity 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, 10 Sep 2004 19:32:12 -0000 John Baldwin writes: > On Friday 10 September 2004 02:18 pm, Andrew Gallatin wrote: > > John-Mark Gurney writes: > > > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400: > > > > If I call copyout() holding one of my mutexes, it will always complain > > > > about a LOR, even if the mutex is freshly initiated: > > > > > > Calling copyout while holding a mutex is not allowed... If the page > > > isn't in memory, it could take many seconds for the page to be swapped > > > back in during which time your mutex will continue to be held. > > > > Thanks.. but that's not really what I asked. > > > > I want to know how witness detects a particular just-created mutex as > > being in a deadlock with the vm map lock. > > > > Again, is it because the vm lock is an sx lock? Is there an implicit > > rule that you can't take an sx lock while holding a mutex (just like > > you can't take Giant, or sleep?) > > Yes. An sx lock is allowed to be held across a sleep, so if you block on an > sx lock, the owner of the lock you are waiting on might be asleep. If that Do you agree that the message that Witness emits ("lock order reversal") for this problem is, while technically accurate, is at least a little confusing? Before I thought to try the mtx_init()/mtx_lock/()/copyout() trick, I spent quite a while scanning my code, looking for some way the VM system could call into it and acquire that lock. There aren't any. Does witness know at the time that it emits the warning that its a "class" type of reversal, rather than a reversal based on previous observations? If so, would it be possible to emit a warning saying something like "Holding a sleep mutex while acquiring an sx lock is probited by law" (maybe add " violators will be shot" for grins ;) Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:45: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 82A1816A4CE for ; Fri, 10 Sep 2004 19:45:05 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D5B43D49 for ; Fri, 10 Sep 2004 19:45:05 +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 164D17A3D2; Fri, 10 Sep 2004 12:45:02 -0700 (PDT) Message-ID: <4142043D.2050405@elischer.org> Date: Fri, 10 Sep 2004 12:45:01 -0700 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: Sean McNeil References: <1094722377.1083.3.camel@server.mcneil.com> In-Reply-To: <1094722377.1083.3.camel@server.mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: setrunqueue() 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: Fri, 10 Sep 2004 19:45:05 -0000 Sean McNeil wrote: >I've experienced this on my amd64 system. Had no problems at all with >SCHED_ULE and no PREEMPTION, but since building a new kernel with these >I have: > >Sep 9 02:20:03 server syslogd: kernel boot file is /boot/kernel/kernel >Sep 9 02:20:03 server kernel: setrunqueue(): corrupt kq_runq, td= 0xffffff003767e520 >Sep 9 02:20:03 server kernel: panic: deadlock in setrunqueue >Sep 9 02:20:03 server kernel: KDB: enter: panic >Sep 9 02:20:03 server kernel: >Sep 9 02:20:03 server kernel: > yeah we are keenly aware of this.. is this in 6.0 or RELENG_5? From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:46: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 14F2416A4CE for ; Fri, 10 Sep 2004 19:46:52 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD86043D4C for ; Fri, 10 Sep 2004 19:46:51 +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 82B467A3D2; Fri, 10 Sep 2004 12:46:51 -0700 (PDT) Message-ID: <414204AB.6030805@elischer.org> Date: Fri, 10 Sep 2004 12:46:51 -0700 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: Sean McNeil References: <1094756152.1061.6.camel@server.mcneil.com> In-Reply-To: <1094756152.1061.6.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: setrunqueue(): corrupt kq_runq 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, 10 Sep 2004 19:46:52 -0000 try turning off PREEMPTION for now.. Sean McNeil wrote: >amd64 -CURRENT system has crashed now several times in the last 2 days. >Ever since the change to SCHED_4BSD and PREEMPTION. I certainly hope >this is fixed before 5.3-RELEASE. > >Sep 9 11:43:46 server syslogd: kernel boot file is /boot/kernel/kernel >Sep 9 11:43:46 server kernel: setrunqueue(): corrupt kq_runq, td= 0xffffff004be8e520 >Sep 9 11:43:46 server kernel: panic: deadlock in setrunqueue >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21a90 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21aa0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21810 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21820 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21590 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c215a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21310 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c21320 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c21090 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c210a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20e10 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20e20 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20b90 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20ba0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20910 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20920 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20690 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c206a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20410 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c20420 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c20190 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c201a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ff10 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1ff20 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fc90 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fca0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1fa10 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1fa20 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f790 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f7a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f510 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f520 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f290 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f2a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1f010 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1f020 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1ed90 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eda0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1eb10 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1eb20 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e890 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e8a0 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: >Sep 9 11:43:46 server kernel: Fatal trap 3: breakpoint instruction fault while >in kernel mode >Sep 9 11:43:46 server kernel: instruction pointer = 0x8:0xffffffff8031a71fSep 9 11:43:46 server kernel: stack pointer = 0x10:0xffffffffb1c1e610 >Sep 9 11:43:46 server kernel: frame pointer = 0x10:0xffffffffb1c1e620 >Sep 9 11:43:46 server kernel: code segment = base 0x0, limit 0xfffff, type 0x1b >Sep 9 11:43:46 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 >Sep 9 11:43:46 server kernel: processor eflags = IOPL = 0 >Sep 9 11:43:46 server kernel: current process = 61 (schedcpu) >Sep 9 11:43:46 server kernel: trap number = 3 >Sep 9 11:43:46 server kernel: panic: breakpoint instruction fault >Sep 9 11:43:46 server kernel: KDB: enter: panic > >Then a reboot. > >Sean > > >_______________________________________________ >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 Sep 10 19:53: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 AEC6B16A4CE for ; Fri, 10 Sep 2004 19:53:00 +0000 (GMT) Received: from mail.mcneil.com (rrcs-24-199-45-54.west.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D7943D48 for ; Fri, 10 Sep 2004 19:53:00 +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 0CC5DF191A; Fri, 10 Sep 2004 12:53:00 -0700 (PDT) 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 09271-05; Fri, 10 Sep 2004 12:52:59 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 3A755F1865; Fri, 10 Sep 2004 12:52:59 -0700 (PDT) From: Sean McNeil To: Julian Elischer In-Reply-To: <414204AB.6030805@elischer.org> References: <1094756152.1061.6.camel@server.mcneil.com> <414204AB.6030805@elischer.org> Content-Type: text/plain Message-Id: <1094845978.9884.1.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Sep 2004 12:52:59 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-current@freebsd.org Subject: Re: setrunqueue(): corrupt kq_runq 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, 10 Sep 2004 19:53:00 -0000 On Fri, 2004-09-10 at 12:46, Julian Elischer wrote: > try turning off PREEMPTION for now.. > > Sean McNeil wrote: > > >amd64 -CURRENT system has crashed now several times in the last 2 days. > >Ever since the change to SCHED_4BSD and PREEMPTION. I certainly hope > >this is fixed before 5.3-RELEASE. Again, let me say I'm sorry for the multiple posts. postfix confused me to think it wasn't going to be delivered. I've turned off PREEMPTION and it has been quite stable. Thanks, Sean From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 20:47: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 04F7316A4CE for ; Fri, 10 Sep 2004 20:47:20 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE7D343D4C for ; Fri, 10 Sep 2004 20:47:19 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16533 invoked from network); 10 Sep 2004 20:47:19 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Sep 2004 20:47:18 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8AKlEF0017736; Fri, 10 Sep 2004 16:47:15 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andrew Gallatin Date: Fri, 10 Sep 2004 16:29:32 -0400 User-Agent: KMail/1.6.2 References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> <200409101450.47478.jhb@FreeBSD.org> <16706.309.398789.905433@grasshopper.cs.duke.edu> In-Reply-To: <16706.309.398789.905433@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409101629.32653.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: John-Mark Gurney cc: freebsd-current@FreeBSD.org Subject: Re: witness oddity 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, 10 Sep 2004 20:47:20 -0000 On Friday 10 September 2004 03:32 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Friday 10 September 2004 02:18 pm, Andrew Gallatin wrote: > > > John-Mark Gurney writes: > > > > Andrew Gallatin wrote this message on Fri, Sep 10, 2004 at 13:18 -0400: > > > > > If I call copyout() holding one of my mutexes, it will always > > > > > complain about a LOR, even if the mutex is freshly initiated: > > > > > > > > Calling copyout while holding a mutex is not allowed... If the > > > > page isn't in memory, it could take many seconds for the page to be > > > > swapped back in during which time your mutex will continue to be > > > > held. > > > > > > Thanks.. but that's not really what I asked. > > > > > > I want to know how witness detects a particular just-created mutex as > > > being in a deadlock with the vm map lock. > > > > > > Again, is it because the vm lock is an sx lock? Is there an implicit > > > rule that you can't take an sx lock while holding a mutex (just like > > > you can't take Giant, or sleep?) > > > > Yes. An sx lock is allowed to be held across a sleep, so if you block > > on an sx lock, the owner of the lock you are waiting on might be asleep. > > If that > > Do you agree that the message that Witness emits ("lock order > reversal") for this problem is, while technically accurate, is at > least a little confusing? Before I thought to try the > mtx_init()/mtx_lock/()/copyout() trick, I spent quite a while scanning > my code, looking for some way the VM system could call into it and > acquire that lock. There aren't any. > > Does witness know at the time that it emits the warning that its a > "class" type of reversal, rather than a reversal based on previous > observations? If so, would it be possible to emit a warning saying > something like "Holding a sleep mutex while acquiring an sx lock is > probited by law" (maybe add " violators will be shot" for grins ;) That's a possibility yes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 21: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 560A216A4CE; Fri, 10 Sep 2004 21:11:57 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D18D143D39; Fri, 10 Sep 2004 21:11:56 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i8ALBuJt003171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 17:11:56 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8ALBp1W060335; Fri, 10 Sep 2004 17:11:51 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16706.6294.966077.389173@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 17:11:50 -0400 (EDT) To: John Baldwin In-Reply-To: <200409101629.32653.jhb@FreeBSD.org> References: <16705.57806.550902.483858@grasshopper.cs.duke.edu> <200409101450.47478.jhb@FreeBSD.org> <16706.309.398789.905433@grasshopper.cs.duke.edu> <200409101629.32653.jhb@FreeBSD.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: John-Mark Gurney cc: freebsd-current@FreeBSD.org Subject: Re: witness oddity 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, 10 Sep 2004 21:11:57 -0000 John Baldwin writes: > > > > Does witness know at the time that it emits the warning that its a > > "class" type of reversal, rather than a reversal based on previous > > observations? If so, would it be possible to emit a warning saying > > something like "Holding a sleep mutex while acquiring an sx lock is > > probited by law" (maybe add " violators will be shot" for grins ;) > > That's a possibility yes. > Thanks... I think that might be helpful.. Drew From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 21:27: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 CE38016A4CE; Fri, 10 Sep 2004 21:27:59 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 629D443D41; Fri, 10 Sep 2004 21:27:59 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i8ALRwRi015572; Fri, 10 Sep 2004 17:27:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8ALRwxo037004; Fri, 10 Sep 2004 17:27:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7AD237303F; Fri, 10 Sep 2004 17:27:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040910212758.7AD237303F@freebsd-current.sentex.ca> Date: Fri, 10 Sep 2004 17:27:58 -0400 (EDT) Subject: [releng_5 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, 10 Sep 2004 21:28:00 -0000 TB --- 2004-09-10 20:27:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-10 20:27:11 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2004-09-10 20:27:11 - checking out the source tree TB --- 2004-09-10 20:27:11 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2004-09-10 20:27:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-10 20:34:44 - building world (CFLAGS=-O -pipe) TB --- 2004-09-10 20:34:44 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-10 20:34:44 - /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-09-10 21:23:20 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-10 21:23:20 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-10 21:23:20 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 10 21:23:20 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 [...] : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x15a8): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x1668): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x16ec): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text3+0x0): additional relocation overflows omitted from the output *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/obj/alpha/tinderbox/RELENG_5/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. TB --- 2004-09-10 21:27:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-10 21:27:58 - ERROR: failed to build generic kernel TB --- 2004-09-10 21:27:58 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 23:39: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 2CE6116A4CE; Fri, 10 Sep 2004 23:39:08 +0000 (GMT) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DE443D46; Fri, 10 Sep 2004 23:39:07 +0000 (GMT) (envelope-from cernm0bm@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 10663) id 7A5304673; Sat, 11 Sep 2004 01:37:26 +0200 (CEST) Date: Sat, 11 Sep 2004 01:37:26 +0200 From: Marian Cerny To: Robert Watson , "Bjoern A. Zeeb" , freebsd-current@freebsd.org Message-ID: <20040910233726.GA5781@artax.karlin.mff.cuni.cz> References: <20040910170913.GT72089@funkthat.com> <20040910172623.GA1111@artax.karlin.mff.cuni.cz> <20040910173613.GV72089@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910173613.GV72089@funkthat.com> User-Agent: Mutt/1.5.6i Subject: Re: LOR (re0 and user map) + 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: Fri, 10 Sep 2004 23:39:08 -0000 > > > It would be very useful to know the revision of the file, as well as what > > > line in the code re_rxeof+0x2ae is. (gdb) l *re_rxeof+0x2ae 0xc0575b76 is in re_rxeof (../../../dev/re/if_re.c:1566). 1561 } 1562 m = sc->rl_head; 1563 sc->rl_head = sc->rl_tail = NULL; 1564 m->m_pkthdr.len = total_len - ETHER_CRC_LEN; 1565 } else 1566 m->m_pkthdr.len = m->m_len = 1567 (total_len - ETHER_CRC_LEN); 1568 1569 ifp->if_ipackets++; 1570 m->m_pkthdr.rcvif = ifp; > Could you try using if_re.c from HEAD? I plan to merge the code from > HEAD into RELENG_5 shortly. I used if_re.c from HEAD with this little modification (I was getting some compilation error on line 171): *** if_re.c Sat Sep 11 01:23:46 2004 --- if_re.c.orig Sat Sep 11 01:23:34 2004 *************** *** 168,174 **** "RealTek 8169S Single-chip Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8110S, "RealTek 8110S Single-chip Gigabit Ethernet" }, ! { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8110S, "Corega CG-LAPCIGT (RTL8169S) Gigabit Ethernet" }, { 0, 0, 0, NULL } }; --- 168,174 ---- "RealTek 8169S Single-chip Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8110S, "RealTek 8110S Single-chip Gigabit Ethernet" }, ! { COREGA_VENDORID, COREGA_DEVICEID_CGLAPCIGT, RL_HWREV_8169S, "Corega CG-LAPCIGT (RTL8169S) Gigabit Ethernet" }, { 0, 0, 0, NULL } }; I'm not getting LORs. But the problem still exists there. On 'halt -p' I still get this PANIC. I thought that re without GIANT could help my problem with cvsup, which is described in PR i386/70832. It didn't, too :-(. -- Marian Cerny Jabber: jojo@njs.netlab.cz [ UNIX is user friendly. It's just selective about who its friends are. ] From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 02:59: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 9FF7B16A4CE; Sat, 11 Sep 2004 02:59:40 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3060843D58; Sat, 11 Sep 2004 02:59:40 +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 i8B2xd54056002; Fri, 10 Sep 2004 22:59:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8B2xdu8088447; Fri, 10 Sep 2004 22:59:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3B05F7303F; Fri, 10 Sep 2004 22:59:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040911025939.3B05F7303F@freebsd-current.sentex.ca> Date: Fri, 10 Sep 2004 22:59:39 -0400 (EDT) Subject: [releng_5 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, 11 Sep 2004 02:59:40 -0000 TB --- 2004-09-11 01:32:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-11 01:32:01 - starting RELENG_5 tinderbox run for ia64/ia64 TB --- 2004-09-11 01:32:01 - checking out the source tree TB --- 2004-09-11 01:32:01 - cd /home/tinderbox/RELENG_5/ia64/ia64 TB --- 2004-09-11 01:32:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-11 01:39:42 - building world (CFLAGS=-O -pipe) TB --- 2004-09-11 01:39:42 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-11 01:39:42 - /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-09-11 02:39:43 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-11 02:39:43 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-11 02:39:43 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 11 02:39:43 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 >>> Kernel build for GENERIC completed on Sat Sep 11 02:52:48 UTC 2004 TB --- 2004-09-11 02:52:48 - generating LINT kernel config TB --- 2004-09-11 02:52:48 - cd /home/tinderbox/RELENG_5/ia64/ia64/src/sys/ia64/conf TB --- 2004-09-11 02:52:48 - /usr/bin/make -B LINT TB --- 2004-09-11 02:52:48 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-11 02:52:48 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-11 02:52:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 11 02:52: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 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/gate/g_gate.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_iso9660.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_msdosfs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_ufs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2483: warning: 'sc' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/obj/ia64/tinderbox/RELENG_5/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. TB --- 2004-09-11 02:59:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-11 02:59:39 - ERROR: failed to build lint kernel TB --- 2004-09-11 02:59:39 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 03:15: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 EC6DB16A4CE; Sat, 11 Sep 2004 03:15:32 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8592F43D41; Sat, 11 Sep 2004 03:15:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i8B3FVGT022665; Fri, 10 Sep 2004 23:15:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8B3FVQk093807; Fri, 10 Sep 2004 23:15:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9F4607303F; Fri, 10 Sep 2004 23:15:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040911031531.9F4607303F@freebsd-current.sentex.ca> Date: Fri, 10 Sep 2004 23:15:31 -0400 (EDT) Subject: [releng_5 tinderbox] failure on powerpc/powerpc 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, 11 Sep 2004 03:15:33 -0000 TB --- 2004-09-11 02:59:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-11 02:59:39 - starting RELENG_5 tinderbox run for powerpc/powerpc TB --- 2004-09-11 02:59:39 - checking out the source tree TB --- 2004-09-11 02:59:39 - cd /home/tinderbox/RELENG_5/powerpc/powerpc TB --- 2004-09-11 02:59:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-11 03:07:23 - building world (CFLAGS=-O -pipe) TB --- 2004-09-11 03:07:23 - cd /home/tinderbox/RELENG_5/powerpc/powerpc/src TB --- 2004-09-11 03:07:23 - /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 [...] cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REP.c -o asn1_TGS_REP.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TGS_REQ.c -o asn1_TGS_REQ.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_Ticket.c -o asn1_Ticket.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TicketFlags.c -o asn1_TicketFlags.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_TransitedEncoding.c -o asn1_TransitedEncoding.So cc -fpic -DPIC -O -pipe -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1 -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1/../../include -DINET6 -c asn1_UNSIGNED.c -o asn1_UNSIGNED.So building shared library libasn1.so.7 Abort trap (core dumped) *** Error code 134 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src/kerberos5/lib/libasn1. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/RELENG_5/powerpc/powerpc/src. TB --- 2004-09-11 03:15:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-11 03:15:31 - ERROR: failed to build world TB --- 2004-09-11 03:15:31 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 04:33: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 451BF16A4CE; Sat, 11 Sep 2004 04:33:31 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8CED43D2D; Sat, 11 Sep 2004 04:33:29 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.33.58] (ppp213A.dyn.pacific.net.au [61.8.33.58]) i8B4X2cb027792; Sat, 11 Sep 2004 14:33:03 +1000 From: Sam Lawrance To: current@freebsd.org Content-Type: text/plain Message-Id: <1094877338.700.64.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 11 Sep 2004 14:35:38 +1000 Content-Transfer-Encoding: 7bit Subject: sysinstall/libdisk BARFs at STRIPE 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, 11 Sep 2004 04:33:31 -0000 I have no idea what's going on in open_disk.c, but it barfs when it encounters my geom stripe partition (t=STRIPE). No doubt there are other unhandled providers. Lukas, i noticed you added code to ignore geom vinum providers, so I cc'ed. Cheers Sam. FreeBSD dirk.no.domain 5.3-BETA3 FreeBSD 5.3-BETA3 #4: Fri Sep 10 08:26:34 EST 2004 sam@dirk.no.domain:/usr/obj/usr/src/sys/GENERIC i386 From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 04:42: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 6C20616A4CE for ; Sat, 11 Sep 2004 04:42:32 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC6F643D2D for ; Sat, 11 Sep 2004 04:42:31 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id A0FBA50BF0; Sat, 11 Sep 2004 13:42:30 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 1503050BEE; Sat, 11 Sep 2004 13:42:29 +0900 (JST) Date: Sat, 11 Sep 2004 13:42:29 +0900 Message-ID: <7m1xh9pgay.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "Elliot Finley" In-Reply-To: <072201c4975c$db5bfa00$32cba1cd@science1> References: <06c601c4973a$1d1c5570$32cba1cd@science1> <7m8ybip6qm.wl@black.imgsrc.co.jp> <072201c4975c$db5bfa00$32cba1cd@science1> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: freebsd-current@freebsd.org Subject: Re: Beta3 core dump 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, 11 Sep 2004 04:42:32 -0000 At Fri, 10 Sep 2004 11:37:33 -0600, Elliot Finley wrote: > I made the change, then I did a 'make && make install' in /usr/src/lib/libc. > It still core dumps. Is there anything else I need to do to put this change > into effect? Hmm, how about using this line instead of "r->linp[0] = 0xffff"? memset(r, 0xff, t->bt_psize); -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 04:44: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 51ABB16A4CE for ; Sat, 11 Sep 2004 04:44:55 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA6F143D1D for ; Sat, 11 Sep 2004 04:44:54 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id BAB8350C1B; Sat, 11 Sep 2004 13:44:53 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 2EC8150C18; Sat, 11 Sep 2004 13:44:52 +0900 (JST) Date: Sat, 11 Sep 2004 13:44:52 +0900 Message-ID: <7mzn3xo1mj.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "Elliot Finley" In-Reply-To: <072201c4975c$db5bfa00$32cba1cd@science1> References: <06c601c4973a$1d1c5570$32cba1cd@science1> <7m8ybip6qm.wl@black.imgsrc.co.jp> <072201c4975c$db5bfa00$32cba1cd@science1> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: freebsd-current@freebsd.org Subject: Re: Beta3 core dump 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, 11 Sep 2004 04:44:55 -0000 At Fri, 10 Sep 2004 11:37:33 -0600, Elliot Finley wrote: > I made the change, then I did a 'make && make install' in /usr/src/lib/libc. > It still core dumps. Is there anything else I need to do to put this change > into effect? Sorry, previous post is ambiguous (memset() should be appeared earlier). Complete lines are: ----- /* Put the new right page for the split into place. */ if ((r = __bt_new(t, &npg)) == NULL) return (NULL); /* XXX: Workaround for broken page data. */ memset(r, 0xff, t->bt_psize); r->pgno = npg; r->lower = BTDATAOFF; r->upper = t->bt_psize; r->nextpg = h->nextpg; r->prevpg = h->pgno; r->flags = h->flags & P_TYPE; ----- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 07:55: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 DAC0B16A4CE for ; Sat, 11 Sep 2004 07:55:12 +0000 (GMT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 657C043D46 for ; Sat, 11 Sep 2004 07:55:12 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd03.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1C62j0-0003Vs-01; Sat, 11 Sep 2004 09:55:10 +0200 Received: from Andro-Beta.Leidinger.net (Ss60RcZJQey2U8ps1xStAvOmZr8HORN9wNzwirnZwGVFp-KAFOexri@[217.83.16.136]) by fmrl03.sul.t-online.com with esmtp id 1C62ix-1bhKO80; Sat, 11 Sep 2004 09:55:07 +0200 Received: from [192.168.1.5] ([192.168.1.5])i8B7tCBe077540; Sat, 11 Sep 2004 09:55:13 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Message-ID: <4142AF18.70208@Leidinger.net> Date: Sat, 11 Sep 2004 09:54:00 +0200 From: Alexander Leidinger User-Agent: Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Brooks Davis References: <200409100017.12733@harryhomeworkstation> <200409100031.35536@harryhomeworkstation> <20040909223755.GA3143@odin.ac.hmc.edu> <200409100042.27877@harryhomeworkstation> <20040909225122.GA4335@odin.ac.hmc.edu> In-Reply-To: <20040909225122.GA4335@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ID: Ss60RcZJQey2U8ps1xStAvOmZr8HORN9wNzwirnZwGVFp-KAFOexri@t-dialin.net X-TOI-MSGID: 2c5ce599-0ba4-451e-b83b-017446370906 cc: freebsd-current@freebsd.org cc: Harald Schmalzbauer Subject: Re: GEOM_GPT on 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: Sat, 11 Sep 2004 07:55:13 -0000 Brooks Davis schrieb: >>Hmm, can I make use of GPT without having boot support? Perhaps you >>have a link handy which illustrates the GPT on disk and the BIOS >>interactivity. Is it possible to have both, MBR and GPT? I can't >>imagine. My particular problem is that I want to have every jail in >>it's own label, but then I have to slice my disk (array), because >>I have roundabout 20 jails, which makes it impossible to rearrange >>label-sizes. > > > While GPT was intended to be the only label on the disk, GEOM does not > have any such restrictions. You can place any label on any geom. My > suggestion would be to allocation a slice or bsdlabel partition for the > GPT. Then use GPT to chop that up to meet the demands of the jails. > For example, you could have: [snip] Another solution would be to use (g)vinum to handle the volume management... Bye, Alexander. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 09:15: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 1FA8116A4CE; Sat, 11 Sep 2004 09:15:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A864743D48; Sat, 11 Sep 2004 09:15:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8B9GOPO021389; Sat, 11 Sep 2004 03:16:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4142C18E.7020208@samsco.org> Date: Sat, 11 Sep 2004 03:12:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, cvs-all@freebsd.org 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 Subject: HEADS UP! RELENG_5 and 6-CURRENT are broken 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, 11 Sep 2004 09:15:42 -0000 All, An unfortunate lasp in judgement happened a few hours ago and some untested commits were made to both RELENG_5 and HEAD that result in both branches being upbootable. I'm going to correct that now, and will hopefully be done in about 30-45 minutes. Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 10:00: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 E192A16A4CE for ; Sat, 11 Sep 2004 10:00:06 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A3343D54 for ; Sat, 11 Sep 2004 10:00:06 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8B9xj01048328; Sat, 11 Sep 2004 02:59:49 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409110959.i8B9xj01048328@gw.catspoiler.org> Date: Sat, 11 Sep 2004 02:59:45 -0700 (PDT) From: Don Lewis To: julian@elischer.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: page fault in sched_pin() 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, 11 Sep 2004 10:00:07 -0000 I just cvsup'ed a few hours ago and I'm getting a page fault in sched_pin() early in the boot process. It looks like a NULL pointer dereference. I'm using SCHED_4BSD+PREEMPTION. It looks like the problem is that proc0_init() (which calls schedinit()) needs to be called before kmeminit(), so that the thread0->td_sched is initialized before it is dereferenced in sched_pin(). The SYSINIT for kmeminit() is SI_SUB_KMEM, which is defined as 0x1800000, while the SYSINIT for proc0_init() is SI_SUB_INTRINSIC, which is defined as 0x2200000. An alternative would be to make sched_pin() a no-op this early in the boot process. 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 #241: Sat Sep 11 02:23:16 PDT 2004 dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB WARNING: WITNESS option enabled, expect reduced performance. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x30 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0620c47 stack pointer = 0x10:0xc0c21cc0 frame pointer = 0x10:0xc0c21cc0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () [thread 0] Stopped at sched_pin+0xf: incl 0x30(%eax) db> tr sched_pin(c0c21cdc,c07a0edc,c1047828,bfeff000,c103a000) at sched_pin+0xf pmap_zero_page(c1047828,bfeff000,c103a000,c0c21cf4,c075f724) at pmap_zero_page+0x35 pmap_growkernel(d6247000) at pmap_growkernel+0xf4 vm_map_findspace(c103a000,bfeff000,14000000,c08d3c3c) at vm_map_findspace+0x118 vm_map_find(c103a000,0,0,0,c08d3c3c,14000000,1,7,7,0) at vm_map_find+0x41 kmem_suballoc(c103a000,c08d3c3c,c08d3c40,14000000,14000) at kmem_suballoc+0x36 kmeminit(0,c1ec00,c1e000,0,c0440b85) at kmeminit+0xe5 mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 10:06: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 0C88216A4CE; Sat, 11 Sep 2004 10:06:24 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DACB43D5E; Sat, 11 Sep 2004 10:06:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-123-112-186.dsl.snfc21.pacbell.net [68.123.112.186])i8BA6Jvd146450; Sat, 11 Sep 2004 06:06:21 -0400 Message-ID: <4142CE1B.3000100@elischer.org> Date: Sat, 11 Sep 2004 03:06:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Don Lewis References: <200409110959.i8B9xj01048328@gw.catspoiler.org> In-Reply-To: <200409110959.i8B9xj01048328@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: page fault in sched_pin() 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, 11 Sep 2004 10:06:24 -0000 yeah we know and are just committing the fix.. Don Lewis wrote: > I just cvsup'ed a few hours ago and I'm getting a page fault in > sched_pin() early in the boot process. It looks like a NULL pointer > dereference. I'm using SCHED_4BSD+PREEMPTION. > > It looks like the problem is that proc0_init() (which calls schedinit()) > needs to be called before kmeminit(), so that the thread0->td_sched is > initialized before it is dereferenced in sched_pin(). > > The SYSINIT for kmeminit() is SI_SUB_KMEM, which is defined as > 0x1800000, while the SYSINIT for proc0_init() is SI_SUB_INTRINSIC, which > is defined as 0x2200000. > > An alternative would be to make sched_pin() a no-op this early in the > boot process. > > > 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 #241: Sat Sep 11 02:23:16 PDT 2004 > dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB > WARNING: WITNESS option enabled, expect reduced performance. > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x30 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0620c47 > stack pointer = 0x10:0xc0c21cc0 > frame pointer = 0x10:0xc0c21cc0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > [thread 0] > Stopped at sched_pin+0xf: incl 0x30(%eax) > db> tr > sched_pin(c0c21cdc,c07a0edc,c1047828,bfeff000,c103a000) at sched_pin+0xf > pmap_zero_page(c1047828,bfeff000,c103a000,c0c21cf4,c075f724) at pmap_zero_page+0x35 > pmap_growkernel(d6247000) at pmap_growkernel+0xf4 > vm_map_findspace(c103a000,bfeff000,14000000,c08d3c3c) at vm_map_findspace+0x118 > vm_map_find(c103a000,0,0,0,c08d3c3c,14000000,1,7,7,0) at vm_map_find+0x41 > kmem_suballoc(c103a000,c08d3c3c,c08d3c40,14000000,14000) at kmem_suballoc+0x36 > kmeminit(0,c1ec00,c1e000,0,c0440b85) at kmeminit+0xe5 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > db> > > _______________________________________________ > 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 Sep 11 10:38: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 4489B16A4CE; Sat, 11 Sep 2004 10:38:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 699FF43D45; Sat, 11 Sep 2004 10:38:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8BAdcBG021667; Sat, 11 Sep 2004 04:39:39 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4142D510.8000504@samsco.org> Date: Sat, 11 Sep 2004 04:36:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, cvs-all@freebsd.org 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 Subject: HEADS UP: All clear on RELENG_5 and HEAD 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, 11 Sep 2004 10:38:59 -0000 All, I'm done fixing the RELENG_5 and HEAD src trees. Sorry for the churn. Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 10:41: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 65A5916A4CE; Sat, 11 Sep 2004 10:41:17 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1DE343D1F; Sat, 11 Sep 2004 10:41:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-123-112-186.dsl.snfc21.pacbell.net [68.123.112.186])i8BAfC3d115374; Sat, 11 Sep 2004 06:41:15 -0400 Message-ID: <4142D648.5040605@elischer.org> Date: Sat, 11 Sep 2004 03:41:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Don Lewis References: <200409110959.i8B9xj01048328@gw.catspoiler.org> In-Reply-To: <200409110959.i8B9xj01048328@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: page fault in sched_pin() 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, 11 Sep 2004 10:41:17 -0000 Don Lewis wrote: > I just cvsup'ed a few hours ago and I'm getting a page fault in > sched_pin() early in the boot process. It looks like a NULL pointer > dereference. I'm using SCHED_4BSD+PREEMPTION. > > It looks like the problem is that proc0_init() (which calls schedinit()) > needs to be called before kmeminit(), so that the thread0->td_sched is > initialized before it is dereferenced in sched_pin(). > > The SYSINIT for kmeminit() is SI_SUB_KMEM, which is defined as > 0x1800000, while the SYSINIT for proc0_init() is SI_SUB_INTRINSIC, which > is defined as 0x2200000. > > An alternative would be to make sched_pin() a no-op this early in the > boot process. Both are ok, but the answer we will do is to store teh pinned value directly in the thread structure as it was originally.. that will be the "quick fix" that we are committing now, effectively puting things back as they were before. I am not sure why this appeared to work on my system. My only thought is that I wasn't booting off the kernel I thught I was booting off. There was a big rush to get it in before scott changed the name.. Ultimatly there are a number of fixes, The first one, that Peter suggested abou a month ago on reviewing some code, is to allocate the td_sched structure along with the td structure, and use non indirect methods to access it. This requires that thread0 and ksegrp0 and proc0 be actually declared in sched_4bsd.c and sched_ule.c so that the size of the whole structure can be known at compile time. (thus getting rid of the td->td_sched pointer completely). The second would be to do as Seigo Tanimura suggested and make a separate SYSINIT section for this stuff evenearlier than the kmeminit() SYSINIT. The third is to decide that this value is not scheduler specific and remove it from the scheduler inteface and make it part of the standard proc interface (which is sort of what we are doing now to fix this). The "correct" version of this would put the pin in the thread structure but define the pinning actors in smp.h instead of sched.h as they would no longer be part of the sched framework but instead part of the SMP framework. (or in proc.h). I have been planing on using peter's sugestion all along as it makes all references to the td_sched structure faster throughout the entire scheduler, but I didn't want o do it to start with as it would hav emade the diff HUGE. The belt and suspenders answer is to do both what we are doing, AND to do what peter suggested later.. so the patch that Scott just committed will get things fixed again, but A later set of patches will change the way that the td_sched structure is allocated and accessed everywhere which willl actually be quicker, AND the definition if the pinning operation will go into proc.h or smp.h so as to not sugest that they are part of the scheduler framework. Seigo's solution might also hold water as there might be an argument for having a place in which all static setup should be done. before we start fooling with kernel vm. Having the pin functions do nothing early on is feasible but not good as it would require some sort of test that would slow down operations after we have booted. > > > 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 #241: Sat Sep 11 02:23:16 PDT 2004 > dl@scratch.catspoiler.org:/usr/obj/usr/src/sys/GENERICSMB > WARNING: WITNESS option enabled, expect reduced performance. > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x30 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0620c47 > stack pointer = 0x10:0xc0c21cc0 > frame pointer = 0x10:0xc0c21cc0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > [thread 0] > Stopped at sched_pin+0xf: incl 0x30(%eax) > db> tr > sched_pin(c0c21cdc,c07a0edc,c1047828,bfeff000,c103a000) at sched_pin+0xf > pmap_zero_page(c1047828,bfeff000,c103a000,c0c21cf4,c075f724) at pmap_zero_page+0x35 > pmap_growkernel(d6247000) at pmap_growkernel+0xf4 > vm_map_findspace(c103a000,bfeff000,14000000,c08d3c3c) at vm_map_findspace+0x118 > vm_map_find(c103a000,0,0,0,c08d3c3c,14000000,1,7,7,0) at vm_map_find+0x41 > kmem_suballoc(c103a000,c08d3c3c,c08d3c40,14000000,14000) at kmem_suballoc+0x36 > kmeminit(0,c1ec00,c1e000,0,c0440b85) at kmeminit+0xe5 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > db> > > _______________________________________________ > 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 Sep 11 10:50: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 0399216A4CF for ; Sat, 11 Sep 2004 10:50:24 +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 DC14D43D53 for ; Sat, 11 Sep 2004 10:50:08 +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 i8BAo7Rx060469; Sat, 11 Sep 2004 12:50:07 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4142D833.4060802@DeepCore.dk> Date: Sat, 11 Sep 2004 12:49:23 +0200 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: Frode Nordahl References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: Promise PDC20267 ATA RAID, poor write performance 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, 11 Sep 2004 10:50:24 -0000 Frode Nordahl wrote: > Hello, >=20 > I have a intel S845WD1-E board with onboard Promise PDC20267 controller= =2E > The system is set up with a P4 2Ghz with 1GB RAM. > The board also has a Intel ICH2, but that's only used by a CDROM. >=20 > Disks connected: > ad4: 39205MB [79656/16/63] at ata2-master UDM= A100 > ad6: 39205MB [79656/16/63] at ata3-master UDM= A100 >=20 > I have them set up in a RAID1 >=20 > I have tried this on FreeBSD 4.10-RELEASE, and 6-CURRENT (from today)=20 > with similar results. >=20 > I also tried with RAID0, and that showed the same results*2, that is,=20 > ca. 7MB/s write instead of 3.5MB/s. >=20 > I have no previous experience with this hardware on other OS'es, so I'm= =20 > not sure what to expect, but I'm pretty sure it should be better than=20 > this :) >=20 > dmesg included below. >=20 > Doing simple tests show very poor write performance: > (reboot) > # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 588.383886 secs (3564258 bytes/sec) >=20 > (reboot) > # dd if=3Dfill of=3D/dev/null bs=3D1m > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 68.492015 secs (30618927 bytes/sec) OK I got this this setup now: atapci0: port=20 0xb000-0xb03f,0xb400-0xb403,0xb800-0xb807,0xd000-0xd003,0xd400-0xd407=20 mem 0xfd000000-0xfd01ffff irq 16 at device 3.0 on pci0 ad1: 14305MB [29065/16/63] at ata2-master UDMA1= 00 ad2: 14305MB [29065/16/63] at ata3-master UDMA1= 00 ar0: 14305MB [1823/255/63] status: READY subdisks: Controller the same, disks are an earlier verision of those "low=20 profile" Maxtor disks, just somewhat slover than yours. pizzabox# dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 122.908771 secs (17062672 bytes/sec) pizzabox# dd if=3Dfill of=3D/dev/null bs=3D1m 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 78.299524 secs (26783713 bytes/sec) Thats pretty much what I'd expect from this HW, so I risk saying that=20 ATA is working just as it should here. The only thing I could think of was if you have WC (write cache) turned=20 off for some reason which yields this result here: pizzabox# dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 428.874993 secs (4889891 bytes/sec) That looks more like your results, but they are also within what I would = expect when not using WC.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 13:57: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 7D52816A4D7; Sat, 11 Sep 2004 13:57:14 +0000 (GMT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5726C43D58; Sat, 11 Sep 2004 13:57:13 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([141.153.207.21]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040911135712.KOFR6722.out002.verizon.net@[10.0.3.231]>; Sat, 11 Sep 2004 08:57:12 -0500 From: "Alexandre \"Sunny\" Kovalenko" To: Don Lewis In-Reply-To: <200409080257.i882vXnB040143@gw.catspoiler.org> References: <200409080257.i882vXnB040143@gw.catspoiler.org> Content-Type: text/plain Message-Id: <1094910994.15695.13.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 11 Sep 2004 09:56:34 -0400 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [141.153.207.21] at Sat, 11 Sep 2004 08:57:11 -0500 cc: freebsd-current@FreeBSD.org Subject: Re: pcm0:play:0: play interrupt timeout, channel dead 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, 11 Sep 2004 13:57:14 -0000 On Tue, 2004-09-07 at 22:57, Don Lewis wrote: > On 7 Sep, Alexandre "Sunny" Kovalenko wrote: > > On Tue, 2004-09-07 at 04:14, Guido van Rooij wrote: > >> I have this problem when using skype. Normal sound playback via e.g. > >> xmms goes well. This is on a Dell Latitude D600. > >> > >> Underneath my dmesg (witout ACPI, with ACPI I get the same results). > >> > >> > cat /dev/sndstat > >> FreeBSD Audio Driver (newpcm) > >> Installed devices: > >> pcm0: at io 0xf4fff800, 0xf4fff400 irq 11 bufsz 16384 (1p/1r/0v channels duplex default) > >> > >> > > There is an odd looking bit of code in > > /usr/src/sys/dev/sound/pcm/channel.c (function chn_write): > > > > if (timeout < 1) > > timeout = 1; > > timeout = 1; > > ret = chn_sleep(c, "pcmwr", timeout); > > > > (notice that timeout is always 1). > > > > If you feel adventurous, you can hardcode it to something like 30 and > > see if a) message disappears b) you get normal sound. In my case (a) > > happened and (b) did not -- I got distorted sound, but I was playing > > with USB audio device, which has features not supported by the driver. > > This has been discussed before on the list. The statement immediately > before the code fragment that you posted sets timeout to a dynamically > determined value based on the buffer size and sample rate. The 'if' > block forces the timeout to be non-zero if the calculation results in a > zero timeout. Somewhere along the way, someone added the statement to > unconditionally force timeout to 1, most likely to minimize the chance > for skipping or distortion if a wakeup() was missed. The will cause the > 'while' loop to burn a bit more CPU time because it is essentially > running in a polled mode. > > The ich problem appears to be located in ich_intr(). This > hardware-specific interrupt handler does not appear to be seeing the > correct bits in the hardware registers that are supposed to tell it that > an interrupt has occurred in the hardware play channel. > > The "play interrupt timeout, channel dead" message will occur if there > isn't at least one play channel interrupt per second. > FWIW: I have received this message when dealing with USB audio (uaudio driver). Increasing constant eliminated the message. I do not know enough about audio handling to speculate any further. --- Alexandre "Sunny" Kovalenko. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 14:05: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 F28AF16A4CE for ; Sat, 11 Sep 2004 14:05:42 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D62943D3F for ; Sat, 11 Sep 2004 14:05:42 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.1.35] (ti211110a080-2532.bb.online.no [80.212.201.228]) by smtp1.powertech.no (Postfix) with ESMTP id 5B2C3822F; Sat, 11 Sep 2004 16:05:40 +0200 (CEST) In-Reply-To: <4142D833.4060802@DeepCore.dk> References: <4142D833.4060802@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Frode Nordahl Date: Sat, 11 Sep 2004 16:05:39 +0200 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.619) cc: current@freebsd.org Subject: Re: Promise PDC20267 ATA RAID, poor write performance 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, 11 Sep 2004 14:05:43 -0000 On Sep 11, 2004, at 12:49, S=F8ren Schmidt wrote: >> Doing simple tests show very poor write performance: >> (reboot) >> # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 >> 2000+0 records in >> 2000+0 records out >> 2097152000 bytes transferred in 588.383886 secs (3564258 bytes/sec) >> (reboot) >> # dd if=3Dfill of=3D/dev/null bs=3D1m >> 2000+0 records in >> 2000+0 records out >> 2097152000 bytes transferred in 68.492015 secs (30618927 bytes/sec) > > The only thing I could think of was if you have WC (write cache)=20 > turned off for some reason which yields this result here: When you say WC, you mean hw.ata.wc, right? It was enabled. I tried to disable it, and things actually got faster. # dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 346.250049 secs (6056756 bytes/sec) Maybe there is some timing issues here somewhere, or just flaky cables=20= :-/ I'll test with other cables and disks and get back. atacontrol cap shows that the disk has write cache as well as read=20 ahead enabled, is it possible to tune this using FreeBSD tools? Mvh, Frode > pizzabox# dd if=3D/dev/zero of=3Dfill bs=3D1m count=3D2000 > 2000+0 records in > 2000+0 records out > 2097152000 bytes transferred in 428.874993 secs (4889891 bytes/sec) > > That looks more like your results, but they are also within what I=20 > would expect when not using WC.. > > > -S=F8ren > From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 14: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 BBD0316A4CE for ; Sat, 11 Sep 2004 14:25:10 +0000 (GMT) Received: from www.cray1.de (i.would.like.to.spoof.my.realip.de [64.27.85.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15A5843D46 for ; Sat, 11 Sep 2004 14:25:10 +0000 (GMT) (envelope-from ubm@u-boot-man.de) Received: from greatsheep.marines (localhost [127.0.0.1]) by www.cray1.de (8.9.3/8.9.3) with SMTP id QAA23068 for ; Sat, 11 Sep 2004 16:25:05 +0200 Date: Sat, 11 Sep 2004 16:28:25 +0200 From: Marc "UBM" Bocklet To: current@freebsd.org Message-Id: <20040911162825.418068e7.ubm@u-boot-man.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__11_Sep_2004_16_28_25_+0200_X+JlJ6oHwM_FAHE8" Subject: two LORs with acx driver and 6-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, 11 Sep 2004 14:25:10 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__11_Sep_2004_16_28_25_+0200_X+JlJ6oHwM_FAHE8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hiho! :-) I played around a bit with the acx driver from wlan.kewl.org and encountered the following two LORs in the process. This time I was intelligent enough to consult the LOR page first, but I did not find them listed there. What I did: configure acx0 for hostap mode enable bridging between acx0 and rl0 connect to the acx0 access point via another wlan card. More info: running with debug.mpsafenet=1 FreeBSD ubm.marines 6.0-CURRENT FreeBSD 6.0-CURRENT #4: Wed Aug 25 20:33:53 CEST 2004 root@ubm.marines:/usr/obj/usr/src/sys/SHEEP i386 dmesg is attached. Teh LORs: http://www.u-boot-man.de/~mbocklet/lors.txt Hope this helps. :-) Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming --Multipart=_Sat__11_Sep_2004_16_28_25_+0200_X+JlJ6oHwM_FAHE8 Content-Type: application/octet-stream; name="dmesg.boot" Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMC1DVVJSRU5UICM0OiBXZWQgQXVnIDI1IDIwOjMzOjUz IENFU1QgMjAwNAogICAgcm9vdEB1Ym0ubWFyaW5lczovdXNyL29iai91c3Ivc3JjL3N5cy9TSEVF UApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3Jt YW5jZS4KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAK Q1BVOiBJbnRlbChSKSBQZW50aXVtKFIpIDQgQ1BVIDIuNDBHSHogKDIzOTMuOTQtTUh6IDY4Ni1j bGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHhmMjQgIFN0ZXBwaW5n ID0gNAogIEZlYXR1cmVzPTB4M2ZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNF LENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQ SSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0+CnJlYWwgbWVtb3J5ICA9IDUzNjgwNTM3NiAo NTExIE1CKQphdmFpbCBtZW1vcnkgPSA1MTU2MjA4NjQgKDQ5MSBNQikKQUNQSSBBUElDIFRhYmxl OiA8SW50ZWxSIEFXUkRBQ1BJPgpQZW50aXVtIDQgVENDIHN1cHBvcnQgZW5hYmxlZCwgOCBzdGVw cyBmcm9tIDEwMCUgdG8gMTMlLCBjdXJyZW50IHBlcmZvcm1hbmNlIDUwJQppb2FwaWMwIDxWZXJz aW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCm5weDA6IFtGQVNUXQpucHgwOiA8bWF0 aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6 IDxJbnRlbFIgQVdSREFDUEk+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZp eGVkKQpUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5 IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0 MDgtMHg0MGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMAphY3BpX3R6MDogPFRo ZXJtYWwgWm9uZT4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3Bp MApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkw CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCmFncDA6IDxJbnRlbCA4Mjg1MCBob3N0IHRv IEFHUCBicmlkZ2U+IG1lbSAweGUwMDAwMDAwLTB4ZTNmZmZmZmYgYXQgZGV2aWNlIDAuMCBvbiBw Y2kwCnBjaWIxOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8 UENJIGJ1cz4gb24gcGNpYjEKcGNpMTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2kxOiA8ZGlzcGxheT4gYXQgZGV2aWNlIDAuMSAobm8gZHJpdmVy IGF0dGFjaGVkKQp1aGNpMDogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVT Qi1BPiBwb3J0IDB4ZDgwMC0weGQ4MWYgaXJxIDE2IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhj aTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJv bGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogSW50ZWwg VUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8SW50ZWwgODI4MDFE QiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhkMDAwLTB4ZDAxZiBpcnEgMTkg YXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMTogW0dJQU5ULUxPQ0tFRF0KdXNiMTogPEludGVs IDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1c2IxOiBVU0Ig cmV2aXNpb24gMS4wCnVodWIxOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKdWhjaTI6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQz4g cG9ydCAweGQ0MDAtMHhkNDFmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2kyOiBb R0lBTlQtTE9DS0VEXQp1c2IyOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIg VVNCLUM+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IEludGVsIFVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIyOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVT QiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZTQyMDAwMDAtMHhlNDIwMDNmZiBpcnEgMjMgYXQgZGV2 aWNlIDI5Ljcgb24gcGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KZWhjaV9wY2lfYXR0YWNoOiBj b21wYW5pb24gdXNiMAplaGNpX3BjaV9hdHRhY2g6IGNvbXBhbmlvbiB1c2IxCmVoY2lfcGNpX2F0 dGFjaDogY29tcGFuaW9uIHVzYjIKdXNiMzogRUhDSSB2ZXJzaW9uIDEuMAp1c2IzOiBjb21wYW5p b24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVzYjIKdXNiMzogPEVIQ0kg KGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKdXNiMzogVVNCIHJldmlzaW9u IDIuMAp1aHViMzogSW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAw LCBhZGRyIDEKdWh1YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBj aWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2kyOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgphdGFwY2kwOiA8SGlnaFBvaW50IEhQVDM3MiBVRE1BMTMz IGNvbnRyb2xsZXI+IHBvcnQgMHhiMDAwLTB4YjBmZiwweGFjMDAtMHhhYzAzLDB4YTgwMC0weGE4 MDcsMHhhNDAwLTB4YTQwMywweGEwMDAtMHhhMDA3IGlycSAyMyBhdCBkZXZpY2UgMC4wIG9uIHBj aTIKYXRhMjogY2hhbm5lbCAjMCBvbiBhdGFwY2kwCmF0YTM6IGNoYW5uZWwgIzEgb24gYXRhcGNp MApybDA6IDxSZWFsVGVrIDgxMzkgMTAvMTAwQmFzZVRYPiBwb3J0IDB4YjQwMC0weGI0ZmYgbWVt IDB4ZTQxMzQwMDAtMHhlNDEzNDBmZiBpcnEgMTggYXQgZGV2aWNlIDEuMCBvbiBwY2kyCm1paWJ1 czA6IDxNSUkgYnVzPiBvbiBybDAKcmxwaHkwOiA8UmVhbFRlayBpbnRlcm5hbCBtZWRpYSBpbnRl cmZhY2U+IG9uIG1paWJ1czAKcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VU WCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpybDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA0OjYxOjQy OmQ4OmJhCmZ3b2hjaTA6IDxUZXhhcyBJbnN0cnVtZW50cyBUU0I0M0FCMjIvQT4gbWVtIDB4ZTQx MzAwMDAtMHhlNDEzM2ZmZiwweGU0MTM2MDAwLTB4ZTQxMzY3ZmYgaXJxIDIwIGF0IGRldmljZSAz LjAgb24gcGNpMgpmd29oY2kwOiBPSENJIHZlcnNpb24gMS4xMCAoUk9NPTApCmZ3b2hjaTA6IE5v LiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBpcyA0Lgpmd29oY2kwOiBFVUk2NCAwMDowNDo2MTow MDowMDowMDo2Njo2Mgpmd29oY2kwOiBQaHkgMTM5NGEgYXZhaWxhYmxlIFM0MDAsIDIgcG9ydHMu CmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3JlYyAyMDQ4IGJ5dGVzLgpmaXJld2lyZTA6IDxJRUVF MTM5NChGaXJlV2lyZSkgYnVzPiBvbiBmd29oY2kwCmZ3ZTA6IDxFdGhlcm5ldCBvdmVyIEZpcmVX aXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRyZXNzOiAwMjowNDo2 MTowMDo2Njo2Mgpmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjowNDo2MTowMDo2Njo2Mgpmd2Uw OiBpZl9zdGFydCBydW5uaW5nIGRlZmVycmVkIGZvciBHaWFudApzYnAwOiA8U0JQLTIvU0NTSSBv dmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3 b2hjaTA6IG5vZGVfaWQ9MHhjODAwZmZjMCwgZ2VuPTEsIENZQ0xFTUFTVEVSIG1vZGUKZmlyZXdp cmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDog YnVzIG1hbmFnZXIgMCAobWUpCmFjeDA6IDxUZXhhcyBJbnN0cnVtZW50cyAoVEkpIDgwMi4xMWIr IDIyTWJwcyBXaXJlbGVzcyBBZGFwdGVyPiBwb3J0IDB4YjgwMC0weGI4MWYgbWVtIDB4ZTQxMjAw MDAtMHhlNDEyZmZmZiwweGU0MTM1MDAwLTB4ZTQxMzVmZmYgaXJxIDIwIGF0IGRldmljZSA2LjAg b24gcGNpMgphY3gwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDowMzoyZjowOTphZDo5MQphY3gwOiAx MWIgcmF0ZXM6IDFNYnBzIDJNYnBzIDUuNU1icHMgMTFNYnBzCmFjeDA6IDgwMi4xMSBhZGRyZXNz OiAwMDowMzoyZjowOTphZDo5MQphY3gwOiBFZXByb20gUmV2IDQgRG9tYWluIEVUU0kgRXVyb3Bl ICgxLTEzKSwgRmlybXdhcmUgUmV2IDEuOS44LmIKYWN4MDogUmFkaW8gVHlwZSAweDExLCBBbnRl bm5hIDB4MDAsIENDQSBNb2RlIDB4MGQsIEVEIFRocmVzaG9sZCAweDcwCmFjeDA6IChjKSBodHRw Oi8vd2xhbi5rZXdsLm9yZy8gMjAwMy0yMDA0CnBjaTI6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQg ZGV2aWNlIDcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBh dCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kxOiA8 SW50ZWwgSUNINCBVRE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHhmMDAwLTB4ZjAwZiwweDM3Niww eDE3MC0weDE3NywweDNmNiwweDFmMC0weDFmNyBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6 IGNoYW5uZWwgIzAgb24gYXRhcGNpMQphdGExOiBjaGFubmVsICMxIG9uIGF0YXBjaTEKaWNoc21i MDogPEludGVsIDgyODAxREMgKElDSDQpIFNNQnVzIGNvbnRyb2xsZXI+IHBvcnQgMHg1MDAtMHg1 MWYgaXJxIDE3IGF0IGRldmljZSAzMS4zIG9uIHBjaTAKaWNoc21iMDogW0dJQU5ULUxPQ0tFRF0K c21idXMwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBpY2hzbWIwCmZkYzA6IDxmbG9wcHkg ZHJpdmUgY29udHJvbGxlcj4gcG9ydCAweDNmNywweDNmMC0weDNmNSBpcnEgNiBkcnEgMiBvbiBh Y3BpMApmZGMwOiBpY190eXBlIDkwIHBhcnRfaWQgODAKc2lvMCBwb3J0IDB4M2Y4LTB4M2ZmIGly cSA0IG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzEgcG9ydCAweDJmOC0weDJmZiBpcnEg MyBvbiBhY3BpMApzaW8xOiB0eXBlIDE2NTUwQQpwcGMwIHBvcnQgMHg3NzgtMHg3N2IsMHgzNzgt MHgzN2YgaXJxIDcgZHJxIDMgb24gYWNwaTAKcHBjMDogU01DLWxpa2UgY2hpcHNldCAoRUNQL0VQ UC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2Lzkg Ynl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCnBsaXAw OiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4gb24gcHBidXMwCmxwdDA6IDxQcmludGVyPiBvbiBw cGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9u IHBwYnVzMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjQs MHg2MCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IDxQUy8yIE1vdXNl PiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBtb2RlbCBNb3Vz ZU1hbissIGRldmljZSBJRCAwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjMDAw MC0weGNjZmZmIG9uIGlzYTAKcG10aW1lcjAgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4g YXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxh Z3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9t ZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDIz OTM5MzYxOTYgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1z ZWMKQVRBUElfUkVTRVQgdGltZSA9IDE4NDIwdXMKQVRBUElfUkVTRVQgdGltZSA9IDMwdXMKYWNk MDogQ0RSVyA8X05FQyBEVkQrUlcgTkQtMTEwMEEvMS5BMz4gYXQgYXRhMC1tYXN0ZXIgVURNQTMz CmFjZDE6IENEUlcgPExJVEUtT04gTFRSLTEyMTAxQi9MUzNHPiBhdCBhdGEwLXNsYXZlIFBJTzQK QVRBUElfUkVTRVQgdGltZSA9IDEwdXMKYWQyOiAzODE2Nk1CIDxTVDM0MDAxNUEvMy4wMT4gWzc3 NTQ1LzE2LzYzXSBhdCBhdGExLW1hc3RlciBVRE1BMTAwCmFjZDI6IERWRFJPTSA8VE9TSElCQSBE VkQtUk9NIFNELU0xNzEyL0owMDQ+IGF0IGF0YTEtc2xhdmUgVURNQTMzCmFkNDogNzYzMTlNQiA8 U1QzODAwMjBBLzMuMzk+IFsxNTUwNjEvMTYvNjNdIGF0IGF0YTItbWFzdGVyIFVETUExMDAKYWQ2 OiA3ODE2N01CIDxNYXh0b3IgNFIwODBMMC9SQU1CMVRVMD4gWzE1ODgxNi8xNi82M10gYXQgYXRh My1tYXN0ZXIgVURNQTEzMwphZDc6IDU4NjI3TUIgPE1heHRvciA0RDA2MEgzL0RBSDAxN0swPiBb MTE5MTE3LzE2LzYzXSBhdCBhdGEzLXNsYXZlIFVETUExMDAKTW91bnRpbmcgcm9vdCBmcm9tIHVm czovZGV2L2FkMnM0YQo= --Multipart=_Sat__11_Sep_2004_16_28_25_+0200_X+JlJ6oHwM_FAHE8-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 14:27: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 6553D16A4CE for ; Fri, 10 Sep 2004 14:27:48 +0000 (GMT) Received: from GreenSrv.rz.unibw-muenchen.de (greensrv.RZ.UniBw-Muenchen.de [137.193.10.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F32143D31 for ; Fri, 10 Sep 2004 14:27:47 +0000 (GMT) (envelope-from lutz@medusa.informatik.unibw-muenchen.de) Received: from localhost (GreenSrv [127.0.0.1])i8AEQ4ZI010888 for ; Fri, 10 Sep 2004 16:26:04 +0200 Received: from GreenSrv.rz.unibw-muenchen.de ([127.0.0.1]) by localhost (GreenSrv [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10816-01 for ; Fri, 10 Sep 2004 16:26:00 +0200 (CEST) Received: from medusa.informatik.unibw-muenchen.de (medusa.Informatik.UniBw-Muenchen.de [137.193.60.34])i8AEPxhl010882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2004 16:25:59 +0200 X-Remarks: If SPAM is relayed via GreenSrv.rz.unibw-muenchen.de to outside of unibw-muenchen.de, please report it to abuse@unibw-muenchen.de Received: from lutz by medusa.informatik.unibw-muenchen.de with local (Exim 4.42 (FreeBSD)) id 1C5mK5-000IoT-MS for current@freebsd.org; Fri, 10 Sep 2004 16:24:22 +0200 From: Lutz Bichler Organization: University of the Federal Armed Forces Munich To: current@freebsd.org Date: Fri, 10 Sep 2004 16:24:21 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409101624.21412.Lutz.Bichler@unibw-muenchen.de> Sender: Lutz Bichler X-Virus-Scanned: by amavisd-new at GreenSrv.rz.unibw-muenchen.de X-Mailman-Approved-At: Sat, 11 Sep 2004 14:47:09 +0000 Subject: Problem with snd_ich.ko 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, 10 Sep 2004 14:27:48 -0000 Hi, i have a "funny" problem with snd_ich on 5.3 Beta3. Whenever i boot my machine, sound.ko and snd_ich.ko are loaded, but i do not get any sound working. After unloading and reloading snd_ich.ko things work fine. Any idea abou what going wrong at boot-time loading of the modules? Some information about my machine: lutz@medusa:~> cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0x1000, 0x2000 irq 5 bufsz 16384 kld snd_ich (1p/1r/0v channels duplex default) lutz@medusa:~> pciconf -vl pcm0@pci0:31:5: class=0x040100 card=0x0056110a chip=0x24458086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) AC'97 Audio Controller' class = multimedia subclass = audio Regards, Lutz From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 23:14: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 74E0416A4CE; Fri, 10 Sep 2004 23:14:18 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0495C43D45; Fri, 10 Sep 2004 23:14:18 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from hoppel.local (port-212-202-38-171.dynamic.qsc.de [212.202.38.171]) by mail.efacilitas.de (Postfix) with ESMTP id 3FAD3123961; Sat, 11 Sep 2004 00:45:52 +0200 (CEST) Received: from alpha (unknown [192.168.1.2]) by hoppel.local (Postfix) with ESMTP id 9B70D631D; Sat, 11 Sep 2004 00:46:42 +0200 (CEST) From: "Bjoern Koenig" To: Date: Sat, 11 Sep 2004 00:48:05 +0200 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 Thread-Index: AcSXiDxHpahpN9UFQ064VGM6hWtwww== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20040910224642.9B70D631D@hoppel.local> X-Mailman-Approved-At: Sat, 11 Sep 2004 14:47:09 +0000 cc: sos@freebsd.org cc: sos@deepcore.dk Subject: profiling data of lacking ICH2 (was: poor ATA disk speed with ICH2) 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, 10 Sep 2004 23:14:18 -0000 Hello again, I built a recent GENERIC kernel (1.413.2.2 2004/09/09 23:10:48 scottl) = with high resolution kernel profiling (config -pp). I ran a little shell = script in single-user mode which looks like [...] kgmon -rB dd if=3D/dev/zero of=3D/usr/out bs=3D4096 count=3D262144 kgmon -hpr [...] and created the following output with gprof: =20 http://www.alpha-tierchen.de/dateien/gprof.out.txt (I'm sorry for posting this external link, but I didn't like to append ~15000 lines to this mail ;-) This is my dmesg: http://www.alpha-tierchen.de/dateien/dmesg.txt hw.ata.wc=3D1 hw.ata.ata_dma=3D1 The dd command told ~15 MB/s without profiling (~500 kB/s with = profiling). There is absolutely no failure with the hard disk and the controller, because after that I installed a 4.10-RELEASE into the same slice and it works pretty fine (~37 MB/s). I repeated this test at another position = on hard disk _completely_ ... and as expected I got similar results. I hope the profiling data helps. I would like to see a gprof output of a system which works correctly, otherwise I have no possibility to = compare. I have the time and motivation to analyse them and point out the = difference. best regards Bj=F6rn K=F6nig From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 15:19: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 4F9B016A4CE for ; Sat, 11 Sep 2004 15:19:37 +0000 (GMT) Received: from thunderbird.etv.net (thunderbird.etv.net [208.14.190.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D380943D4C for ; Sat, 11 Sep 2004 15:19:36 +0000 (GMT) (envelope-from lists@efinley.com) Received: from [205.161.203.50] (helo=science1) by thunderbird.etv.net with smtp (Exim 4.34 (FreeBSD)) id 1C69f6-000Jkn-2J; Sat, 11 Sep 2004 09:19:36 -0600 Message-ID: <07bb01c49812$bf4463a0$32cba1cd@science1> From: "Elliot Finley" To: "Jun Kuriyama" References: <06c601c4973a$1d1c5570$32cba1cd@science1><7m8ybip6qm.wl@black.imgsrc.co.jp><072201c4975c$db5bfa00$32cba1cd@science1> <7mzn3xo1mj.wl@black.imgsrc.co.jp> Date: Sat, 11 Sep 2004 09:19:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-current@freebsd.org Subject: Re: Beta3 core dump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Elliot Finley List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 15:19:37 -0000 I made the memset change. It still core dumps. Just so you're clear on what I'm doing. I made the code change, then in /usr/src/lib/libc I do a 'make' then a 'make install', then I do a 'portsdb -fu'. Elliot ----- Original Message ----- From: "Jun Kuriyama" To: "Elliot Finley" Cc: Sent: Friday, September 10, 2004 10:44 PM Subject: Re: Beta3 core dump > At Fri, 10 Sep 2004 11:37:33 -0600, > Elliot Finley wrote: > > I made the change, then I did a 'make && make install' in /usr/src/lib/libc. > > It still core dumps. Is there anything else I need to do to put this change > > into effect? > > Sorry, previous post is ambiguous (memset() should be appeared > earlier). Complete lines are: > > ----- > /* Put the new right page for the split into place. */ > if ((r = __bt_new(t, &npg)) == NULL) > return (NULL); > /* XXX: Workaround for broken page data. */ > memset(r, 0xff, t->bt_psize); > r->pgno = npg; > r->lower = BTDATAOFF; > r->upper = t->bt_psize; > r->nextpg = h->nextpg; > r->prevpg = h->pgno; > r->flags = h->flags & P_TYPE; > ----- > > > -- > Jun Kuriyama // IMG SRC, Inc. > // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 15: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 63DD816A4D0 for ; Sat, 11 Sep 2004 15:27:20 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id B501843D41 for ; Sat, 11 Sep 2004 15:27:19 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 9398750C28; Sun, 12 Sep 2004 00:27:18 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 1F43050C27; Sun, 12 Sep 2004 00:27:17 +0900 (JST) Date: Sun, 12 Sep 2004 00:27:17 +0900 Message-ID: <7my8jgomga.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "Elliot Finley" In-Reply-To: <07bb01c49812$bf4463a0$32cba1cd@science1> References: <06c601c4973a$1d1c5570$32cba1cd@science1> <7m8ybip6qm.wl@black.imgsrc.co.jp> <072201c4975c$db5bfa00$32cba1cd@science1> <7mzn3xo1mj.wl@black.imgsrc.co.jp> <07bb01c49812$bf4463a0$32cba1cd@science1> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: freebsd-current@freebsd.org Subject: Re: Beta3 core dump 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, 11 Sep 2004 15:27:20 -0000 At Sat, 11 Sep 2004 09:19:35 -0600, Elliot Finley wrote: > I made the memset change. It still core dumps. > > Just so you're clear on what I'm doing. I made the code change, then in > /usr/src/lib/libc I do a 'make' then a 'make install', then I do a > 'portsdb -fu'. Thanks. My patch fixes 3 boxes in my office, but I find next one still dumps core even with patch. I'll dig into more... -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 15:51: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 2006C16A4CE; Sat, 11 Sep 2004 15:51:26 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0E2943D1D; Sat, 11 Sep 2004 15:51:25 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.5] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id i8BFpJGJ002842; Sat, 11 Sep 2004 11:51:22 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <4142D648.5040605@elischer.org> References: <200409110959.i8B9xj01048328@gw.catspoiler.org> <4142D648.5040605@elischer.org> Date: Sat, 11 Sep 2004 17:48:08 +0200 To: Julian Elischer From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: Don Lewis cc: freebsd-current@freebsd.org Subject: Re: page fault in sched_pin() 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, 11 Sep 2004 15:51:26 -0000 At 3:41 AM -0700 2004-09-11, Julian Elischer wrote: > I am not sure why this appeared to work on my system. My only thought is that > I wasn't booting off the kernel I thught I was booting off. There was a big > rush to get it in before scott changed the name. Correct me if I'm wrong, but we're in freeze for RELENG_5 preparing for it to become the new -STABLE branch, right? Should not this change have been made only to HEAD, and then merged to RELENG_5 if it was found to be necessary? Assuming that's the case, then why the rush? I'm just curious as to how a mistake like this could have made it into both -HEAD and RELENG_5 simultaneously.... -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 17:15: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 1872F16A4CE for ; Sat, 11 Sep 2004 17:15:51 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E21E43D5D for ; Sat, 11 Sep 2004 17:15:50 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8BHFiYA049175; Sat, 11 Sep 2004 10:15:47 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409111715.i8BHFiYA049175@gw.catspoiler.org> Date: Sat, 11 Sep 2004 10:15:43 -0700 (PDT) From: Don Lewis To: Alex.Kovalenko@verizon.net In-Reply-To: <1094910994.15695.13.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: pcm0:play:0: play interrupt timeout, channel dead 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, 11 Sep 2004 17:15:51 -0000 On 11 Sep, Alexandre "Sunny" Kovalenko wrote: > On Tue, 2004-09-07 at 22:57, Don Lewis wrote: >> On 7 Sep, Alexandre "Sunny" Kovalenko wrote: >> > On Tue, 2004-09-07 at 04:14, Guido van Rooij wrote: >> >> I have this problem when using skype. Normal sound playback via e.g. >> >> xmms goes well. This is on a Dell Latitude D600. >> >> >> >> Underneath my dmesg (witout ACPI, with ACPI I get the same results). >> >> >> >> > cat /dev/sndstat >> >> FreeBSD Audio Driver (newpcm) >> >> Installed devices: >> >> pcm0: at io 0xf4fff800, 0xf4fff400 irq 11 bufsz 16384 (1p/1r/0v channels duplex default) >> >> >> >> >> > There is an odd looking bit of code in >> > /usr/src/sys/dev/sound/pcm/channel.c (function chn_write): >> > >> > if (timeout < 1) >> > timeout = 1; >> > timeout = 1; >> > ret = chn_sleep(c, "pcmwr", timeout); >> > >> > (notice that timeout is always 1). >> > >> > If you feel adventurous, you can hardcode it to something like 30 and >> > see if a) message disappears b) you get normal sound. In my case (a) >> > happened and (b) did not -- I got distorted sound, but I was playing >> > with USB audio device, which has features not supported by the driver. >> >> This has been discussed before on the list. The statement immediately >> before the code fragment that you posted sets timeout to a dynamically >> determined value based on the buffer size and sample rate. The 'if' >> block forces the timeout to be non-zero if the calculation results in a >> zero timeout. Somewhere along the way, someone added the statement to >> unconditionally force timeout to 1, most likely to minimize the chance >> for skipping or distortion if a wakeup() was missed. The will cause the >> 'while' loop to burn a bit more CPU time because it is essentially >> running in a polled mode. >> >> The ich problem appears to be located in ich_intr(). This >> hardware-specific interrupt handler does not appear to be seeing the >> correct bits in the hardware registers that are supposed to tell it that >> an interrupt has occurred in the hardware play channel. >> >> The "play interrupt timeout, channel dead" message will occur if there >> isn't at least one play channel interrupt per second. >> > FWIW: I have received this message when dealing with USB audio (uaudio > driver). Increasing constant eliminated the message. I do not know > enough about audio handling to speculate any further. Are you using a non-default value of HZ in your kernel config file? I don't see any reason why the code should behave differently with the default value of HZ (100) if timeout is set to 1 versus 30. In the first case, the code will sleep 100 times for one tick each time before count reaches zero and the channel is marked as dead. In the second case the code will sleep four times and decrement count by 30 each time before count goes negative. What happens if you set timeout to 33? What about 34? What happens if the two places that set 'count = hz' are changed to 'count = 2 * hz'? Now that chn_sleep() uses msleep(), it should be possible to set timeout to 0, which would give an indefinite wait. If the channel dies, the application will hang, but the application should be killable. It should also be possible to set timeout to hz. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 17:34: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 7AE4A16A4CE for ; Sat, 11 Sep 2004 17:34:20 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA15443D55 for ; Sat, 11 Sep 2004 17:34:17 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i8BHKPjr001525 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 11 Sep 2004 13:20:25 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Gerald Pfeifer Date: Sat, 11 Sep 2004 13:36:14 -0400 User-Agent: KMail/1.6.2 References: <47158390.20040827112834@ulstu.ru> <200409060149.35764.mistry.7@osu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_YezQBsZ0YT1QhQk"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409111336.24239.mistry.7@osu.edu> X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_82, PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL,X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap 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, 11 Sep 2004 17:34:20 -0000 --Boundary-02=_YezQBsZ0YT1QhQk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 September 2004 01:05 pm, you wrote: > On Mon, 6 Sep 2004, Anish Mistry wrote: > > Well I guess this is my lucky day. Apply the attached patch for vm_mmap > > to your kernel and patch the August wine sources with the wine-mmap.pat= ch > > and compile and install wine (be sure to use gmake). This is working on > > my dev system with 6-CURRENT as of Saturday night. > > I currently do not have a 6-CURRENT (or recent 5-STABLE) machine > available, and we probably can't require users of our wine port to > patch their kernel, so we'd really need to see that in a stock kernel. > > Is there any chance someone could review/apply that patch=3D You're the first to reply, and we need a few other people with RELENG_5 or= =20 HEAD to test. > > > The wine mmap patch just doesn't reserve the DOS area so DOS programs m= ay > > not work. This seems to just work around a side effect of the kernel > > mmap patch. > > This i can get into Wine quite easily. > A proper patch for this would be just to #ifdef __FreeBSD__ around that lin= e. > > I still think that the kernel mmap patch has issues so I'm hoping Alan > > can give us some feedback. > > Alan? > > > Anyway this worked for me, YMMV. > > Thanks a lot! > > Gerald =2D-=20 Anish Mistry --Boundary-02=_YezQBsZ0YT1QhQk Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBQzeYxqA5ziudZT0RAnboAKCkSLrixbvjI0Ehp2jWXFGXHQXJJwCgjud7 j+RvtuQW+hPsMfJPKjtUMb8= =jM7R -----END PGP SIGNATURE----- --Boundary-02=_YezQBsZ0YT1QhQk-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 18:00: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 660B516A4CE; Sat, 11 Sep 2004 18:00:16 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD5043D49; Sat, 11 Sep 2004 18:00:14 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8BI05PC021435; Sat, 11 Sep 2004 14:00:05 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8BI008L021434; Sat, 11 Sep 2004 14:00:00 -0400 (EDT) (envelope-from green) Date: Sat, 11 Sep 2004 14:00:00 -0400 From: Brian Fundakowski Feldman To: Anish Mistry Message-ID: <20040911180000.GX928@green.homeunix.org> References: <47158390.20040827112834@ulstu.ru> <200409060149.35764.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409060149.35764.mistry.7@osu.edu> User-Agent: Mutt/1.5.6i cc: Alan Cox cc: anvir@ulstu.ru cc: Gerald Pfeifer cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap 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, 11 Sep 2004 18:00:16 -0000 On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote: > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > > [ John, sorry for the duplicate message; this is the correct one. ] > > > > On Fri, 27 Aug 2004, John Birrell wrote: > > > Anish Mistry has developed a patch to choose an > > > appropriate mmap address. He posted it to -current. I haven't had time to > > > test it. > > > > Thanks for the note. Will you have time to test/commit this before 5.3? > > > > Anish, do you have any news on this patch? (Wine has been broken for a > > couple of months now, and it would be great to have at least 5.3 fixed.) > > > Well I guess this is my lucky day. Apply the attached patch for vm_mmap to > your kernel and patch the August wine sources with the wine-mmap.patch and > compile and install wine (be sure to use gmake). This is working on my dev > system with 6-CURRENT as of Saturday night. > The wine mmap patch just doesn't reserve the DOS area so DOS programs may not > work. This seems to just work around a side effect of the kernel mmap patch. > I still think that the kernel mmap patch has issues so I'm hoping Alan can > give us some feedback. > Anyway this worked for me, YMMV. Do these combined work for you, minus any modifications to mmap(2)? I do not feel that the kernel mmap(2) should be modified in this manner, that it is a strictly userland problem. Index: lib/libpthread/thread/thr_stack.c =================================================================== RCS file: /usr/ncvs/src/lib/libpthread/thread/thr_stack.c,v retrieving revision 1.8 diff -u -r1.8 thr_stack.c --- lib/libpthread/thread/thr_stack.c 14 Sep 2003 22:39:44 -0000 1.8 +++ lib/libpthread/thread/thr_stack.c 11 Sep 2004 17:17:32 -0000 @@ -61,7 +61,7 @@ * Base address of the last stack allocated (including its red zone, if * there is one). Stacks are allocated contiguously, starting beyond the * top of the main stack. When a new stack is created, a red zone is - * typically created (actually, the red zone is simply left unmapped) above + * typically created (actually, the red zone is mapped with PROT_NONE) above * the top of the stack, such that the stack will not be able to grow all * the way to the bottom of the next stack. This isn't fool-proof. It is * possible for a stack to grow by a large amount, such that it grows into @@ -134,6 +134,7 @@ kse_critical_t crit; size_t stacksize; size_t guardsize; + char *stackaddr; /* * Round up stack size to nearest multiple of _thr_page_size so @@ -194,7 +195,7 @@ _thr_guard_default; /* Allocate a new stack. */ - attr->stackaddr_attr = last_stack - stacksize; + stackaddr = last_stack - stacksize - guardsize; /* * Even if stack allocation fails, we don't want to try to @@ -209,11 +210,20 @@ KSE_LOCK_RELEASE(curkse, &_thread_list_lock); _kse_critical_leave(crit); - /* Map the stack, but not the guard page: */ - if ((attr->stackaddr_attr = mmap(attr->stackaddr_attr, - stacksize, PROT_READ | PROT_WRITE, MAP_STACK, - -1, 0)) == MAP_FAILED) - attr->stackaddr_attr = NULL; + /* Map the stack and guard page together, and split guard + page from allocated space: */ + if ((stackaddr = mmap(stackaddr, stacksize+guardsize, + PROT_READ | PROT_WRITE, MAP_STACK, + -1, 0)) != MAP_FAILED && + (guardsize == 0 || + mprotect(stackaddr, guardsize, PROT_NONE) == 0)) { + stackaddr += guardsize; + } else { + if (stackaddr != MAP_FAILED) + munmap(stackaddr, stacksize + guardsize); + stackaddr = NULL; + } + attr->stackaddr_attr = stackaddr; } if (attr->stackaddr_attr != NULL) return (0); Index: libexec/rtld-elf/map_object.c =================================================================== RCS file: /usr/ncvs/src/libexec/rtld-elf/map_object.c,v retrieving revision 1.15 diff -u -r1.15 map_object.c --- libexec/rtld-elf/map_object.c 3 Aug 2004 08:50:58 -0000 1.15 +++ libexec/rtld-elf/map_object.c 11 Sep 2004 17:41:28 -0000 @@ -46,12 +46,15 @@ * Map a shared object into memory. The "fd" argument is a file descriptor, * which must be open on the object and positioned at its beginning. * The "path" argument is a pathname that is used only for error messages. + * The "low_addr" argument allows for addresses below the normal data + * area start to be used for mapping if no space is available above. * * The return value is a pointer to a newly-allocated Obj_Entry structure * for the shared object. Returns NULL on failure. */ Obj_Entry * -map_object(int fd, const char *path, const struct stat *sb) +map_object(int fd, const char *path, const struct stat *sb, + unsigned long low_addr) { Obj_Entry *obj; Elf_Ehdr *hdr; @@ -152,6 +155,15 @@ mapbase = mmap(base_addr, mapsize, convert_prot(segs[0]->p_flags), convert_flags(segs[0]->p_flags), fd, base_offset); + /* + * If requested and out of space for the library, try again below + * the normal minimum data segment address. + */ + if (mapbase == (caddr_t) -1 && base_addr == NULL && low_addr != 0) { + base_addr = (caddr_t) low_addr; + mapbase = mmap(base_addr, mapsize, convert_prot(segs[0]->p_flags), + convert_flags(segs[0]->p_flags), fd, base_offset); + } if (mapbase == (caddr_t) -1) { _rtld_error("%s: mmap of entire address space failed: %s", path, strerror(errno)); Index: libexec/rtld-elf/rtld.c =================================================================== RCS file: /usr/ncvs/src/libexec/rtld-elf/rtld.c,v retrieving revision 1.99 diff -u -r1.99 rtld.c --- libexec/rtld-elf/rtld.c 4 Aug 2004 19:12:14 -0000 1.99 +++ libexec/rtld-elf/rtld.c 11 Sep 2004 17:51:00 -0000 @@ -143,6 +143,9 @@ static char *ld_library_path; /* Environment variable for search path */ static char *ld_preload; /* Environment variable for libraries to load first */ +static unsigned long ld_library_low_addr; /* Environment variable for + alternate data area to + try to map into */ static char *ld_tracing; /* Called from ldd to print libs */ static Obj_Entry *obj_list; /* Head of linked list of shared objects */ static Obj_Entry **obj_tail; /* Link field of last object in list */ @@ -287,6 +290,14 @@ ld_bind_now = getenv(LD_ "BIND_NOW"); if (trust) { + const char *env_low_addr = getenv(LD_ "LIBRARY_LOW_ADDR"); + if (env_low_addr != NULL) { + char *low_addr_endptr = NULL; + errno = 0; + ld_library_low_addr = strtoul(env_low_addr, &low_addr_endptr, 0); + if (*low_addr_endptr != '\0' || errno != 0) + ld_library_low_addr = 0; + } ld_debug = getenv(LD_ "DEBUG"); libmap_disable = getenv(LD_ "LIBMAP_DISABLE") != NULL; ld_library_path = getenv(LD_ "LIBRARY_PATH"); @@ -308,7 +319,7 @@ if (aux_info[AT_EXECFD] != NULL) { /* Load the main program. */ int fd = aux_info[AT_EXECFD]->a_un.a_val; dbg("loading main program"); - obj_main = map_object(fd, argv0, NULL); + obj_main = map_object(fd, argv0, NULL, 0); close(fd); if (obj_main == NULL) die(); @@ -1249,7 +1260,7 @@ if (obj == NULL) { /* First use of this object, so we must map it in */ dbg("loading \"%s\"", path); - obj = map_object(fd, path, &sb); + obj = map_object(fd, path, &sb, ld_library_low_addr); close(fd); if (obj == NULL) { free(path); Index: libexec/rtld-elf/rtld.h =================================================================== RCS file: /usr/ncvs/src/libexec/rtld-elf/rtld.h,v retrieving revision 1.34 diff -u -r1.34 rtld.h --- libexec/rtld-elf/rtld.h 3 Aug 2004 08:50:58 -0000 1.34 +++ libexec/rtld-elf/rtld.h 11 Sep 2004 17:41:45 -0000 @@ -209,7 +209,8 @@ } SymCache; extern void _rtld_error(const char *, ...) __printflike(1, 2); -extern Obj_Entry *map_object(int, const char *, const struct stat *); +extern Obj_Entry *map_object(int, const char *, const struct stat *, + unsigned long); extern void *xcalloc(size_t); extern void *xmalloc(size_t); extern char *xstrdup(const char *); -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 18: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 5D56016A4CE; Sat, 11 Sep 2004 18:22:14 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC5FF43D49; Sat, 11 Sep 2004 18:22:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i8BIMCsA034957; Sat, 11 Sep 2004 14:22:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8BIMCSV008870; Sat, 11 Sep 2004 14:22:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C873F7303F; Sat, 11 Sep 2004 14:22:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040911182212.C873F7303F@freebsd-current.sentex.ca> Date: Sat, 11 Sep 2004 14:22:12 -0400 (EDT) Subject: [releng_5 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: Sat, 11 Sep 2004 18:22:14 -0000 TB --- 2004-09-11 17:21:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-11 17:21:18 - starting RELENG_5 tinderbox run for alpha/alpha TB --- 2004-09-11 17:21:18 - checking out the source tree TB --- 2004-09-11 17:21:18 - cd /home/tinderbox/RELENG_5/alpha/alpha TB --- 2004-09-11 17:21:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-11 17:28:54 - building world (CFLAGS=-O -pipe) TB --- 2004-09-11 17:28:54 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-11 17:28:54 - /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-09-11 18:17:30 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-11 18:17:30 - cd /home/tinderbox/RELENG_5/alpha/alpha/src TB --- 2004-09-11 18:17:30 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 11 18:17:31 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 [...] : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x15a8): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x1668): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text+0x16ec): In function `cam_periph_unmapmem': : relocation truncated to fit: BRADDR .text3 cam_periph.o(.text3+0x0): additional relocation overflows omitted from the output *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/obj/alpha/tinderbox/RELENG_5/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/RELENG_5/alpha/alpha/src. TB --- 2004-09-11 18:22:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-11 18:22:12 - ERROR: failed to build generic kernel TB --- 2004-09-11 18:22:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 18:57: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 C7A7016A4CE for ; Sat, 11 Sep 2004 18:57:28 +0000 (GMT) Received: from smtp1.netcologne.de (smtp1.netcologne.de [194.8.194.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D18343D3F for ; Sat, 11 Sep 2004 18:57:28 +0000 (GMT) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-243-85.netcologne.de [213.196.243.85]) by smtp1.netcologne.de (Postfix) with SMTP id D03BA38CD3 for ; Sat, 11 Sep 2004 20:57:24 +0200 (MEST) Received: (qmail 36785 invoked by uid 1001); 11 Sep 2004 18:57:51 -0000 Date: Sat, 11 Sep 2004 20:57:29 +0200 From: Thomas-Martin Seck To: freebsd-current@freebsd.org Message-ID: <20040911185729.GA382@laurel.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Subject: RELENG_5: occasional panic on shutdown 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, 11 Sep 2004 18:57:28 -0000 Once in a while I drop into ddb when I try to shutdown my RELENG_5 machine from a serial console; please see below. Is there anything interesting I could do in ddb to diagnose the problem? $ sudo shutdown -h now Shutdown NOW! shutdown: [pid 522] $ *** FINAL System shutdown message from thomas@current.tmseck.homedns.org *** System going down IMMEDIATELY Sep 11 20:50:15 current shutdown: halt by thomas: System shutdown time has arrived Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc04c16cf stack pointer = 0x10:0xcc551784 frame pointer = 0x10:0xcc551790 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 = 251 (syslogd) [thread 100038] Stopped at knote+0x27: cmpxchgl %ecx,0x1c(%edx) db> From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 19:35: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 DFC9716A4CE for ; Sat, 11 Sep 2004 19:35:26 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 872CC43D3F for ; Sat, 11 Sep 2004 19:35:26 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 4786 invoked from network); 11 Sep 2004 19:35:26 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 Sep 2004 19:35:26 -0000 Received: from hydrogen.funkthat.com (mtuhkt@localhost.funkthat.com [127.0.0.1])i8BJZOuU038831; Sat, 11 Sep 2004 12:35:25 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8BJZNdA038830; Sat, 11 Sep 2004 12:35:23 -0700 (PDT) Date: Sat, 11 Sep 2004 12:35:23 -0700 From: John-Mark Gurney To: Thomas-Martin Seck Message-ID: <20040911193523.GB72089@funkthat.com> Mail-Followup-To: Thomas-Martin Seck , freebsd-current@freebsd.org References: <20040911185729.GA382@laurel.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911185729.GA382@laurel.tmseck.homedns.org> 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: freebsd-current@freebsd.org Subject: Re: RELENG_5: occasional panic on shutdown 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: Sat, 11 Sep 2004 19:35:27 -0000 Thomas-Martin Seck wrote this message on Sat, Sep 11, 2004 at 20:57 +0200: > Once in a while I drop into ddb when I try to shutdown my RELENG_5 > machine from a serial console; please see below. > > Is there anything interesting I could do in ddb to diagnose the problem? > > $ sudo shutdown -h now > Shutdown NOW! > shutdown: [pid 522] > $ > > *** FINAL System shutdown message from thomas@current.tmseck.homedns.org *** > System going down IMMEDIATELY > > > Sep 11 20:50:15 current shutdown: halt by thomas: > > System shutdown time has arrived > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x1c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc04c16cf > stack pointer = 0x10:0xcc551784 > frame pointer = 0x10:0xcc551790 > 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 = 251 (syslogd) > [thread 100038] > Stopped at knote+0x27: cmpxchgl %ecx,0x1c(%edx) > db> You forgot the back trace on this, do a: tr from the db prompt... It is also very useful to find out the line number for the address that it stopped at.. (knote+0x27)... you can use gdb for this: gdb kernel.debug l *knote+0x27 I do have a fix that may fix this, but I can't know if it will until I get the information above. -- 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 Sat Sep 11 19:59: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 CE17A16A4CE for ; Sat, 11 Sep 2004 19:59:53 +0000 (GMT) Received: from smtp1.netcologne.de (smtp1.netcologne.de [194.8.194.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0487B43D39 for ; Sat, 11 Sep 2004 19:59:53 +0000 (GMT) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-248-179.netcologne.de [213.196.248.179]) by smtp1.netcologne.de (Postfix) with SMTP id 6CF7B38BDB for ; Sat, 11 Sep 2004 21:59:49 +0200 (MEST) Received: (qmail 37151 invoked by uid 1001); 11 Sep 2004 20:00:17 -0000 Date: Sat, 11 Sep 2004 21:59:55 +0200 From: Thomas-Martin Seck To: freebsd-current@freebsd.org Message-ID: <20040911195955.GB382@laurel.tmseck.homedns.org> Mail-Followup-To: freebsd-current@freebsd.org, John-Mark Gurney References: <20040911185729.GA382@laurel.tmseck.homedns.org> <20040911193523.GB72089@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911193523.GB72089@funkthat.com> 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 cc: John-Mark Gurney Subject: Re: RELENG_5: occasional panic on shutdown 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, 11 Sep 2004 19:59:54 -0000 * John-Mark Gurney (gurney_j@resnet.uoregon.edu): > Thomas-Martin Seck wrote this message on Sat, Sep 11, 2004 at 20:57 +0200: > > Once in a while I drop into ddb when I try to shutdown my RELENG_5 > > machine from a serial console; please see below. > You forgot the back trace on this, do a: tr from the db prompt... Ok, there you are: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor write, page not present instruction pointer = 0x8:0xc04c16cf stack pointer = 0x10:0xcc5be784 frame pointer = 0x10:0xcc5be790 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 = 249 (syslogd) [thread 100064] Stopped at knote+0x27: cmpxchgl %ecx,0x1c(%edx) db> tr knote(c1299698,0,0,c1195640,cc5be7c0) at knote+0x27 ttwwakeup(c1299600) at ttwwakeup+0xc8 comstart(c1299600) at comstart+0x386 comparam(c1299600,c12996a4,c1299600,3,0) at comparam+0x254 sioopen(c06c2bc0,6,2000,c1195640,c06b27e0) at sioopen+0x1df spec_open(cc5be880,cc5be93c,c05392c5,cc5be880,80) at spec_open+0x2b6 spec_vnoperate(cc5be880) at spec_vnoperate+0x13 vn_open_cred(cc5be980,c06c98f8,0,c10dde00,ffffffff) at vn_open_cred+0x419 vn_open(cc5be980,c06c98f8,0,ffffffff) at vn_open+0x1e cn_devopen(c06c98c0,c1195640,0) at cn_devopen+0xac cnopen(c06c157c,6,2000,c1195640,c06a0780) at cnopen+0x41 spec_open(cc5bea84,cc5beb40,c05392c5,cc5bea84,80) at spec_open+0x2b6 spec_vnoperate(cc5bea84) at spec_vnoperate+0x13 vn_open_cred(cc5bebe4,cc5bece4,0,c10dde00,5) at vn_open_cred+0x419 vn_open(cc5bebe4,cc5bece4,0,5,0) at vn_open+0x1e kern_open(c1195640,804f220,0,6,0) at kern_open+0xe3 open(c1195640,cc5bed14,3,4,292) at open+0x18 syscall(2f,2f,2f,7,bfbfdff0) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280d3583, esp = 0xbfbfd9dc, ebp = 0xbfbfda58 --- db> > It is also very useful to find out the line number for the address > that it stopped at.. (knote+0x27)... you can use gdb for this: > gdb kernel.debug > l *knote+0x27 $ gdb /usr/obj/usr/src/sys/CURRENT/kernel.debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) l *knote+0x27 0xc04c16cf is in knote (atomic.h:154). 149 atomic.h: No such file or directory. in atomic.h (gdb) > I do have a fix that may fix this, but I can't know if it will until > I get the information above. I hope this helps. Thanks for looking into it! From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 20:02: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 5FFBE16A4CE for ; Sat, 11 Sep 2004 20:02:09 +0000 (GMT) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5FC343D31 for ; Sat, 11 Sep 2004 20:02:08 +0000 (GMT) (envelope-from raoul.megelas@libertysurf.fr) Received: from libertysurf.fr (83.154.21.48) by mail.libertysurf.net (6.5.036) id 41427FC00018048A for freebsd-current@freebsd.org; Sat, 11 Sep 2004 22:02:08 +0200 Received: from raoul.megelas by port.private.music with local (Exim 4.20) id 1C6DYC-0000Cg-Vg for freebsd-current@freebsd.org; Sat, 11 Sep 2004 21:28:44 +0200 Date: Sat, 11 Sep 2004 21:28:44 +0200 From: "raoul.megelas" To: freebsd-current@freebsd.org Message-ID: <20040911192844.GA771@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ltmdm 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, 11 Sep 2004 20:02:09 -0000 hi all, the Lucent Technology winmodem, (ltmdm from the ports/comms), included in the Dell Inspiron 8000 panic when a ring incoming signal occurs. The 6.0-current kernel is dated from this afternoon, but I have seen that 20 days ago. here is the ddb screen: SSkernel trap 12 with interrupts disabled page fault while in kernel mode fault virtual address 0x138 fault cod"e supervisor read = page not present instruction pointer 0x8:0xc1b8d00d stack pointer 0x10:0xcbedfc84 frame pointer = 0x10:0xcbedfc94 code segment base 0x0 limit 0xfffff, type 0x1b = dpl 0 pres 1 def32 1, gran 1 processor eflags = resume IOPL=0 current process = 18 (swi5 ttyltmdm++) thread 100000] stopped at siointr 1+0xbd instruction: cmpl $0,0x138(%edx) Any idea would be welcome. Thanks raoul raoul.megelas@libertysurf.fr From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 20:25: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 B700316A4CE for ; Sat, 11 Sep 2004 20:25:40 +0000 (GMT) Received: from lmfilto03.st1.spray.net (lmfilto03.st1.spray.net [212.78.202.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id D868D43D58 for ; Sat, 11 Sep 2004 20:25:39 +0000 (GMT) (envelope-from bsd-daemon@spray.se) Received: from localhost (localhost [127.0.0.1]) by lmfilto03.st1.spray.net (Postfix) with ESMTP id 81C94129068 for ; Sat, 11 Sep 2004 20:25:38 +0000 (GMT) Received: from lmcodec02.st1.spray.net ([212.78.202.56])port 10024) with ESMTP id 32541-08 for ; Sat, 11 Sep 2004 20:25:38 +0000 (GMT) Received: from lmcodec02.st1.spray.net (localhost [127.0.0.1]) by lmcodec02.st1.spray.net (Postfix) with SMTP id 17939AB207 for ; Sat, 11 Sep 2004 20:25:38 +0000 (GMT) From: bsd-daemon@spray.se To: freebsd-current@freebsd.org Message-ID: <1094934338016321@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [213.199.67.100] Mime-Version: 1.0 Date: Sat, 11 Sep 2004 20:25:38 GMT Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0163211094934338_ID" X-Virus-Scanned: by amavisd-new at spray.net Subject: [5.3-BETA3] kernel panic on boot 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, 11 Sep 2004 20:25:40 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0163211094934338_ID Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello! Which line do I have to put in the kernel config to be able to dump this early in the booting process? The "Kernel Debugging" chapter in the "Developers handbook" is a bit unclear on this subject (it says the dump device can be hard-coded via the dump clause in the config(5) line of a kernel configuration file), and nothing can be found in NOTES either. Boot output follows: BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 640kB/97280kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root@harlow.cse.buffalo.edu, Sat Sep 4 01:20:02 UTC 2004) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x415884 data=0x7d564+0x75f9c syms=[0x4+0x5b980+0x6f87e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=00000000000a0000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=0000000005f00000 SMAP type=02 base=00000000fffe0000 len=0000000000020000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=c3fe72bf base=c3b736bbc3af2ebb len=c3ffdebbc3ffe0bb 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-BETA3 #0: Sat Sep 4 12:07:48 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc09d6000. Calibrating clock(s) ... i8254 clock: 1193779 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 133263149 Hz CPU: Pentium/P54C (133.26-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x3bf real memory = 100663296 (96 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x0000000005e1ffff, 85946368 bytes (20983 pages) avail memory = 88948736 (84 MB) APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) MPTable: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fe100 bios32: Entry = 0xfa8f6 (c00fa8f6) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xa1a0 pnpbios: Found PnP BIOS data at 0xc00f1790 pnpbios: Entry = f0000:185e Rev = 1.0 pnpbios: OEM ID 1127406 Other BIOS signatures found: Intel Pentium detected, installing workaround for F00F bug ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) lapic: Routing ExtINT -> LINT0 lapic: Routing NMI -> LINT1 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0 irqs 0-15 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00030010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> null: random: io: mem: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x80002000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=04a38086) pcibios: BIOS version 2.10 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x22 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0781162 stack pointer = 0x10:0xc0c21c24 frame pointer = 0x10:0xc0c21c30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread 0] Stopped at mptable_walk_table+0x16: cmpw $0,0x22(%eax) db> tr mptable_walk_table(c0781a00,c0c21c42) at mptable_walk_table+0x16 mptable_pci_probe_table(0) at mptable_pci_probe_table+0x69 mptable_hostb_probe(c120fc00) at mptable_hostb_probe+0x6b device_probe_child(c120fd00,c120fc00,c0891a20,c120fc00,c120fd00) at device_probe_child+0xc4 device_probe_and_attach(c120fc00) at device_probe_and_attach+0x51 bus_generic_attach(c120fd00,c120fd00,c081b630,c120fd00,c120fd00) at bus_generic_attach+0x16 legacy_attach(c120fd00) at legacy_attach+0x19 device_attach(c120fd00,0,c120fd00,c120fd80,0) at device_attach+0x58 device_probe_and_attach(c120fd00) at device_probe_and_attach+0xb4 bus_generic_attach(c120fd80,c120fd80,c120fd80,c0c21d44,c0612fe8) at bus_generic_attach+0x16 nexus_attach(c120fd80) at nexus_attach+0x13 device_attach(c120fd80,c0886130,c120fd80,c0886130,c29000) at device_attach+0x58 device_probe_and_attach(c120fd80) at device_probe_and_attach+0xb4 root_bus_configure(c1248380,c080f18a,0) at root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c043f475) at configure+0x1b mi_startup() at mi_startup+0x96 begin() at begin+0x2c (gdb) l *mptable_walk_table+0x16 0xc0781162 is in mptable_walk_table (/usr/src/sys/i386/i386/mptable.c:389). 384 { 385 u_int i; 386 u_char *entry; 387 388 entry = (u_char *)(mpct + 1); 389 for (i = 0; i < mpct->entry_count; i++) { 390 switch (*entry) { 391 case MPCT_ENTRY_PROCESSOR: 392 case MPCT_ENTRY_IOAPIC: 393 case MPCT_ENTRY_BUS: (gdb) If I can give you more useful information, please ask. Thanks Gustav Bylesjo --=_NextPart_Lycos_0163211094934338_ID-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 20:36: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 58D1516A4CE for ; Sat, 11 Sep 2004 20:36:07 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31FE43D45 for ; Sat, 11 Sep 2004 20:36:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-120-131-100.dsl.snfc21.pacbell.net [68.120.131.100])i8BKa3H9088874; Sat, 11 Sep 2004 16:36:04 -0400 Message-ID: <414361B3.3000305@elischer.org> Date: Sat, 11 Sep 2004 13:36:03 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: bsd-daemon@spray.se References: <1094934338016321@lycos-europe.com> In-Reply-To: <1094934338016321@lycos-europe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: [5.3-BETA3] kernel panic on boot 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, 11 Sep 2004 20:36:07 -0000 bsd-daemon@spray.se wrote: > Hello! > > Which line do I have to put in the kernel config to be able to dump this early in the booting process? > The "Kernel Debugging" chapter in the "Developers handbook" is a bit unclear on this subject (it says the dump device can be hard-coded via the dump clause in the config(5) line of a kernel configuration file), and nothing can be found in NOTES either. > you can not dump at this stage. All you can do is use serial remote debugging and run gdb on the live machine via a serial port. (or in vmware or similar). (or run ddb as you have already discovered). The reason is that there is no disk drive configured yet so there is nothing to dump to.. > Boot output follows: > > > BIOS drive A: is disk0 > BIOS drive C: is disk1 > BIOS 640kB/97280kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (root@harlow.cse.buffalo.edu, Sat Sep 4 01:20:02 UTC 2004) > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x415884 data=0x7d564+0x75f9c syms=[0x4+0x5b980+0x6f87e] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel]... > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=00000000000a0000 > SMAP type=02 base=00000000000f0000 len=0000000000010000 > SMAP type=01 base=0000000000100000 len=0000000005f00000 > SMAP type=02 base=00000000fffe0000 len=0000000000020000 > SMAP type=02 base=00000000fec00000 len=0000000000001000 > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=c3fe72bf base=c3b736bbc3af2ebb len=c3ffdebbc3ffe0bb > 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-BETA3 #0: Sat Sep 4 12:07:48 UTC 2004 > root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel/kernel" at 0xc09d6000. > Calibrating clock(s) ... i8254 clock: 1193779 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 133263149 Hz > CPU: Pentium/P54C (133.26-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x52b Stepping = 11 > Features=0x3bf > real memory = 100663296 (96 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000c29000 - 0x0000000005e1ffff, 85946368 bytes (20983 pages) > avail memory = 88948736 (84 MB) > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > SMP: Added CPU 1 (AP) > MPTable: > APIC ID: physical 0, logical 0:0 > APIC ID: physical 1, logical 0:1 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00fe100 > bios32: Entry = 0xfa8f6 (c00fa8f6) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0xa1a0 > pnpbios: Found PnP BIOS data at 0xc00f1790 > pnpbios: Entry = f0000:185e Rev = 1.0 > pnpbios: OEM ID 1127406 > Other BIOS signatures found: > Intel Pentium detected, installing workaround for F00F bug > ioapic0: Changing APIC ID to 2 > ioapic0: Routing external 8259A's -> intpin 0 > ioapic0: intpin 0 -> ExtINT (edge, high) > ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) > ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) > ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) > ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) > ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) > ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) > ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) > ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) > ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) > ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) > ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) > ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) > ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) > ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) > ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) > lapic: Routing ExtINT -> LINT0 > lapic: Routing NMI -> LINT1 > ioapic0: Routing IRQ 0 -> intpin 2 > ioapic0 irqs 0-15 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00030010 LDR: 0x01000000 DFR: 0x0fffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > wlan: <802.11 Link Layer> > null: > random: > io: > mem: > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > pci_open(1): mode 1 addr port (0x0cf8) is 0x80002000 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=04a38086) > pcibios: BIOS version 2.10 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x22 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0781162 > stack pointer = 0x10:0xc0c21c24 > frame pointer = 0x10:0xc0c21c30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread 0] > Stopped at mptable_walk_table+0x16: cmpw $0,0x22(%eax) > db> tr > mptable_walk_table(c0781a00,c0c21c42) at mptable_walk_table+0x16 > mptable_pci_probe_table(0) at mptable_pci_probe_table+0x69 > mptable_hostb_probe(c120fc00) at mptable_hostb_probe+0x6b > device_probe_child(c120fd00,c120fc00,c0891a20,c120fc00,c120fd00) at device_probe_child+0xc4 > device_probe_and_attach(c120fc00) at device_probe_and_attach+0x51 > bus_generic_attach(c120fd00,c120fd00,c081b630,c120fd00,c120fd00) at bus_generic_attach+0x16 > legacy_attach(c120fd00) at legacy_attach+0x19 > device_attach(c120fd00,0,c120fd00,c120fd80,0) at device_attach+0x58 > device_probe_and_attach(c120fd00) at device_probe_and_attach+0xb4 > bus_generic_attach(c120fd80,c120fd80,c120fd80,c0c21d44,c0612fe8) at bus_generic_attach+0x16 > nexus_attach(c120fd80) at nexus_attach+0x13 > device_attach(c120fd80,c0886130,c120fd80,c0886130,c29000) at device_attach+0x58 > device_probe_and_attach(c120fd80) at device_probe_and_attach+0xb4 > root_bus_configure(c1248380,c080f18a,0) at root_bus_configure+0x16 > configure(0,c1ec00,c1e000,0,c043f475) at configure+0x1b > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > > (gdb) l *mptable_walk_table+0x16 > 0xc0781162 is in mptable_walk_table (/usr/src/sys/i386/i386/mptable.c:389). > 384 { > 385 u_int i; > 386 u_char *entry; > 387 > 388 entry = (u_char *)(mpct + 1); > 389 for (i = 0; i < mpct->entry_count; i++) { > 390 switch (*entry) { > 391 case MPCT_ENTRY_PROCESSOR: > 392 case MPCT_ENTRY_IOAPIC: > 393 case MPCT_ENTRY_BUS: > (gdb) > > If I can give you more useful information, please ask. > > Thanks > Gustav Bylesjo > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sep 11 21:05: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 828FF16A4CE; Sat, 11 Sep 2004 21:05:21 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id C11DC43D46; Sat, 11 Sep 2004 21:05:20 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i8BKpPjr001807 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 11 Sep 2004 16:51:27 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Brian Fundakowski Feldman Date: Sat, 11 Sep 2004 17:07:13 -0400 User-Agent: KMail/1.6.2 References: <47158390.20040827112834@ulstu.ru> <200409060149.35764.mistry.7@osu.edu> <20040911180000.GX928@green.homeunix.org> In-Reply-To: <20040911180000.GX928@green.homeunix.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Nk2QB5x+ra+2riV"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409111707.25937.mistry.7@osu.edu> X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL, X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap 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, 11 Sep 2004 21:05:21 -0000 --Boundary-02=_Nk2QB5x+ra+2riV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 September 2004 02:00 pm, you wrote: > On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote: > > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > > > [ John, sorry for the duplicate message; this is the correct one. ] > > > > > > On Fri, 27 Aug 2004, John Birrell wrote: > > > > Anish Mistry has developed a patch to choose an > > > > appropriate mmap address. He posted it to -current. I haven't had > > > > time to test it. > > > > > > Thanks for the note. Will you have time to test/commit this before > > > 5.3? > > > > > > Anish, do you have any news on this patch? (Wine has been broken for= a > > > couple of months now, and it would be great to have at least 5.3 > > > fixed.) > > > > Well I guess this is my lucky day. Apply the attached patch for vm_mmap > > to your kernel and patch the August wine sources with the wine-mmap.pat= ch > > and compile and install wine (be sure to use gmake). This is working on > > my dev system with 6-CURRENT as of Saturday night. > > The wine mmap patch just doesn't reserve the DOS area so DOS programs m= ay > > not work. This seems to just work around a side effect of the kernel > > mmap patch. I still think that the kernel mmap patch has issues so I'm > > hoping Alan can give us some feedback. > > Anyway this worked for me, YMMV. > > Do these combined work for you, minus any modifications to mmap(2)? I do > not feel that the kernel mmap(2) should be modified in this manner, that = it > is a strictly userland problem. > With only these applied I get old message that wine can't mmap it's address= =20 space. =2D-=20 Anish Mistry --Boundary-02=_Nk2QB5x+ra+2riV Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBQ2kNxqA5ziudZT0RAggmAKDAS9dsCyL6KJtdBE4VNmrvyFc9dgCeLRDK Hj/miQh45y/mdUesJwhYYhg= =49Km -----END PGP SIGNATURE----- --Boundary-02=_Nk2QB5x+ra+2riV-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:14: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 7D04F16A4CE for ; Sat, 11 Sep 2004 21:14:52 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43D7F43D46 for ; Sat, 11 Sep 2004 21:14:52 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id A0849304C for ; Sat, 11 Sep 2004 16:14:31 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18502-01 for ; Sat, 11 Sep 2004 16:14:26 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 4DC62304A for ; Sat, 11 Sep 2004 16:14:26 -0500 (CDT) Message-ID: <41436ABE.7060202@veldy.net> Date: Sat, 11 Sep 2004 16:14:38 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F3B6DDBF1409111AA424021" X-Virus-Scanned: by amavisd-new at veldy.net Subject: How do I install a kernel from CD over the top of BETA4? 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, 11 Sep 2004 21:14:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F3B6DDBF1409111AA424021 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I built two kernels and did not manage to save the old working kernel (I thought that I had) and now I have NO bootable kernels to boot my 5.3BETA4 system ... how can I get the kernel off of my 5.2.1 CD so that I can build a new working kernel (after a fresh cvsup)? Thanks, Tom Veldhouse --------------enig7F3B6DDBF1409111AA424021 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBQ2rDARgTFXYf0wARAq+NAJ9d/At7NmnsohoYpKr0Pxpzh5EDfgCdHjxq /KcV6Q/hrom4uUyJniFMQzg= =6jnl -----END PGP SIGNATURE----- --------------enig7F3B6DDBF1409111AA424021-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:18: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 A733F16A4CF for ; Sat, 11 Sep 2004 21:18:44 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C4543D1D for ; Sat, 11 Sep 2004 21:18:44 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8BLIT6f049447; Sat, 11 Sep 2004 14:18:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409112118.i8BLIT6f049447@gw.catspoiler.org> Date: Sat, 11 Sep 2004 14:18:29 -0700 (PDT) From: Don Lewis To: mat@cnd.mcgill.ca In-Reply-To: <20040826204822.GB670@cnd.mcgill.ca> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: tech2187@yahoo.com Subject: Re: lor with sndstat (amd64) 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, 11 Sep 2004 21:18:44 -0000 On 26 Aug, Mathew Kanner wrote: > On Aug 26, K Chapman wrote: >> running: amd64 >> 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Wed Aug 25 >> 23:40:19 EDT >> >> sound from kernel config: >> device sound >> device "snd_via8233" >> >> noticed this on console ater cat /dev/sndstat : >> lock order reversal >> 1st 0xffffffff805d03e0 sndstat (sndstat) @ >> /usr/src/sys/dev/sound/pcm/sndstat.c:165 >> 2nd 0xffffff002b61e8f0 user map (user map) @ >> /usr/src/sys/vm/vm_map.c:2997 >> KDB: stack backtrace: >> witness_checkorder() at witness_checkorder+0x654 >> _sx_xlock() at _sx_xlock+0x51 >> vm_map_lookup() at vm_map_lookup+0x44 >> vm_fault() at vm_fault+0xba >> trap_pfault() at trap_pfault+0x111 >> trap() at trap+0x1b5 >> alltraps_with_regs_pushed() at >> alltraps_with_regs_pushed+0x5 >> sndstat_read() at sndstat_read+0x8b >> spec_read() at spec_read+0x1ea >> vn_read() at vn_read+0x153 >> dofileread() at dofileread+0x9a >> read() at read+0x68 >> syscall() at syscall+0x4b0 >> Xfast_syscall() at Xfast_syscall+0xa8 >> --- syscall (3, FreeBSD ELF64, read), rip = >> 0x200689708, rsp = 0x7fffffffeab8, rbp = >> 0x7fffffffedc4 --- >> >> saw reports of a lor with sndstat at the end of last >> year, but that seemed to have been resolved. sound >> seems fine however... plays cd's, mp3's ok. > > Hello "K", > I've never seen this one before, I'll take a look at this on > the weekend, but since I don't have a 8233 or and AMD64 I may not find > it. I committed a fix for this yesterday: sys/dev/sound/pcm/sndstat.c rev 1.18. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:24: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 0F56216A4CE; Sat, 11 Sep 2004 21:24:21 +0000 (GMT) Received: from lmfilto02.st1.spray.net (lmfilto02.st1.spray.net [212.78.202.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE88243D5E; Sat, 11 Sep 2004 21:24:20 +0000 (GMT) (envelope-from bsd-daemon@spray.se) Received: from localhost (localhost [127.0.0.1]) by lmfilto02.st1.spray.net (Postfix) with ESMTP id 1E625E135C; Sat, 11 Sep 2004 21:24:19 +0000 (GMT) Received: from lmcodec03.st1.spray.net ([212.78.202.147])port 10024) with ESMTP id 18999-09; Sat, 11 Sep 2004 21:24:18 +0000 (GMT) Received: from lmcodec03.st1.spray.net (localhost [127.0.0.1]) by lmcodec03.st1.spray.net (Postfix) with SMTP id C697BAB208; Sat, 11 Sep 2004 21:24:18 +0000 (GMT) From: bsd-daemon@spray.se To: freebsd-current@freebsd.org Message-ID: <1094937858009848@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [213.199.67.100] Mime-Version: 1.0 Date: Sat, 11 Sep 2004 21:24:18 GMT Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0098481094937858_ID" X-Virus-Scanned: by amavisd-new at spray.net cc: Jean-Marc Zucconi Subject: Re: Re: [5.3-BETA3] kernel panic on boot 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, 11 Sep 2004 21:24:21 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0098481094937858_ID Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit > Från: Jean-Marc Zucconi > Till: bsd-daemon@spray.se > Rubrik: Re: [5.3-BETA3] kernel panic on boot > Datum: 11/09/2004 > >>>>> bsd-daemon writes: > > > Hello! > > Which line do I have to put in the kernel config to be able to dump > this early in the booting process? > > The "Kernel Debugging" chapter in the "Developers > handbook" is a bit unclear on this subject (it says the dump device > can be hard-coded via the dump clause in the config(5) line of a kernel > configuration file), and nothing can be found in NOTES either. > > > Boot output follows: > > [...] > > Try to boot after disabling ACPI. > > Jean-Marc > > -- > Jean-Marc Zucconi -- PGP Key: finger jmz@FreeBSD.org [KeyID: 400B38E9] I assume you mean set hint.acpi.0.disabled="1" before booting, unfortunately I still get the same results Gustav Bylesjo --=_NextPart_Lycos_0098481094937858_ID-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:26: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 CAD7216A4CE for ; Sat, 11 Sep 2004 21:26:11 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFE143D53 for ; Sat, 11 Sep 2004 21:26:11 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i8BLQ5qT022359; Sat, 11 Sep 2004 17:26:10 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i8BLQ4nc022358; Sat, 11 Sep 2004 17:26:04 -0400 (EDT) (envelope-from green) Date: Sat, 11 Sep 2004 17:26:04 -0400 From: Brian Fundakowski Feldman To: Anish Mistry Message-ID: <20040911212604.GY928@green.homeunix.org> References: <47158390.20040827112834@ulstu.ru> <200409060149.35764.mistry.7@osu.edu> <20040911180000.GX928@green.homeunix.org> <200409111707.25937.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409111707.25937.mistry.7@osu.edu> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap 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, 11 Sep 2004 21:26:11 -0000 On Sat, Sep 11, 2004 at 05:07:13PM -0400, Anish Mistry wrote: > On Saturday 11 September 2004 02:00 pm, you wrote: > > On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote: > > > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > > > > [ John, sorry for the duplicate message; this is the correct one. ] > > > > > > > > On Fri, 27 Aug 2004, John Birrell wrote: > > > > > Anish Mistry has developed a patch to choose an > > > > > appropriate mmap address. He posted it to -current. I haven't had > > > > > time to test it. > > > > > > > > Thanks for the note. Will you have time to test/commit this before > > > > 5.3? > > > > > > > > Anish, do you have any news on this patch? (Wine has been broken for a > > > > couple of months now, and it would be great to have at least 5.3 > > > > fixed.) > > > > > > Well I guess this is my lucky day. Apply the attached patch for vm_mmap > > > to your kernel and patch the August wine sources with the wine-mmap.patch > > > and compile and install wine (be sure to use gmake). This is working on > > > my dev system with 6-CURRENT as of Saturday night. > > > The wine mmap patch just doesn't reserve the DOS area so DOS programs may > > > not work. This seems to just work around a side effect of the kernel > > > mmap patch. I still think that the kernel mmap patch has issues so I'm > > > hoping Alan can give us some feedback. > > > Anyway this worked for me, YMMV. > > > > Do these combined work for you, minus any modifications to mmap(2)? I do > > not feel that the kernel mmap(2) should be modified in this manner, that it > > is a strictly userland problem. > > > With only these applied I get old message that wine can't mmap it's address > space. Oh, I'm sorry for not explaining the last step. You need to set the environment variable "LD_LIBRARY_LOW_ADDR" to some address, like after the first megabyte, or something like that, but before the first "data" address. Try, say, 1024000. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:35: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 EACEF16A4CE for ; Sat, 11 Sep 2004 21:35:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20F7843D41 for ; Sat, 11 Sep 2004 21:35:10 +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 D435C1FF9A8; Sat, 11 Sep 2004 23:35:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id C3E4B1FF9A7; Sat, 11 Sep 2004 23:35:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 0B35E15389; Sat, 11 Sep 2004 21:31:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0893515329; Sat, 11 Sep 2004 21:31:13 +0000 (UTC) Date: Sat, 11 Sep 2004 21:31:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Marc UBM Bocklet In-Reply-To: <20040911162825.418068e7.ubm@u-boot-man.de> Message-ID: References: <20040911162825.418068e7.ubm@u-boot-man.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD current mailing list Subject: Re: two LORs with acx driver and 6-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, 11 Sep 2004 21:35:11 -0000 On Sat, 11 Sep 2004, Marc UBM Bocklet wrote: > > encountered the following two LORs in the process. This time I was > intelligent enough to consult the LOR page first, but I did not find > them listed there. ... > Teh LORs: > > http://www.u-boot-man.de/~mbocklet/lors.txt added as http://sources.zabbadoz.net/freebsd/lor.html#036 http://sources.zabbadoz.net/freebsd/lor.html#037 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:50: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 6A89916A4CE; Sat, 11 Sep 2004 21:50:26 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2913D43D31; Sat, 11 Sep 2004 21:50:26 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8BLo31Q049489; Sat, 11 Sep 2004 14:50:07 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409112150.i8BLo31Q049489@gw.catspoiler.org> Date: Sat, 11 Sep 2004 14:50:03 -0700 (PDT) From: Don Lewis To: ma@dt.e-technik.uni-dortmund.de In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: re@FreeBSD.org cc: bde@FreeBSD.org Subject: extfs at shutdown (was: Re: BETA3 showstoppers (read: critical bugs)) 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, 11 Sep 2004 21:50:26 -0000 On 6 Sep, Matthias Andree wrote: > - a mounted ext2 file system (read-only sufficient) still causes FreeBSD > to not flush its own ufs super blocks at shut down, causing an fsck > run at next reboot. > Workaround: umount all ext2 file systems before reboot/halt. Ext2 abuses BUF_KERNPROC() through its LCK_BUF() macro to store the contents of its private cache of group descriptors, inode and block bitmaps, etc. in system buffers for the entire time that the file system is mounted. These resources don't get synced with the rest of the file system data, even during the final system sync, and the data isn't written and the resources aren't released until the file system is unmounted. I think it is undesirable to defer writing a significant amount of metadata until after the final filesystem sync. I also think that fixed size metadata caches (EXT2_MAX_GROUP_LOADED) for each mounted ext2 file system is undesirable. I think this metadata should be handled the same was as ufs caches it. Unfortunately this would be a fairly intrusive change. BTW, it looks like a bug to me that ext2_unmount() writes the superblock before the other metadata. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 21:52: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 2904316A4CF for ; Sat, 11 Sep 2004 21:52:31 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8032943D48 for ; Sat, 11 Sep 2004 21:52:30 +0000 (GMT) (envelope-from gwk@rahn-koltermann.de) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C6FnJ-0003Ob-00 for freebsd-current@freebsd.org; Sat, 11 Sep 2004 23:52:29 +0200 Received: from [217.232.140.192] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1C6FnJ-0005Px-00 for freebsd-current@freebsd.org; Sat, 11 Sep 2004 23:52:29 +0200 From: "Georg-W. Koltermann" To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1094939545.2033.6.camel@localhost.muc.eu.mscsoftware.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 11 Sep 2004 23:52:25 +0200 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:90bcaad5e51ecc993b2919ba4b74e6dc Subject: [5.3-BETA3] VMWare2 problems, with 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: Sat, 11 Sep 2004 21:52:31 -0000 Hi, trying to get VMWare2 to run on 5.3-BETA3, I noticed two problems: a) It doesn't compile. You have to apply the patch from ports/68202 b) Then it fails when trying to load the kernel module due to an undefined external kmem_alloc_pageable(). I have replaced the calls with kmem_alloc_nofault() as suggested in a different posting about VMWare3. Could you please commit the patches from ports/68202 and the fix for b) above, which I'm enclosing. -- Thanks, Georg. -----------------------snip----------------------------- --- vmmon-only/freebsd/hostif.c~ Fri Sep 10 11:50:20 2004 +++ vmmon-only/freebsd/hostif.c Fri Sep 10 19:19:27 2004 @@ -1110,7 +1110,7 @@ paddr = vtophys(addr); #if __FreeBSD_version >= 500038 GIANT_REQUIRED; - ka->kaddr = kmem_alloc_pageable(kernel_map, PAGE_SIZE); + ka->kaddr = kmem_alloc_nofault(kernel_map, PAGE_SIZE); ka->map = PHYS_TO_VM_PAGE(paddr); vm_page_lock_queues(); vm_page_wire(ka->map); @@ -1118,19 +1118,19 @@ pmap_qenter(ka->kaddr, &ka->map, 1); #elif __FreeBSD_version >= 500021 GIANT_REQUIRED; - ka->kaddr = kmem_alloc_pageable(kernel_map, PAGE_SIZE); + ka->kaddr = kmem_alloc_nofault(kernel_map, PAGE_SIZE); ka->map = PHYS_TO_VM_PAGE(paddr); vm_page_wire(ka->map); pmap_kenter(ka->kaddr, paddr); #elif __FreeBSD_version >= 500013 mtx_lock(&vm_mtx); - ka->kaddr = kmem_alloc_pageable(kernel_map, PAGE_SIZE); + ka->kaddr = kmem_alloc_nofault(kernel_map, PAGE_SIZE); ka->map = PHYS_TO_VM_PAGE(paddr); vm_page_wire(ka->map); pmap_kenter(ka->kaddr, paddr); mtx_unlock(&vm_mtx); #else - ka->kaddr = kmem_alloc_pageable(kernel_map, PAGE_SIZE); + ka->kaddr = kmem_alloc_nofault(kernel_map, PAGE_SIZE); ka->map = PHYS_TO_VM_PAGE(paddr); vm_page_wire(ka->map); pmap_kenter(ka->kaddr, paddr); --- ../vmmon-only/freebsd/hostif.c~ Fri Sep 10 11:50:20 2004 +++ ../vmmon-only/freebsd/hostif.c Fri Sep 10 19:19:27 2004 @@ -1066,7 +1066,7 @@ return NULL; } paddr = vtophys(addr); - ka->kaddr = kmem_alloc_pageable(kernel_map, PAGE_SIZE); + ka->kaddr = kmem_alloc_nofault(kernel_map, PAGE_SIZE); ka->map = PHYS_TO_VM_PAGE(paddr); vm_page_wire(ka->map); pmap_kenter(ka->kaddr, paddr); From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 22:19:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id D63D416A4CF; Sat, 11 Sep 2004 22:19:43 +0000 (GMT) Date: Sat, 11 Sep 2004 22:19:43 +0000 From: Kris Kennaway To: "raoul.megelas" Message-ID: <20040911221943.GA6990@hub.freebsd.org> References: <20040911192844.GA771@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911192844.GA771@libertysurf.fr> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: ltmdm 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, 11 Sep 2004 22:19:44 -0000 On Sat, Sep 11, 2004 at 09:28:44PM +0200, raoul.megelas wrote: > hi all, > > the Lucent Technology winmodem, (ltmdm from the ports/comms), > included in the Dell Inspiron 8000 > panic when a ring incoming signal occurs. > > The 6.0-current kernel is dated from this afternoon, but > I have seen that 20 days ago. Did you remember to recompile the module when you updated your kernel? You must do this or you'll get panics. > here is the ddb screen: > > SSkernel trap 12 with interrupts disabled > page fault while in kernel mode > fault virtual address 0x138 > fault cod"e supervisor read = page not present > instruction pointer 0x8:0xc1b8d00d > stack pointer 0x10:0xcbedfc84 > frame pointer = 0x10:0xcbedfc94 > code segment base 0x0 limit 0xfffff, type 0x1b > = dpl 0 pres 1 def32 1, gran 1 > > processor eflags = resume IOPL=0 > current process = 18 (swi5 ttyltmdm++) > thread 100000] > stopped at siointr 1+0xbd instruction: cmpl $0,0x138(%edx) > > Any idea would be welcome. See the instructions on obtaining a debugging traceback, in the developer's handbook. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 22:35: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 6C30B16A4CE for ; Sat, 11 Sep 2004 22:35:25 +0000 (GMT) Received: from mail.halls.colostate.edu (halls-mailgw.acns.colostate.edu [129.82.100.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A797243D48 for ; Sat, 11 Sep 2004 22:35:24 +0000 (GMT) (envelope-from end@endif.cjb.net) Received: from sed (inge068081.halls.colostate.edu [129.82.68.81]) i8BMZ2vA015722; Sat, 11 Sep 2004 16:35:02 -0600 Date: Sat, 11 Sep 2004 16:32:01 -0600 From: Robin Schoonover To: Danny Braniss Message-Id: <20040911163201.3e58e29a@sed> In-Reply-To: <20040904073507.3280943D49@mx1.FreeBSD.org> References: <200409031714.06053.dantavious@comcast.net> <20040904073507.3280943D49@mx1.FreeBSD.org> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: Sound in FreeBSD 5.3 Beta2 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, 11 Sep 2004 22:35:25 -0000 On Sat, 04 Sep 2004 10:35:06 +0300 Danny Braniss wrote: > look at the dmesg, and search for pcm0, and see if all is ok. > in my case: > pcm0: port 0xdc00-0xdc7f,0xd800-0xd8ff mem > 0xdd081000-0xdd081fff irq 20 at device 6.0 on pci0 > pcm0: [GIANT-LOCKED] > pcm0: cannot reset channel 0 > pcm0: unable to initialize the card > device_attach: pcm0 attach returned 6 > > by chance, i disabled agp and sound is now working! Does anyone know what causes this? I'm in the same boat (same chipset, same problem), and I'd like to have both sound and agp enabled. -- Robin Schoonover (aka End) # # Despite the high cost of living, it remains popular. # From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 22:49: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 F3F7916A4CE for ; Sat, 11 Sep 2004 22:49:52 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7164843D31 for ; Sat, 11 Sep 2004 22:49:50 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i8BMnmYB047911 for ; Sat, 11 Sep 2004 18:49:48 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i8BMnm4C047908 for ; Sat, 11 Sep 2004 18:49:48 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sat, 11 Sep 2004 18:49:47 -0400 (EDT) From: Andre Guibert de Bruet To: current@freebsd.org Message-ID: <20040911183823.W84468@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: TreeList failed: Network write failure: ChannelMux.ProtocolError 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, 11 Sep 2004 22:49:53 -0000 Hello, Anyone have any ideas on this one? # cvsupdate Parsing supfile "cvs-supfile" Connecting to cvsup2.FreeBSD.org Connected to cvsup2.FreeBSD.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs TreeList failed: Network write failure: ChannelMux.ProtocolError Will retry at 18:43:42 ^C The machine in question is a dual Athlon with a custom SMP kernel config which can be found at http://bling.properkernel.com/BLING . Reverting to GENERIC does _not_ fix the problem. The interface in question is an nge-compatible 64-bit Linksys card detected as: nge0@pci0:8:0: class=0x020000 card=0x10641737 chip=0x0022100b rev=0x00 hdr=0x00 vendor = 'National Semiconductor' device = 'DP83820/1 10/100/1000 Gigabit Ethernet Adapter' class = network subclass = ethernet I've also noticed data corruption in the form of failed CRCs (And hence dropped SSH connections) while transferring large amounts of data via SSH over gige to a machine on its subnet. These problems started occuring after the giant-less networking megacommit. Older kernels check out without any such issues. Additional information on the system can be found online: pciconf -vl: http://bling.properkernel.com/pciconf-vl.txt kernel config: http://bling.properkernel.com/BLING old dmesg (Can be updated): http://bling.properkernel.com/dmesg.boot.txt Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 23: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 BF98016A4CE for ; Sat, 11 Sep 2004 23:35:24 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 071B843D1F for ; Sat, 11 Sep 2004 23:35:15 +0000 (GMT) (envelope-from gwk@rahn-koltermann.de) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C6HOj-0001v5-00 for freebsd-current@freebsd.org; Sun, 12 Sep 2004 01:35:13 +0200 Received: from [217.232.140.192] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1C6HOj-00017a-00 for freebsd-current@freebsd.org; Sun, 12 Sep 2004 01:35:13 +0200 From: "Georg-W. Koltermann" To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1094945709.15216.4.camel@localhost.muc.eu.mscsoftware.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 12 Sep 2004 01:35:09 +0200 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:90bcaad5e51ecc993b2919ba4b74e6dc Subject: [5.3-BETA3] no IPSEC connection to 5.2.1 box 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, 11 Sep 2004 23:35:24 -0000 Hi, I don't get my IPSEC connection to run. This system is 5.3-BETA3, the other system is 5.2.1. Both use FAST_IPSEC. Keys are negotiated by racoon. This system logs: Sep 12 01:28:43 hunter racoon: INFO: isakmp.c:813:isakmp_ph1begin_i(): begin Aggressive mode. Sep 12 01:28:43 hunter racoon: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon Sep 12 01:28:43 hunter racoon: NOTIFY: oakley.c:2084:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. Sep 12 01:28:43 hunter racoon: INFO: isakmp.c:2459:log_ph1established(): ISAKMP-SA established 10.0.0.3[500]-10.0.0.2[500] spi:089d678f545f30a1:b029dca9f1b19b03 Sep 12 01:28:44 hunter racoon: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.3[0]<=>10.0.0.2[0] Sep 12 01:29:17 hunter racoon: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.3[0]<=>10.0.0.2[0] Sep 12 01:30:07 hunter last message repeated 2 times Sep 12 01:30:23 hunter named[369]: Err/TO getting serial# for "0.168.192.IN-ADDR.ARPA" Sep 12 01:30:29 hunter racoon: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.3[0]<=>10.0.0.2[0] Sep 12 01:30:29 hunter racoon: ERROR: pfkey.c:1076:pk_sendupdate(): libipsec failed send update (No buffer space available) Sep 12 01:30:29 hunter racoon: ERROR: isakmp_quick.c:651:quick_i2send(): pfkey update failed. Sep 12 01:30:29 hunter racoon: ERROR: isakmp.c:750:quick_main(): failed to process packet. Sep 12 01:30:29 hunter racoon: ERROR: isakmp.c:541:isakmp_main(): phase2 negotiation failed. Sep 12 01:30:57 hunter racoon: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.3[0]<=>10.0.0.2[0] Sep 12 01:31:21 hunter racoon: INFO: isakmp.c:952:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.3[0]<=>10.0.0.2[0] The other system logs: Sep 12 01:29:37 bat racoon: INFO: isakmp.c:1059:isakmp_ph2begin_r(): respond new phase 2 negotiation: 10.0.0.2[0]<=>10.0.0.3[0] Sep 12 01:29:37 bat racoon: INFO: pfkey.c:1197:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.3->10.0.0.2 spi=265528800(0xfd3a5e0) Sep 12 01:29:37 bat racoon: INFO: pfkey.c:1420:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.2->10.0.0.3 spi=41763698(0x27d4372) Sep 12 01:30:10 bat racoon: INFO: isakmp.c:1059:isakmp_ph2begin_r(): respond new phase 2 negotiation: 10.0.0.2[0]<=>10.0.0.3[0] Sep 12 01:30:10 bat racoon: INFO: pfkey.c:1197:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.3->10.0.0.2 spi=26763127(0x1985f77) Sep 12 01:30:10 bat racoon: INFO: pfkey.c:1420:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.2->10.0.0.3 spi=205325487(0xc3d04af) I should also mention that my ports (i.e. racoon) are still the binaries from 5.2.1 (mounted from the old partition due to space constraints). Do I need to recompile racoon for 5.3? -- Regards, Georg. From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 23: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 E3E8A16A4CE for ; Sat, 11 Sep 2004 23:43:31 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF3D43D45 for ; Sat, 11 Sep 2004 23:43:31 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 0099511AB2; Sun, 12 Sep 2004 01:43:28 +0200 (CEST) Date: Sun, 12 Sep 2004 01:43:28 +0200 From: "Simon L. Nielsen" To: "Georg-W. Koltermann" Message-ID: <20040911234328.GC770@zaphod.nitro.dk> References: <1094945709.15216.4.camel@localhost.muc.eu.mscsoftware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <1094945709.15216.4.camel@localhost.muc.eu.mscsoftware.com> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: [5.3-BETA3] no IPSEC connection to 5.2.1 box 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, 11 Sep 2004 23:43:32 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.09.12 01:35:09 +0200, Georg-W. Koltermann wrote: > I don't get my IPSEC connection to run. This system is 5.3-BETA3, the > other system is 5.2.1. Both use FAST_IPSEC. Keys are negotiated by > racoon. >=20 > This system logs: >=20 [...] > Sep 12 01:30:29 hunter racoon: INFO: isakmp.c:952:isakmp_ph2begin= _i(): initiate new phase 2 negotiation: 10.0.0.3[0]<=3D>10.0.0.2[0] > Sep 12 01:30:29 hunter racoon: ERROR: pfkey.c:1076:pk_sendupdate(= ): libipsec failed send update (No buffer space available) This is a known problem. A workaround is to set options MSIZE=3D512 in your kernel configuration file. --=20 Simon L. Nielsen FreeBSD Documentation Team --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBQ42gh9pcDSc1mlERAn6rAJ4x6qX4TcGjWUt33bwdrfo9GKgi1ACfbyS2 8t9AgliVlP02J/58uQ51/7A= =ATGw -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 23:53: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 71DFD16A4CE; Sat, 11 Sep 2004 23:53:07 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDEF843D2D; Sat, 11 Sep 2004 23:53:06 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i8BNdCjr002035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 11 Sep 2004 19:39:12 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Brian Fundakowski Feldman Date: Sat, 11 Sep 2004 19:54:55 -0400 User-Agent: KMail/1.6.2 References: <47158390.20040827112834@ulstu.ru> <200409111707.25937.mistry.7@osu.edu> <20040911212604.GY928@green.homeunix.org> In-Reply-To: <20040911212604.GY928@green.homeunix.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_hB5QBOHtGxvjErn"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409111955.13663.mistry.7@osu.edu> X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL, X_OSIRU_OPEN_RELAY version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: Wine and mmap 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, 11 Sep 2004 23:53:07 -0000 --Boundary-02=_hB5QBOHtGxvjErn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 September 2004 05:26 pm, you wrote: > On Sat, Sep 11, 2004 at 05:07:13PM -0400, Anish Mistry wrote: > > On Saturday 11 September 2004 02:00 pm, you wrote: > > > On Mon, Sep 06, 2004 at 01:49:35AM -0400, Anish Mistry wrote: > > > > On Sunday 05 September 2004 05:15 pm, Gerald Pfeifer wrote: > > > > > [ John, sorry for the duplicate message; this is the correct one.= ] > > > > > > > > > > On Fri, 27 Aug 2004, John Birrell wrote: > > > > > > Anish Mistry has developed a patch to choose > > > > > > an appropriate mmap address. He posted it to -current. I haven't > > > > > > had time to test it. > > > > > > > > > > Thanks for the note. Will you have time to test/commit this befo= re > > > > > 5.3? > > > > > > > > > > Anish, do you have any news on this patch? (Wine has been broken > > > > > for a couple of months now, and it would be great to have at least > > > > > 5.3 fixed.) > > > > > > > > Well I guess this is my lucky day. Apply the attached patch for > > > > vm_mmap to your kernel and patch the August wine sources with the > > > > wine-mmap.patch and compile and install wine (be sure to use gmake)= =2E=20 > > > > This is working on my dev system with 6-CURRENT as of Saturday nigh= t. > > > > The wine mmap patch just doesn't reserve the DOS area so DOS progra= ms > > > > may not work. This seems to just work around a side effect of the > > > > kernel mmap patch. I still think that the kernel mmap patch has > > > > issues so I'm hoping Alan can give us some feedback. > > > > Anyway this worked for me, YMMV. > > > > > > Do these combined work for you, minus any modifications to mmap(2)? I > > > do not feel that the kernel mmap(2) should be modified in this manner, > > > that it is a strictly userland problem. > > > > With only these applied I get old message that wine can't mmap it's > > address space. > > Oh, I'm sorry for not explaining the last step. You need to set the > environment variable "LD_LIBRARY_LOW_ADDR" to some address, like after > the first megabyte, or something like that, but before the first "data" > address. Try, say, 1024000. Ok, I've tried that, with several different numbers and I either get someth= ing=20 like: wine: failed to initialize: /usr/local/lib/libwine_unicode.so.1: mmap retur= ned=20 wrong address: wanted 0xc350000, got 0xc3bd000 or just the normal: wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: mmap of entir= e=20 address space failed: Cannot allocate memory Any other suggestions? =2D-=20 Anish Mistry --Boundary-02=_hB5QBOHtGxvjErn Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBQ5BhxqA5ziudZT0RAsHqAKDcA8gx8fRX+aqMkDwK5/CGgaCwiACeJst5 CJQNtqFqlv+3oAmea9YGCno= =jDup -----END PGP SIGNATURE----- --Boundary-02=_hB5QBOHtGxvjErn-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 23:54: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 8C28816A4CE; Sat, 11 Sep 2004 23:54:21 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE5643D41; Sat, 11 Sep 2004 23:54:21 +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 i8BNsKbT010834; Sat, 11 Sep 2004 19:54:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8BNsJj4036184; Sat, 11 Sep 2004 19:54:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 19EE67303F; Sat, 11 Sep 2004 19:54:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040911235420.19EE67303F@freebsd-current.sentex.ca> Date: Sat, 11 Sep 2004 19:54:20 -0400 (EDT) Subject: [releng_5 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, 11 Sep 2004 23:54:21 -0000 TB --- 2004-09-11 22:26:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-11 22:26:32 - starting RELENG_5 tinderbox run for ia64/ia64 TB --- 2004-09-11 22:26:32 - checking out the source tree TB --- 2004-09-11 22:26:32 - cd /home/tinderbox/RELENG_5/ia64/ia64 TB --- 2004-09-11 22:26:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2004-09-11 22:34:17 - building world (CFLAGS=-O -pipe) TB --- 2004-09-11 22:34:17 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-11 22:34:17 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-11 23:34:19 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-11 23:34:19 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-11 23:34:19 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 11 23:34: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 >>> Kernel build for GENERIC completed on Sat Sep 11 23:47:28 UTC 2004 TB --- 2004-09-11 23:47:28 - generating LINT kernel config TB --- 2004-09-11 23:47:28 - cd /home/tinderbox/RELENG_5/ia64/ia64/src/sys/ia64/conf TB --- 2004-09-11 23:47:28 - /usr/bin/make -B LINT TB --- 2004-09-11 23:47:28 - building LINT kernel (COPTFLAGS=-O -pipe) TB --- 2004-09-11 23:47:28 - cd /home/tinderbox/RELENG_5/ia64/ia64/src TB --- 2004-09-11 23:47:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 11 23:47:28 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 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/gate/g_gate.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_iso9660.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_msdosfs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/label/g_label_ufs.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/ia64/ia64/src/sys -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/altq -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/pf -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/RELENG_5/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': /tinderbox/RELENG_5/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2483: warning: 'sc' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/obj/ia64/tinderbox/RELENG_5/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/ia64/ia64/src. TB --- 2004-09-11 23:54:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-11 23:54:19 - ERROR: failed to build lint kernel TB --- 2004-09-11 23:54:19 - tinderbox aborted